Fix Downgrade CI: bump NonlinearSolve (4.12) and OrdinaryDiffEqSDIRK (1.7) floors#61
Draft
ChrisRackauckas-Claude wants to merge 1 commit into
Draft
Conversation
90b2938 to
7e28710
Compare
…ix Downgrade CI
The Downgrade job fails during precompilation. The old test-dep compat floors
resolve a stale, mutually-inconsistent valley of SciML versions that hits three
distinct precompile failures; each floor bump removes one:
1. NonlinearSolve v3 + new DiffEqBase
v3 does `using DiffEqBase: AbstractNonlinearTerminationMode`, but that type
moved out of DiffEqBase into NonlinearSolveBase. v3's DiffEqBase compat is
under-bounded, so it pairs with a DiffEqBase that no longer defines the symbol:
`UndefVarError: AbstractNonlinearTerminationMode not defined`.
2. NonlinearSolve 4.0.x + NonlinearSolveBase 1.5.x
Both define the same `SciMLBase.__solve(::DualAbstractNonlinearProblem, ...)`
(NonlinearSolve's forward_diff.jl and NonlinearSolveBase's ForwardDiff ext):
`Method overwriting is not permitted during Module precompilation`.
NonlinearSolve 4.12 is the first 4.x requiring NonlinearSolveBase 2, where
that method lives in exactly one place, so (1) and (2) are both avoided.
3. OrdinaryDiffEqSDIRK 1.2.0 + new OrdinaryDiffEqDifferentiation
SDIRK 1.2.0 builds TRBDF2 with a legacy tuple AD field
`(AutoForwardDiff, Val{0}, Val{:forward})` that the resolved
OrdinaryDiffEqDifferentiation 1.16's `prepare_ADType` no longer accepts, so
PDESystemLibrary's top-level `solve(prob, TRBDF2())` in lib/brusselator.jl
dies at precompile with a `prepare_ADType` MethodError. SDIRK 1.7 is the
first version carrying an OrdinaryDiffEqDifferentiation "1.12 - 1" compat
(the modern AD API), which fixes it.
With these floors the downgrade resolves a consistent set (NonlinearSolve 4.12.0
/ NonlinearSolveBase 2.2.0 / OrdinaryDiffEqSDIRK 1.7.0 /
OrdinaryDiffEqDifferentiation 1.16.1 / OrdinaryDiffEq 6.97.0 / DiffEqBase
6.202.0 / ModelingToolkit 9.50.0 / SciMLBase 2.116.0) that precompiles cleanly
on Julia 1.10 (verified locally, including PDESystemLibrary itself). The
non-downgrade builds already resolve NonlinearSolve 4.19.x and SDIRK 2.7.x, so
these floor bumps have no effect on them.
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
7e28710 to
0d5699f
Compare
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
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.
Problem
The
Downgrade / Downgrade Testsjob onmasteris red — it fails during precompilation.Root cause (three interlocking stale-floor incompatibilities)
The old test-dep compat floors make the SciML reusable downgrade workflow (Resolver.jl
--min=@deps) resolve a stale, mutually-inconsistent valley of versions that trips three distinctprecompile failures. Each floor bump removes one:
NonlinearSolve v3 + new DiffEqBase. v3 does
using DiffEqBase: AbstractNonlinearTerminationMode, but that type was moved out ofDiffEqBaseinto
NonlinearSolveBase. v3'sDiffEqBasecompat is under-bounded (6.149.0, no upper cap),so the resolver pairs it with DiffEqBase v6.174.0 which no longer defines it:
UndefVarError: AbstractNonlinearTerminationMode not defined.NonlinearSolve 4.0.x + NonlinearSolveBase 1.5.x. Both define the same
SciMLBase.__solve(::DualAbstractNonlinearProblem, alg, ...)(NonlinearSolve'sforward_diff.jland NonlinearSolveBase's ForwardDiff ext):
Method overwriting is not permitted during Module precompilation.OrdinaryDiffEqSDIRK 1.2.0 + new OrdinaryDiffEqDifferentiation. SDIRK 1.2.0 builds
TRBDF2with a legacy tuple AD field
(AutoForwardDiff, Val{0}, Val{:forward})that the resolvedOrdinaryDiffEqDifferentiation1.16'sprepare_ADTypeno longer accepts, so PDESystemLibrary'stop-level
solve(prob, TRBDF2())inlib/brusselator.jldies at precompile with aprepare_ADTypeMethodError.Fix
NonlinearSolveBase = "2"(where__solvelives in exactly one place) — kills (1) and (2).
OrdinaryDiffEqDifferentiation = "1.12 - 1"compat (the modern AD API) — kills (3).With these floors the downgrade resolves a consistent set:
The non-downgrade builds already resolve NonlinearSolve 4.19.x and SDIRK 2.7.x, so these floor bumps
have no effect on them.
Local verification (Julia 1.10.11)
Reproduced the exact CI downgrade by running the real
julia-actions/julia-downgrade-compatdowngrade.jl(mode=deps, Resolver.jl--min=@deps) against the patchedProject.toml, thenprecompiling the resolved environment. Result: 0 packages failed (
✗), and none of the threeerrors above appear. Critically,
PDESystemLibraryitself precompiled✓— its top-levelsolve(prob, TRBDF2())(the call that previously threw theprepare_ADTypeMethodError) now runsclean, as do NonlinearSolve / NonlinearSolveBase / OrdinaryDiffEqNonlinearSolve / OrdinaryDiffEqSDIRK.
Please ignore until reviewed by @ChrisRackauckas.
🤖 Generated with Claude Code