- 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: 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

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:

Received on 2009-09-29 12:42:49

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