Skip to content

Inconsistency for how to give intiial conditions to DAEs with higher order derivatives. #2619

New issue

Have a question about this project? No Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “No 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? No Sign in to your account

Closed
TorkelE opened this issue Apr 5, 2024 · 5 comments · Fixed by #3032
Closed
Labels
bug Something isn't working

Comments

@TorkelE
Copy link
Member

TorkelE commented Apr 5, 2024

Normally, one can/should give initial values/guesses for variables occurring only in the algebraic equations parts of a DAE. However, when one does this for a DAE with higher-order derivatives there are weird behaviours:

using OrdinaryDiffEq, ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D

# Creates systems.
@parameters k1 k2 ω
@variables X(t) Y(t)
eqs_1st_order = [D(Y) + Y - ω ~ 0,
       X + k1 ~ Y + k2]
eqs_2nd_order = [D(D(Y)) + 2ω*D(Y) +^2)*Y ~ 0,
        X + k1 ~ Y + k2]
@mtkbuild sys_1st_order = ODESystem(eqs_1st_order, t)
@mtkbuild sys_2nd_order = ODESystem(eqs_2nd_order, t)

# Creates initial conditions and parameters.
u0_1st_order_1 = [X => 1.0, Y => 2.0]
u0_1st_order_2 = [Y => 2.0]
u0_2nd_order_1 = [X => 1.0, Y => 2.0, D(Y) => 0.5]
u0_2nd_order_2 = [Y => 2.0, D(Y) => 0.5]
tspan = (0.0, 10.)
ps ==> 0.5, k1 => 2.0, k2 => 3.0]

# Creates ODEProblems.
oprob_1st_order_1 = ODEProblem(sys_1st_order, u0_1st_order_1, tspan, ps)
oprob_1st_order_2 = ODEProblem(sys_1st_order, u0_1st_order_2, tspan, ps)
oprob_2nd_order_1 = ODEProblem(sys_2nd_order, u0_2nd_order_1, tspan, ps) # gives sys_2nd_order
oprob_2nd_order_2 = ODEProblem(sys_2nd_order, u0_2nd_order_2, tspan, ps)

# Solves ODEProblems.
solve(oprob_1st_order_1, Rosenbrock23()) # retcode: Success
solve(oprob_1st_order_2, Rosenbrock23()) # retcode: Success
solve(oprob_2nd_order_1, Rosenbrock23()) # retcode: InitialFailure
solve(oprob_2nd_order_2, Rosenbrock23()) # retcode: Success
@TorkelE TorkelE added the bug Something isn't working label Apr 5, 2024
@ChrisRackauckas
Copy link
Member

What is the weird behavior?

@TorkelE
Copy link
Member Author

TorkelE commented Apr 5, 2024

Here, if you provide an initial guess for X (the variable that only appears in the algebraic equation) when attempting to solve the 2nd-order DAE, you get an error. However, it is possible to give such a guess to the DAE with first order differentials only.

(This might make sense for someone more involved, but encountered it when running various tests, and figured that it seemed weird)

@ChrisRackauckas
Copy link
Member

That's not a guess, it's a condition, and the 3 conditions together are not satisfiable. If you want to supply a guess, you have to make it a guess. See guesses in https://docs.sciml.ai/ModelingToolkit/stable/tutorials/initialization/

@TorkelE
Copy link
Member Author

TorkelE commented Apr 5, 2024

Right, that makes sense. But why do I then not get the same problem for the first case? I.e.

u0_1st_order_1 = [X => 1.0, Y => 2.0]
oprob_1st_order_1 = ODEProblem(sys_1st_order, u0_1st_order_1, tspan, ps)
sol = solve(oprob_1st_order_1, Rosenbrock23()) # retcode: Success

then when I check

sol[X][1]

I get 3.0 (which is different from the initial condition I gave)

@ChrisRackauckas
Copy link
Member

That's a bug because it simplifies down to a pure ODE and then doesn't run the initialization consistency check that DAEs do. Maybe I can address that in #2591

ChrisRackauckas added a commit that referenced this issue Jul 6, 2024
InitializationProblem is not always built, however it missed a case. If you have an ODE and you define all of the initial conditions, then it does not need an initialization problem. But, if you simplify down to an ODE and give initial conditions for all of the original variables, including some simplified out, then you have defined initial conditions on some observed quantities and that needs to be accounted for by an initialization process.

This fixes #2619
ChrisRackauckas added a commit that referenced this issue Jul 22, 2024
InitializationProblem is not always built, however it missed a case. If you have an ODE and you define all of the initial conditions, then it does not need an initialization problem. But, if you simplify down to an ODE and give initial conditions for all of the original variables, including some simplified out, then you have defined initial conditions on some observed quantities and that needs to be accounted for by an initialization process.

This fixes #2619
ChrisRackauckas added a commit that referenced this issue Jul 27, 2024
InitializationProblem is not always built, however it missed a case. If you have an ODE and you define all of the initial conditions, then it does not need an initialization problem. But, if you simplify down to an ODE and give initial conditions for all of the original variables, including some simplified out, then you have defined initial conditions on some observed quantities and that needs to be accounted for by an initialization process.

This fixes #2619
ChrisRackauckas added a commit that referenced this issue Sep 6, 2024
InitializationProblem is not always built, however it missed a case. If you have an ODE and you define all of the initial conditions, then it does not need an initialization problem. But, if you simplify down to an ODE and give initial conditions for all of the original variables, including some simplified out, then you have defined initial conditions on some observed quantities and that needs to be accounted for by an initialization process.

This fixes #2619
BenChung pushed a commit to BenChung/ModelingToolkit.jl that referenced this issue Sep 24, 2024
InitializationProblem is not always built, however it missed a case. If you have an ODE and you define all of the initial conditions, then it does not need an initialization problem. But, if you simplify down to an ODE and give initial conditions for all of the original variables, including some simplified out, then you have defined initial conditions on some observed quantities and that needs to be accounted for by an initialization process.

This fixes SciML#2619
No Sign up for free to join this conversation on GitHub. Already have an account? No Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants