Skip to content
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

Rosenbrock23 gives incorrect results for simple DAE #2074

Closed
oscardssmith opened this issue Nov 30, 2023 · 5 comments
Closed

Rosenbrock23 gives incorrect results for simple DAE #2074

oscardssmith opened this issue Nov 30, 2023 · 5 comments
Labels

Comments

@oscardssmith
Copy link
Contributor

oscardssmith commented Nov 30, 2023

using OrdinaryDiffEq, LinearAlgebra
J = [0.0 0.0 1.0 0.0; 
    0.0 0.0 0.0 1.0; 
    1.0 -1.0 0.0 -1;
    -1.0 -1.0 -1e-3 0.0]
f(du, u, _, t) = du .= J*u + [0.0, 0.0, 0.0, sin(t)]
u0 = [0.,0., 1.,1.]
prob = ODEProblem(ODEFunction(f; mass_matrix=mass_matrix=Diagonal([1,1,0,0])), u0, (0.0,2pi))
sol = solve(prob, Rosenbrock23(), dense=false);
length(sol.t) #2798
sol2 = solve(prob, Rodas5P(), dense=false);
length(sol2.t) #47

yields (note the glitches which are way more than the 1e-6 tolerance in Rosenbrock23))
image

with a slightly different jacobian where it does fine.

J = [0.0 0.0 1.0 0.0; 
    0.0 0.0 0.0 1.0; 
    1.0 -1.0 0.0 -1;
    -1.0 -1.0 -1.0 0.0]
@topolarity
Copy link

topolarity commented Nov 30, 2023

The unexpected part here are the glitches at ~t=1.7 and ~4.8

@oscardssmith
Copy link
Contributor Author

The glitches are fixed with #2079, but the number of steps increase to ~3400. Interestingly, Rodas4 and Rodas5 both take significantly more steps than Rodas4P/Rodas5P here (760 and 360 vs 53 and 52 respectively). As such, I think it might be an inherent issue with Rosenbrock23 rather than a simple bug.

@ChrisRackauckas
Copy link
Member

For Rodas4/Rodas5, f(du, u, _, t) = du .= J*u + [0.0, 0.0, 0.0, sin(t)] yes this is inherent to the method. #1602 is a deep dive into that. This is the reason the P methods are preferred, and Rodas5P was fixed specifically to fix the fact that sin(t), cos(t), or anything with a taylor-expansion of t^5 or great gives Rodas4/5 and issue.

For Rosenbrock23 It's just the error control so yes fixed by that PR.

@oscardssmith
Copy link
Contributor Author

This still doesn't explain (to me at least), why Rosenbrock23 needs 3400 timesteps for this ODE while Trapezoid, FBDF, QNDF, and RadauIIA3 all require <200 steps. The only other methods I've found that do worse are ROS34PW1a and ROS34PW1b which are also RosenbrockW methods. Essentially the thing I'm really trying to figure out here is why Rosenbrock23 which usually isn't awful in terms of performance is almost 2 orders of magnitude worse than any of the other go to methods here. Is there a way to maintain the resilience of Rosenbrock23 that doesn't have catastrophic performance for cases like this?

@ChrisRackauckas
Copy link
Member

This is a DAE. Rosenbrock23 isn't stiffly-stable, so it's effectively order 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants