Skip to content

Fix Rosenbrock convergence-order test flakiness (Rodas6P dts + Rodas5P+Krylov tol)#3528

Merged
ChrisRackauckas merged 2 commits intoSciML:masterfrom
ChrisRackauckas-Claude:fix-rodas6p-order-regression
Apr 23, 2026
Merged

Fix Rosenbrock convergence-order test flakiness (Rodas6P dts + Rodas5P+Krylov tol)#3528
ChrisRackauckas merged 2 commits intoSciML:masterfrom
ChrisRackauckas-Claude:fix-rodas6p-order-regression

Conversation

@ChrisRackauckas-Claude
Copy link
Copy Markdown
Contributor

Summary

Four @test assertions in lib/OrdinaryDiffEqRosenbrock/test/ode_rosenbrock_tests.jl have been failing on #3521 (and #3520 before it):

  • L212 / L222Rodas6P on prob_ode_linear / prob_ode_2Dlinear, measured L2 ≈ 5.44 / 5.51 vs expected ≈ 6 ± 0.2.
  • L270 / L283Rodas5P with KrylovJL() / KrylovJL_GMRES() linsolve, measured L2 ≈ 2.83 vs expected ≈ 5 ± 0.2.

Both are test-setup issues, not solver regressions. Confirmed by reproducing the same 5.44/5.51 slope on the released OrdinaryDiffEqRosenbrock v1.26.0 — so this is not a regression from the tableau-sublibrary refactor (#3509/#3511) or the controller-cache refactor (#3422). The Rodas6P test has been flaky ever since Gerd Steinebach flipped the expected order from 5 to 6 in 10be42a, one day after landing Rodas6P.

Root causes

  1. Rodas6P (L212/L222). With dts = (1/2).^(6:-1:3), the smallest step (1/64) drives the error on these tiny linear problems to Float64 roundoff (~1e-15), corrupting the log-log slope. Widening to dts = (1/2).^(5:-1:2) (smallest 1/32) stays above roundoff and yields L2 ≈ 6.07 on both problems — comfortably within atol = 0.2.
  2. Rodas5P + Krylov (L270/L283). LinearSolve now respects the requested reltol/abstol, so the default-tolerance inner Krylov solve clips the outer Rosenbrock order to ~2.83. Passing reltol = 1e-14, abstol = 1e-14 — the same fix applied at L319 for Rodas3 in 6fe7343 — restores L2 ≈ 5.004.

Verified locally on Julia 1.12.6

L212: Rodas6P linear    L2 = 6.072619418560989    (expected ≈ 6)
L222: Rodas6P 2Dlinear  L2 = 6.072276736140377    (expected ≈ 6)
L270: Rodas5P+KrylovJL       L2 = 5.004392395316728  (expected ≈ 5)
L283: Rodas5P+KrylovJL_GMRES L2 = 5.004392395316728  (expected ≈ 5)

testTol = 0.2 is unchanged. No solver code modified.

Test plan

  • CI test (OrdinaryDiffEqRosenbrock, 1) passes on Julia 1.12.6 (Core group).
  • All previously failing assertions (L212, L222, L270, L283) now report the new measured orders shown above.

🤖 Generated with Claude Code

Four convergence assertions in lib/OrdinaryDiffEqRosenbrock/test/ode_rosenbrock_tests.jl
(lines 212/222 for Rodas6P, 270/283 for Rodas5P+Krylov) were failing because of
issues in the test setup, not regressions in the solver code.

1. Rodas6P (L212/L222): with dts = (1/2).^(6:-1:3), the smallest step (1/64)
   brings error on the tiny prob_ode_linear/2Dlinear problem down to Float64
   roundoff (~1e-15), corrupting the log-log slope. Measured L2 was ~5.4-5.5;
   the test expected ~6. Widening to dts = (1/2).^(5:-1:2) (smallest = 1/32)
   stays above roundoff and gives L2 ≈ 6.07 as expected. Reproduced the same
   5.44/5.51 slope on released OrdinaryDiffEqRosenbrock v1.26.0, confirming
   this is not a regression from the tableau sublibrary refactor (SciML#3509/SciML#3511)
   or the controller-cache refactor (SciML#3422) — the test has been flaky since
   Gerd Steinebach changed the expected order from 5 to 6 in 10be42a,
   right after landing Rodas6P.

2. Rodas5P + KrylovJL / KrylovJL_GMRES (L270/L283): LinearSolve now enforces
   the requested reltol/abstol on Krylov iterations, so the default-tolerance
   inner solve clips outer-method accuracy to ~2.8 order. Passing
   reltol=1e-14, abstol=1e-14 (same pattern as the Rodas3+Krylov test at
   L319, fixed in 6fe7343) restores L2 ≈ 5.004.

testTol is unchanged at 0.2. No solver code was modified.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Comment thread lib/OrdinaryDiffEqRosenbrock/test/ode_rosenbrock_tests.jl Outdated
@ChrisRackauckas ChrisRackauckas merged commit dbced3e into SciML:master Apr 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants