-
-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set u_modified in DAE initialization if the u was changed #1969
base: master
Are you sure you want to change the base?
Conversation
Some integrators (such as Sundials) keep a shadow copy of `u` and need to reflect this copy back into the solver internals to use them. This happens e.g. during callbacks, but the same situation applies to initialization, so use the same mechanism (setting u_modified to `true`) to let the solver know that it needs to update its internal datastructures.
@@ -183,6 +183,7 @@ function _initialize_dae!(integrator, prob::ODEProblem, alg::ShampineCollocation | |||
integrator.u .= nlsol.u | |||
failed = nlsol.retcode != ReturnCode.Success | |||
end | |||
u_modified!(integrator, true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the default assumption. What's a case where this makes a difference?
Needs a test case |
Sundials.jl got an implementation of the OrdinaryDiffEq DAE initialization interface in SciML#401. Unfortunately, it turns out that this doesn't quite work, because the u/du in Sundials' integrator struct are not the actual memory that IDA uses (it has an internal copy). In [1], I propose re-using `u_modified` to inform us that the shadow copy was modified during initialization. This is the Sundials side of that interface. [1] SciML/OrdinaryDiffEq.jl#1969
Sundials.jl got an implementation of the OrdinaryDiffEq DAE initialization interface in SciML#401. Unfortunately, it turns out that this doesn't quite work, because the u/du in Sundials' integrator struct are not the actual memory that IDA uses (it has an internal copy). In [1], I propose re-using `u_modified` to inform us that the shadow copy was modified during initialization. This is the Sundials side of that interface. [1] SciML/OrdinaryDiffEq.jl#1969
Sundials.jl got an implementation of the OrdinaryDiffEq DAE initialization interface in SciML#401. Unfortunately, it turns out that this doesn't quite work, because the u/du in Sundials' integrator struct are not the actual memory that IDA uses (it has an internal copy). In [1], I propose re-using `u_modified` to inform us that the shadow copy was modified during initialization. This is the Sundials side of that interface. [1] SciML/OrdinaryDiffEq.jl#1969
Sundials.jl got an implementation of the OrdinaryDiffEq DAE initialization interface in #401. Unfortunately, it turns out that this doesn't quite work, because the u/du in Sundials' integrator struct are not the actual memory that IDA uses (it has an internal copy). In [1], I propose re-using `u_modified` to inform us that the shadow copy was modified during initialization. This is the Sundials side of that interface. [1] SciML/OrdinaryDiffEq.jl#1969
I don't believe this is necessary. Specifically, setting u_modified in inits is only needed for Sundials solvers, and sundials solvers don't use ODE/DAEIntegrator so these initialization methods will never be used with them, |
That's true, but only by default, there's nothing preventing people from setting these manually or chaining them, but even if nobody were to ever do that, that's not really the point. The question is whether the interface requires these to be set and as written, the answer is yes. |
Some integrators (such as Sundials) keep a shadow copy of
u
and need to reflect this copy back into the solver internals to use them. This happens e.g. during callbacks, but the same situation applies to initialization, so use the same mechanism (setting u_modified totrue
) to let the solver know that it needs to update its internal datastructures.