Open dpad opened 3 years ago
Thinking through this a bit more, it does seem like it's more of an issue of not making copies of the callbacks when solving an EnsembleProblem. I've injected a simple deepcopy(callback)
in my own __solve()
dispatch (which passes down to the underlying __solve(ODEProblem)
) and it seems to have solved this issue (NOTE: the above issue is therefore no longer present in OrbitalTrajectories >= 0.1.11
).
I wonder if this should be default behaviour, or if there should be some way to trigger it automatically or otherwise warn very clearly that this can happen?
We should solve this by making the cache in init
See the minimum example below, which loops until resulting in the shown crash.
I did some simple debugging (looking at the thread IDs) and found that
PeriodicCallback
seems to have a race issue with theindex[]
value getting reset (in the initialisation function) by different threads, leading to another thread trying to add a newtstop
value in the wrong place (i.e. wheretdir_tnew < integrator.t
).I can fix this issue by changing
tnew = t0[] + (index[] + 1) * Δt
(inPeriodicCallback
function) totnew = integrator.t + Δt
-- however, I think the issue probably still remains in thecondition
function. So it probably needs a better thought out solution.Could it be simply that
EnsembleProblem
is sharing callbacks between the threads, rather than making copies? I didn't look into this. [UPDATE: I did. See comments below. This particular error only occurs onOrbitalTrajectories v0.1.10
.)