- 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: Wed, 01 Mar 2006 22:35:07 +0100

Yves Revaz wrote:

*>
*

*> Dear All,
*

*>
*

*> In the new implementation of sph, the smoothing length is not
*

*> constraints by the number
*

*> of neighbours but by imposing that the volume defined by the smoothing
*

*> length contains
*

*> a constant mass (eq. 6 of Springel 2005).
*

*> However, when running gadget (with DesNumNgb=50), I get the typical
*

*> following values
*

*> out of the routine "density_evaluate" :
*

*>
*

*> numngb_inbox = 12 # numbers of neighbours in a box of
*

*> dimension 2h x 2h x 2h
*

*> numngb = 10 # numbers of neighbours in a sphere of
*

*> radius h weighted_numngb = 49.936302 # weighted number of
*

*> neighbours
*

*>
*

Hi Yves,

I don't really think that these are typical numbers. Please note that

density_evaluate only looks for the neighbours on the local processor, i.e.

there can be additional contributions on other domains that are added in

with separate calls of this function on other processors.

Nevertheless, the number of actual neighbours inside the radius h can be

smaller than the value of DesNumNgb in certain cases (in general it scatters

around this value while weighted_numngb is always close to DesNumNgb). This

happens in particular for particles at the centre of density peaks.

The most extreme cases of this behaviour can happen if one has a very small

clump of a few particles (~10 or smaller) embedded in a sea of a particle

distribution of much lower density. Then the kernel radius h for the

particles of such a clump will be much larger than the radius of the clump,

letting several of the neighbours contribute with the full kernel weight at

zero lag (r/h<<1). This means they contribute strongly to the weighted

neighboor sum, making the absolute number of neighbours quite a bit smaller

than DesNumNgb.

However, I don't really see a severe deficit due to this. In this situation

one probably doesn't want that the clump particles couple strongly to

particles of the low density phase that are far away - after all, the

clumps have a fairly sharp "edge" in such a case. Also, low density

particles will still couple in the force equation to the clump particles

(their h will overlap with the clump particles from a larger volume than the

other way round) in a one-sided way. Finally, while in the more traditional

scheme to determine h one would set a slightly higher h in this case for the

clump particles, the additional neighbours that are seen would all lie at

the edge of the smoothing kernel, and would then contribute little to the

SPH sums. So I don't think that there is a significant difference in the

dynamics in this case between the two schemes.

Volker

*> I have been first surprised by the fact that from 10 effective
*

*> neighbours we finally obtain
*

*> 49.936302 weighted number of neighbours ! However, this may be
*

*> understood from the
*

*> kernel definition and the weighted number of neighbours definition :
*

*>
*

*> wk ~ 8/(pi*h3) # for r/h<<1
*

*>
*

*> weighted_numngb ~= 4/3*pi*h3 *rho * / m ~= 4/3*pi*h3 *
*

*> numngb*8/(pi*h3)*m / m ~= 10.66 numngb
*

*>
*

*>
*

*> Thus, when setting DesNumNgb we do not really set the effective number
*

*> of neighbours,
*

*> but rather ~10 times (depending on the distribution around the particle)
*

*> the effective number
*

*> of neighbours. As a consequence, with DesNumNgb=50, only few particles
*

*> are taking into account
*

*> to compute the hydrodynamical forces (about 10 in the latter case),
*

*> while in classical sph one expect
*

*> to have at least 30 neighbours.
*

*>
*

*> Could someone comment on that ?
*

*>
*

*> Thanks.
*

*>
*

*>
*

*>
*

Received on 2006-03-01 22:35:19

Date: Wed, 01 Mar 2006 22:35:07 +0100

Yves Revaz wrote:

Hi Yves,

I don't really think that these are typical numbers. Please note that

density_evaluate only looks for the neighbours on the local processor, i.e.

there can be additional contributions on other domains that are added in

with separate calls of this function on other processors.

Nevertheless, the number of actual neighbours inside the radius h can be

smaller than the value of DesNumNgb in certain cases (in general it scatters

around this value while weighted_numngb is always close to DesNumNgb). This

happens in particular for particles at the centre of density peaks.

The most extreme cases of this behaviour can happen if one has a very small

clump of a few particles (~10 or smaller) embedded in a sea of a particle

distribution of much lower density. Then the kernel radius h for the

particles of such a clump will be much larger than the radius of the clump,

letting several of the neighbours contribute with the full kernel weight at

zero lag (r/h<<1). This means they contribute strongly to the weighted

neighboor sum, making the absolute number of neighbours quite a bit smaller

than DesNumNgb.

However, I don't really see a severe deficit due to this. In this situation

one probably doesn't want that the clump particles couple strongly to

particles of the low density phase that are far away - after all, the

clumps have a fairly sharp "edge" in such a case. Also, low density

particles will still couple in the force equation to the clump particles

(their h will overlap with the clump particles from a larger volume than the

other way round) in a one-sided way. Finally, while in the more traditional

scheme to determine h one would set a slightly higher h in this case for the

clump particles, the additional neighbours that are seen would all lie at

the edge of the smoothing kernel, and would then contribute little to the

SPH sums. So I don't think that there is a significant difference in the

dynamics in this case between the two schemes.

Volker

Received on 2006-03-01 22:35:19

*
This archive was generated by hypermail 2.3.0
: 2023-01-10 10:01:30 CET
*