You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a problem that I think is related to issue #679. I am trying to couple a live NFW halo in gadget2 with an orbiting test mass, however I have noticed that no matter how long I pre-evolve the halo to allow it to reach equilibrium, as soon as I add it to bridge, the halo rapidly expands. I have tried the suggestions made in #679, in particular ensuring that max_size_timestep in gadget2 is a few factors of two less than the bridge timestep (dt), and using a multiple of two times the bridge timestep in the unit converter, but the issue persists.
Attached is an example script that demonstrates the problem by evolving the same halo first by calling evolve_model every bridge timestep, and then evolving with a bridge integrator. The resulting evolution is dramatically different. I ran the same test with BHTree and in this case the evolution is the same whether or not I call evolve_model directly or via bridge. The evolution with and without bridge does match for gadget2 if I add it to the bridge with add_code instead of add_system.
I'm also confused by the output file from gadget2, with every multiple of dt/max_size_timestep step having a systemstep=0, yet the time still increases:
I've narrowed down the problem to line 464 in bridge: channel.copy_attributes(["vx","vy","vz"])
and more generally, copying to gadget2 between evolve_model calls seems to cause rounding errors in the timestep. The script test.py.txt demonstrates this with the output file for the case where data is copied to gadget2 showing the lines:
Begin Step 1, Time: 1, Systemstep: 0
Begin Step 2, Time: 2, Systemstep: 0
Begin Step 3, Time: 2.99994, Systemstep: 0
Begin Step 4, Time: 3.99994, Systemstep: 1
Begin Step 5, Time: 4, Systemstep: 0
Begin Step 6, Time: 5, Systemstep: 0
The two simulations diverge after step 5. Adding print(gravity.get_time_step().in_(units.Myr)) in the script shows a timestep of 0.999938964844 Myr followed by 6.103515625e-05 Myr at 4Myr and 5Myr respectively, yet the model_time still increases by 1Myr. I've tried different multiples of dt in the unit converter and parameters.max_size_timestep but the evolution never matches the case where no data is copied from the interface to gadget2.
Hi,
I have a problem that I think is related to issue #679. I am trying to couple a live NFW halo in gadget2 with an orbiting test mass, however I have noticed that no matter how long I pre-evolve the halo to allow it to reach equilibrium, as soon as I add it to bridge, the halo rapidly expands. I have tried the suggestions made in #679, in particular ensuring that max_size_timestep in gadget2 is a few factors of two less than the bridge timestep (dt), and using a multiple of two times the bridge timestep in the unit converter, but the issue persists.
Attached is an example script that demonstrates the problem by evolving the same halo first by calling evolve_model every bridge timestep, and then evolving with a bridge integrator. The resulting evolution is dramatically different. I ran the same test with BHTree and in this case the evolution is the same whether or not I call evolve_model directly or via bridge. The evolution with and without bridge does match for gadget2 if I add it to the bridge with add_code instead of add_system.
gadget_testing.py.txt
I'm also confused by the output file from gadget2, with every multiple of dt/max_size_timestep step having a systemstep=0, yet the time still increases:
Am I implementing gadget2 incorrectly?
Thanks!
Fred
The text was updated successfully, but these errors were encountered: