Re: boxSize_Z in 2D hydro runs

From: Volker Springel <volker_at_MPA-Garching.MPG.DE>
Date: Tue, 29 Sep 2009 12:42:48 +0200

Hi Sander,

The boxSize_Z is indeed superfluous if you interpret the density of the 2D runs
as a surface density, and you define a two-dimensional pressure, etc.

I had introduced the boxSize_Z at some point to allow an interpretation of the
2D runs in terms of a 3D simulation with an imposed symmetry, such that each
particle is effectively a cylinder in 3D. And in order to get the same "3D"
density values as in a comparison calculation in 3D, I introduced the boxSize_Z
division.

If you don't like this and rather want to work with the surface density
interpretation, you can either eliminate the boxSize_Z division, or arrange
things such that boxSize_Z = 1, which is always possible with an appropriate
setting of LONG_Z, provided periodic boundaries are used. I have assumed that
the latter will always be used for such 2D tests, because gravity is not
supported for such runs, but which would be needed to hold the gas together in
the absence of periodic boundaries. But I guess you could use vaccum boundaries
also if you insist. This requires deleting boxSize_Z then in order to compile
the code.

In general I should also caution that the 2D functionality for SPH simulations
with Gadget-II was really only introduced to allow small test-problems, without
paying particular attention to optimize all of the code from 3D to 2D. (For
example, the additional superfluous storage for the third dimension is still
carried around by the code, and superfluous computations for this third
coordinate are done as well. Also, there is no proper support for gravity in 2D.)

Cheers,
Volker


Sander Valcke wrote:
> And to add to the problem: boxSize_Z is only declared for periodic
> simulations. Using hinv3 and hinv4 as listed below the code does not
> compile with TWODIMS set but PERIODIC not set.
>
> Sander Valcke wrote:
>>
>> Dear gadget list,
>>
>> I have a small question about 2D hydro simulations in GadgetII. In
>> hydra.c and density.c the following lines are used to get the inverse
>> of the 2nd or 3rd power (2D) of the smoothing length:
>>
>> hinv3 = hinv * hinv / boxSize_Z;
>> hinv4 = hinv * hinv * hinv / boxSize_Z;
>>
>> I do not understand why the boxSize_Z is there, why would the Z
>> boxsize have any influence at all in a 2D simulation? I ran some tests
>> and when commenting out the boxSize_Z the simulation results do
>> differ, although the initial differences are quite small and the
>> long-term qualitative evolution seems to remain the same.
>>
>> So, I would like to understand why that term is there, and whether I
>> can safely remove it (the 2D particle densities written in the
>> snapshots are the real 2D densities divided by boxSize_Z, which is a
>> bit confusing).
>>
>> Cheerz,
>>
>> Sander
>>
>
Received on 2009-09-29 12:42:49