Re: boxSize_Z in 2D hydro runs

From: Sander Valcke <>
Date: Tue, 29 Sep 2009 14:15:12 +0200

Hi Volker,

thank you for the clear answer!

As for why I need non-periodic 2D: I'm trying to do some 2D windtunnel
simulations where new SPH particles are generated "on the left side",
and then after interacting with an object they are destroyed when they
pass through "the right side" (or the upper or lower side, for that

Thanks also for the warning on Gadget not being optimized, I'll just
remove most of the obvious superfluous computations, the memory isn't
really an issue, same for the gravity.



Volker Springel wrote:
> 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
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:

| Sander Valcke                                  |
| Sterrenkundig Observatorium, Universiteit Gent |
| Krijgslaan 281 S9, B-9000 Gent, Belgium        |
| phone +32-9-264-4796  |  fax +32-9-264-4989    |
|       |
Sometimes the best medicine is to stop taking something.
Received on 2009-09-29 14:10:05

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