Resume a simulation with ODE bodies

I notice that when resuming a simulation with ODE bodies, I would get a WARNING
“simulation has rigid bodies and/or moving boundaries, resume will not give identical results”.

I did a simple test using the BuoyancyTest, tend=10s. resume it at 5s and compared with no resume.
indeed, there are some differences between the results, not serious.

However, I think resume is quite important not only for simulation but also for debugging.
How can I fix it, at least, I doubt is that something missing when resuming (or, hotwriter)?

I found this in HotFile.cc
// NOTE: simulation with ODE bodies cannot be resumed identically due to
// the way ODE handles its internal state.
// TODO FIXME/ should be num ODE bodies

Then, the question is what the internal state means.
i suspect, is that acceleration? if so, i believe this can be fix easily.

Hello @JoJo,

the warning makes things a bit more catastrophic than they should be, so depending on your debugging needs, you may be able to use the resume function. Resuming the simulation will give numerically different results from not resuming it, but resuming it multiple times from the same save point should give you the same result each time.

The comment in HotFile is a bit obsolete (we don’t even use libODE anymore for the rigid bodies, but Project Chrono), but the principle is still the same: some of the internal state of the external library cannot be restored reliably. I don’t remember the exact details off the top of my head, but I think the main culprit when we were using ODE was the object rotation (something about the usage of angles vs rotation matrix, IIRC), and with Chrono that plus something to do with the internal state of the integrator.

That being said, if you do find a way to extract and restore the necessary data (possibly in a way that would survive upgrades to the Chrono library), we’ll gladly accept it into mainline (for us this has always had a lower priority because the numerical differences usually do not affect the overall results significantly, and when they do it’s indicative of a numerically unstable problem, which is a bigger issue than just not being able to restore rigid bodies invariantly).

thanks for the reply.
I just found that some variables are missing in CHRONO when resumes.
like acceleration (linear and angular) and Syscoord.
So, maybe we can use the functions like GetWac_par(), save and load that data.