Problem with Gadget2 evolve_model

[ReinosoB]

I am evolving the same set of sph particles up to the same time but in different chunks of time, using Gadget2.
The total wall clock time increases dramatically for very small chunks of time, which only makes sense to me if
somehow the timestep for Gadget2 particles is determined based on the time you give to the 'evolve_model()' function.
I am attaching the script to reproduce the issue. This does not occur with ph4.
Some idea of whats going on?

Thanks,

Bastián

gadget2_test.txt

[rieder]

Hi @ReinosoB,
You're comparing Gadget2 (an SPH code) with ph4 (an Nbody code). ph4 won't do any SPH calculations, so it will certainly be faster (also note that the "plummer gas sphere" initial conditions intentionally set the velocity of all gas particles to 0).
If you have regions with high density (which is likely for a Plummer model - which isn't initialised with equal density), the time it takes to evolve the model will definitely increase, certainly when you get close to one free-fall time.
evolve_model(time) will integrate from the current time of the code (model_time) until time. I'm not sure why you use increasingly short timesteps in your script?

One suggestion I would have is to use a time quantity as one of the variables for your converter (instead of mass or position), and to then always use factors of 2 of that time to determine the timestep. Also, depending on what you are attempting to simulate, you may prefer using the 'molecular cloud' initial conditions (as found in one of the textbook examples) to the Plummer gas model.

[ReinosoB]

Hi @rieder,

Many thanks for your answer.
I did not compare Gadget2 with ph4, I did a similar experiment using ph4 (but using different initial conditions, better suited for an Nbody code).
The point I wanted to make here is that Gadget2 makes use of individual timesteps and so I would expect that evolving the same set of particles to the same final time, but in different chunks (if you want for example more frequent snapshot output), should
not have this impact in the integration time, or am I missing something important here?

I am going to try your suggestion. Thanks again for your reply.

[ipelupessy]

you can check more carefully what is going on with passing the redirection="none" option to Gadget2 (at instantiation). For the small timesteps, the code is indeed not evolving for most of the evolve calls. Apperently there is some overhead in a "empty" evolve call...its a bit more than I would expect...

btw, you have to be careful setting the timestep parameters (max_size_timestep, and time_max) ie its a good idea to set your max_size_timestep to the timestep you want to have in the script and time_max some power of two multiple of that bigger than the eventual time you want to reach...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 28 days if no further activity occurs. Thank you for your contributions.

[ipelupessy]

closing as substantially solved