- Mail actions: [ respond to this message ] [ mail a new topic ]
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

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

Date: Thu, 12 Jan 2006 17:22:38 +0100

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

Received on 2006-01-12 17:22:38

*
This archive was generated by hypermail 2.3.0
: 2022-09-01 14:03:41 CEST
*