Open jonathanfischer97 opened 1 month ago
odeprob.u0
as wellIn threaded optimization loops, I have to remake the problem with newprob = remake(odeprob, p = copy(odeprob.p), u0 = copy(odeprob.u0)
in order to avoid multiple threads mutating the same fields of the parent ODEProblem
This is at least the standard behavior with the rest of remake. There is a coming alias system that could improve this behavior. Copy by default could have some major other implications though so it's hard to add into the system (and you cannot assume every p
type has a copy
so the solve cannot necessarily do it, so ensembleprob on threads has safetycopy for deepcopy, which is a bad fallback).
So it's at least consistent, but I agree I'm not happy with it.
remake
doesn't copy theMTKParameters
object, unless new parameters are passed directlyIf a new problem is made with
newprob = remake(odeprob)
, any mutations tonewprob.p
will affectodeprob.p
because both fields point to the same thing. This side effect is either a bug or not well documented, because a naive user would not expect this.@parameters α β γ δ @variables x(t) y(t) eqs = [D(x) ~ (α - β y) x D(y) ~ (δ x - γ) y] @mtkbuild odesys = ODESystem(eqs, t)
using OrdinaryDiffEq odeprob = ODEProblem( odesys, [x => 1.0, y => 1.0], (0.0, 10.0), [α => 1.5, β => 1.0, γ => 3.0, δ => 1.0])
newprob = remake(odeprob)
Will evaluate to true
parameter_values(newprob) === parameter_values(odeprob)
This will change
odeprob.p
even though we are callingreplace!
on the new parametersreplace!(Tunable(), parameter_values(newprob), rand(4)) odeprob.p
remake
to possibly be thread unsafe if the problem is remade and then modified within the loopremake(odeprob; p = newp)
ODEProblem
is copied withremake
first, and then the parameters of the new problem modified withreplace!
:odeprob.p
in addition tonewprob.p
every iteration, obviously not threadsafe or generally robustSolution
remake
needs to copy the original problem's parameters when constructing the new problemPackage environment
Version info