Open fredt00 opened 6 months ago
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.
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.
It seems to me that this isn't fixed? In that case it should remain open until we can figure out what the problem is.
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.
Hi,
I have a problem that I think is related to issue https://github.com/amusecode/amuse/issues/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 https://github.com/amusecode/amuse/issues/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