-
-
Notifications
You must be signed in to change notification settings - Fork 217
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
Comments
What is the weird behavior? |
Here, if you provide an initial guess for (This might make sense for someone more involved, but encountered it when running various tests, and figured that it seemed weird) |
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/ |
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 |
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 |
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
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
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
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
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
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:
The text was updated successfully, but these errors were encountered: