<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hello,</p>
<p> </p>
<p>first I agree a variable smoothing length is the better choise in a SPH algorithm.</p>
<p>As I understood, one of the bigger problems is the implementation of the particles in Carpet, because of MPI. For using a tree structure to save and search particles there is a global memory outside of the parallelized threads necessary. In this case we could use variable smoothing length without problems, I think (it is still possible to make a search routine without trees, using the grid structure, but therefor it is also necessary to determine the grid cell enclosing a particle).</p>
<p>-Stefan</p>
<p> </p>
<p> </p>
<p> </p>
<div> </div>
<p>Am 2015-11-25 21:53, schrieb Erik Schnetter:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">Stefan
<div> </div>
<div>There exist several algorithms for managing the SPH particles and finding interactions. Personally, I dislike using an algorithm that would e.g. changing the particle radius depending on the process decomposition.</div>
<div> </div>
<div>If I was to implement an SPH method for astrophysics in Cactus, then I would probably choose a binary tree. I would make the process decomposition that is implied by this tree independent of how Cactus decomposes its grid functions. Thus you can test both grid functions and particle algorithms independently.</div>
<div> </div>
<div>To couple particles and grids, you need two ingredients:</div>
<div>- Interpolate grid quantities at particle locations</div>
<div>- Deposit particle quantities onto grid</div>
<div> </div>
<div>The first already exists in Cactus; you would use the Cactus interpolator for this.</div>
<div> </div>
<div>The second is particle-specific, and this routine needs to be written. Determining the grid cell enclosing a particle is the main ingredient. For PUGH (a uniform grid) this is straightforward; for Carpet, there is a routine "gh::locate_position" that one would call.</div>
<div> </div>
<div>Apart from these considerations, I have a personal preference for algorithms that are derived from a Lagrangian. A variable smoothing length is likely important in astrophysics since you will encounter large density differences there.</div>
<div> </div>
<div>-erik</div>
<div> </div>
<div> </div>
<div> </div>
</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Wed, Nov 25, 2015 at 2:18 AM, Stefan Ruehe <span><<a href="mailto:sruehe@astrophysik.uni-kiel.de">sruehe@astrophysik.uni-kiel.de</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;"><span style="text-decoration: underline;"></span>
<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">
<p>Good morning,</p>
<p> </p>
<p>I have made some thoughts about the problems with SPH and MPI.</p>
<p>I found a paper by Valdez-Balderas et al (2012) (<a href="http://adsabs.harvard.edu/abs/2012arXiv1210.1017V">http://adsabs.harvard.edu/abs/2012arXiv1210.1017V</a>), which could help to solve some of the problems.</p>
<p>They suggest a particle halo on each processor unit, in which the neighbour particle of the adjacent processors are saved. This should be synchronized in each timestep.</p>
<p>One problem of this method is SPH have to use fixed smoothlength, otherwise the volume of the halo can't be set. The variability of the smoothlength is required to have an adaptive refinement in the SPH-algorithm. I would suggest to use semi-fixed smoothlength, which are smaller in higher refindement levels. This could reduce the disadvantages of the fixed smoothlength.</p>
<p>What is your opinion this?</p>
<p> </p>
<p>Now I try to test how good SPH-approximations for the hydrodynamic grid variables in the Tmunu base are under the condition of such "adaptive-fixed" smoothlength. I have an other method in mind, but this would need more temporary memory.</p>
<p>Best regards,</p>
<p>Stefan Ruehe</p>
<p> </p>
<p> </p>
<div> </div>
</div>
<br />_______________________________________________<br /> Users mailing list<br /><a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br /><a href="http://lists.einsteintoolkit.org/mailman/listinfo/users">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br /><br /></blockquote>
</div>
<br /><br clear="all" />
<div> </div>
-- <br />
<div class="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>><br /><a href="http://www.perimeterinstitute.ca/personal/eschnetter/">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div>
</blockquote>
</body></html>