<html>#2626: Multipole is not OpenMP parallelized
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Gabriele Bozzola</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>trivial</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p>If the loops (e.g. the ones over radii) contain calls to the interpolator then they cannot be OpenMP parallelized, since the interpolator (no Cactus call actually) is not thread save.</p>
<p>One would have to MPI parallelize but that is not trivial since the interpolator is a MPI collective call (but different ranks may pass different arguments, so what is needed is “dummy” interpolator calls on those ranks that have run out of radii to work on). It is also not fully clear if this would speed up (or not, if the inter-process communication actually dominates). </p>
<p>The loops over (l,m) can be OpenMP parallelized (no interpolator call there) can be parallelized using OpenMP (though watch out for shared temporary arrays and static variables).</p>
<p>You may actually see an extra speedup, if you are using it, by switching from ASCII output to HDF5 output.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2626/multipole-is-not-openmp-parallelized'>https://bitbucket.org/einsteintoolkit/tickets/issues/2626/multipole-is-not-openmp-parallelized</a></p>
</html>