Closed timknab closed 2 months ago
Thanks for pointing this out. I should have phrased the reply in the linked issue a bit better. remake
right now supports parametric initial conditions if they are passed to remake
. i.e. passing u0 = [x => 2p1], p => [p1 => 3]
will set the value of x
to 6. To support doing this for default values in the system, we need https://github.com/SciML/SymbolicIndexingInterface.jl/pull/47 which is something I'll get around to finishing soon
Ah ok, sorry for the misunderstanding
I'll keep an eye on https://github.com/SciML/SymbolicIndexingInterface.jl/pull/47 and can easily work around it using get_u0
in the meantime
Thanks!
This now works:
julia> prob2 = remake(prob, u0 = Dict(), p = [x0 => 9.0], use_defaults = true)
ODEProblem with uType Vector{Float64} and tType Float64. In-place: true
timespan: (0.0, 10.0)
u0: 2-element Vector{Float64}:
9.0
0.0
u0 = Dict()
is necessary since otherwise it doesn't process any updates to u0
. use_defaults = true
is necessary so that the model defaults take precedence over the existing values of variables in the problem.
use_defaults = true is necessary so that the model defaults take precedence over the existing values of variables in the problem.
That shouldn't be the case, dependencies should always be handled?
That would be breaking. Prior to this remake
rework, it didn't take defaults into account. If we do that by default, it breaks MTK tests
I wouldn't call that breaking. It's a bug fix. I think it's clear that any user would expect u0[1] = x0
here, and the fact that it doesn't after remake is unintended.
So if the defaults also include constant values y => 10.0
should this be used instead of the existing values in the problem passed to remake
? Or do we only consider dependent defaults?
Also, I'm calling it breaking because MTK tests rely on this behavior of ignoring defaults. I think they'll also pass if we only ignore constant-valued defaults, but am not sure
I think we'd ideally error if any given constraints cannot be satisfied. I'm not sure how easy that is to do though, but that would be the most ideal situation.
Should y => 1.0
be treated as a constraint? Wouldn't this severely restrict how problems can be remade?
No, just functions of other parameters.
And if the user explicitly provides an alternate value (e.g. x => 1.0
in the above example)? Error?
I'd prefer error yes
Actually, it should act like the initialization stuff. So you always want to make sure the "current" equations are satisfied. Anything put into ODEProblem
or remake
is an override. If someone does p1 ~ 2*p2
, then that should always be satisfied, so p2 => 2.0
should change p1
. If someone then does p1 => 2.0
, they are overriding this definition, since they used to have @parameters p1 = 2*p2
and now they did a late override to remove that equation.
"Removing that equation" is modifying the system, which remake
doesn't do. Parameter dependencies are intrinsic to the system since they only exist at the MTK level. Parameter defaults can be overridden, which remake
will do.
Remake still does not appear to update initial conditions that are dependent on parameters. Following up from this issue where supposedly this was fixed in #644
Would expect prob2.u0 = [9.0, 0.0]