Re: Star formation

From: Volker Springel <volker_at_MPA-Garching.MPG.DE>
Date: Thu, 12 Jan 2006 17:22:38 +0100

> I'm now using Gadget2 to implement star formation and I have found some
> differences with the first version which confuse me. I'm refering to the
> defintion of the smoothing parameters for SPH particles.
>
> Although the /ngb_treefind/ routine I need (to look over the
> neighbourhood of particles that are candidates to form stars) does not
> exist anymore (I have rewritten one similar), my real problem concerns
> the density evaluation (/void density_evaluate(int target, int mode) /in
> "density.c"). When I ask for the number of neighbours of a particle, it
> returns something like /SphP[i].Numngb=33.2/ (which is OK even if I
> don't understand why this variable is now a /float/ instead of an
> /integer/?!). But, when I look for the index stored in the external
> variable /Ngblist/, I find only 23 neighbours!!! It seems to me that I
> can't really "see" all the neighbours, but is there a particular reason
> behind this?
> Last one, but the most important: the corresponding smoothing length
> /SphP[i].Hsml /does not refer to any of the neighbours stored in the
> list. How should I understand this? Is this parameter not related to
> /Numngb/ anymore?
>

Hi,

in gadget2, the smoothing lengths are not defined as the distance to the
N-th neighbour, rather by a constraint between kernel volume and
estimated density. As a result, the smoothing length depends on the
locations of all particles within the smoothing volume, not only the
most distant one. This is explained in gadget2's code paper, see in
particular equation (6).

What is stored in the variable NumNgb is not the plain neighbour count,
but rather the quantity 4pi/3 h_i^3 * sum_j w_j, where w_j are the
kernel weights of the neighbours. This is a "weighted number of
neighbours", and is indeed a float, not an int. The actual number of
neighbours contributing to the neighbour list can be both larger or
smaller, and will in general scatter around the weighted number.

It is possible to revert to a raw count of all neighbours by replacing
   weighted_numngb += NORM_COEFF * wk / hinv3;
in density.c with
   weighted_numngb += 1;
but the resulting formulation of SPH will not conserve both energy and
entropy simultaneously.

Volker






> Could someone please explain these subtleties to me? Lastly, can I use
> the neighbours found in /Ngblist/ for some experiments (changes of
> type...) without problems???
>
Received on 2006-01-12 17:22:38