Fix OrdinaryDiffEqExplicitTableaus test env [sources] path to top-level OrdinaryDiffEq#3511
Merged
ChrisRackauckas merged 1 commit intoSciML:masterfrom Apr 23, 2026
Conversation
…el OrdinaryDiffEq
The sublibrary's `[sources]` entry for OrdinaryDiffEq pointed at
`../OrdinaryDiffEq`, which would be `lib/OrdinaryDiffEq` from the
sublibrary dir — but OrdinaryDiffEq is the monorepo root, not a sibling
under `lib/`. This made `Pkg.test` on the sublibrary fail immediately
with:
ERROR: expected package `OrdinaryDiffEq [1dea7af3]` to exist at
path `.../lib/OrdinaryDiffEq`
Both `test (OrdinaryDiffEqExplicitTableaus, …)` and
`test (OrdinaryDiffEqExplicitTableaus_QA, …)` hit this because they
both activate the same Project.toml via `Pkg.test`.
Fix: point `OrdinaryDiffEq` at `../..` — the repo root — matching the
pattern used in `lib/DiffEqDevTools/Project.toml` and
`lib/StochasticDiffEq/Project.toml`.
Also bump the test-only `ODEProblemLibrary` compat from `"0.1"` to
`"1"` so the test env can actually resolve against the v7
OrdinaryDiffEq / DiffEqBase 7 chain. Every other sublib already
pins ODEProblemLibrary to `"1"`; `0.1` is incompatible with DiffEqBase
7 and turns the path fix into an immediate resolver failure. Without
this, the path fix alone would still leave the CI jobs red for a
different reason.
Verified locally with `Pkg.activate("lib/OrdinaryDiffEqExplicitTableaus"); Pkg.instantiate()`
succeeds, and `Pkg.test` now gets past resolution to actual test code
(further test failures are real OrdinaryDiffEq v7 migration issues,
out of scope for this fix).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
2 tasks
ChrisRackauckas
added a commit
that referenced
this pull request
Apr 23, 2026
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 (#3509/#3511) or the controller-cache refactor (#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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
[sources]entry forOrdinaryDiffEqinlib/OrdinaryDiffEqExplicitTableaus/Project.tomlpointed at../OrdinaryDiffEq, which resolves tolib/OrdinaryDiffEq— butOrdinaryDiffEqis the top-level of the monorepo, not a sibling sublibrary. This made bothtest (OrdinaryDiffEqExplicitTableaus, …)andtest (OrdinaryDiffEqExplicitTableaus_QA, …)fail on PR NEWS: before/after code example for StochasticDelayDiffEq → DelayDiffEq migration #3508 with:../..(repo root), matching the working pattern inlib/DiffEqDevTools/Project.tomlandlib/StochasticDiffEq/Project.toml.[compat] ODEProblemLibraryfrom"0.1"to"1". Every other sublibrary already pinsODEProblemLibrary = "1"; the old0.1compat is incompatible with the v7OrdinaryDiffEq/DiffEqBase 7chain and would leave the resolver failing even after the path fix.Scope
UndefVarError: Heun,ExplicitRK, etc.) are separate v7 migration issues and are out of scope.Verification
lib/*/**/Project.tomlforpath = "../OrdinaryDiffEq"— only this one sublibrary had the bug.julia --project=. -e 'using Pkg; Pkg.activate("lib/OrdinaryDiffEqExplicitTableaus"); Pkg.instantiate()'— succeeds.Pkg.test("OrdinaryDiffEqExplicitTableaus")now resolves and proceeds to actual test execution (was previously failing before any test code ran).Test plan
test (OrdinaryDiffEqExplicitTableaus, 1, ubuntu-latest, 120, 1)gets past env setup on CItest (OrdinaryDiffEqExplicitTableaus_QA, 1, ubuntu-latest, 120, 1)gets past env setup on CI🤖 Generated with Claude Code