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
Hello, I have been doing some repeatability tests and just found that there seems to be an issue with the RK45 solver (and probably other ones) not flushing its memory when, for example, a new m is defined.
What I see is that if you run the same simulation in a loop like this one:
for p:=0; p<12; p++{
t = 0
m = Uniform(-1,0.2,0)
run(1e-9)
}
different results are obtained for each loop.
It seems to be an issue of the solver not flushing the torques in the memory because I can do this to force a flush:
for p:=0; p<12; p++{
m = Uniform(-1,0.2,0)
SetSolver(1)
steps(10)
SetSolver(5)
t = 0
m = Uniform(-1,0.2,0)
run(1e-9)
}
and then (almost) fully reproducible results are obtained.
This looks to me like a serious bug, because intuitively one should not have to manually flush the torque buffer when changing m and this can lead to non-reproducibility of results when people do e.g. parameter scans using a loop.
I attach an example file with a complete script showing the issue. Fix_solver_buffer.txt
The text was updated successfully, but these errors were encountered:
In most cases, the error would be negligible because only the first timestep of the run would have a small error. Nevertheless, the cache buffers should indeed be flushed when starting a new run.
Pull request #261 fixes this issue. With these changes, the "flush cycle" and "no flush cycle" in "Fix_solver_buffer.txt" yield similar results. Note that there are still some small fluctuations in the results because the initial step size is slightly different for each run.
Hello, I have been doing some repeatability tests and just found that there seems to be an issue with the RK45 solver (and probably other ones) not flushing its memory when, for example, a new m is defined.
What I see is that if you run the same simulation in a loop like this one:
different results are obtained for each loop.
It seems to be an issue of the solver not flushing the torques in the memory because I can do this to force a flush:
and then (almost) fully reproducible results are obtained.
This looks to me like a serious bug, because intuitively one should not have to manually flush the torque buffer when changing m and this can lead to non-reproducibility of results when people do e.g. parameter scans using a loop.
I attach an example file with a complete script showing the issue.
Fix_solver_buffer.txt
The text was updated successfully, but these errors were encountered: