Skip to content

Bump compat for OrdinaryDiffEq v7 / SciMLBase v3 ecosystem - #445

Merged
ChrisRackauckas merged 4 commits into
SciML:mainfrom
ChrisRackauckas-Claude:bump-ordinarydiffeq-v7-ecosystem
May 1, 2026
Merged

Bump compat for OrdinaryDiffEq v7 / SciMLBase v3 ecosystem#445
ChrisRackauckas merged 4 commits into
SciML:mainfrom
ChrisRackauckas-Claude:bump-ordinarydiffeq-v7-ecosystem

Conversation

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member

Summary

  • Bump OrdinaryDiffEq compat from "6.87" to "6, 7" (main and docs)
  • Bump OrdinaryDiffEqDefault compat from "1.1" to "1, 2"
  • Add OrdinaryDiffEqRosenbrock and OrdinaryDiffEqBDF as test dependencies with compat "1, 2"
  • Add explicit using OrdinaryDiffEqRosenbrock: Rodas4/Rodas5 and using OrdinaryDiffEqBDF: DFBDF imports in all affected test files

Motivation

OrdinaryDiffEq v7 (refs SciML/OrdinaryDiffEq.jl#3562 and #3565) narrows the default exports from using OrdinaryDiffEq to only: DefaultODEAlgorithm, Tsit5, AutoTsit5, Vern6Vern9, Rosenbrock23, Rodas5P, FBDF. Solvers like Rodas4, Rodas5, and DFBDF now require explicit sub-package imports. The new major versions are:

  • OrdinaryDiffEq → 7
  • OrdinaryDiffEqDefault → 2
  • OrdinaryDiffEqRosenbrock → 2
  • OrdinaryDiffEqBDF → 2

See the NEWS.md for the full list of breaking changes.

Test plan

  • Pkg.test() passes with OrdinaryDiffEq v7
  • Compat bounds allow both v6 and v7 (backward compatible)
  • All test files that use Rodas4, Rodas5, or DFBDF have explicit sub-package imports

🤖 Generated with Claude Code

- Bump OrdinaryDiffEq compat from "6.87" to "6, 7"
- Bump OrdinaryDiffEqDefault compat from "1.1" to "1, 2"
- Add OrdinaryDiffEqRosenbrock and OrdinaryDiffEqBDF as test dependencies
  with compat "1, 2" (needed because OrdinaryDiffEq v7 no longer exports
  Rodas4/Rodas5/DFBDF from the main package; add explicit sub-package imports
  in all affected test files)
- Update docs/Project.toml OrdinaryDiffEq compat to "6, 7"

Refs SciML/OrdinaryDiffEq.jl#3562 and #3565.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
`DiffEqBase = "6.189.1"` was capped at v6, causing the resolver to
pick the v6 ecosystem (DiffEqBase v6, SciMLBase v2) and fail at
`LateBindingUpdateU0PContext` in MTKBase precompile.

Changed `DiffEqBase = "6.189.1"` → `"6.189.1, 7"` so the resolver
can pick DiffEqBase v7.0.0, which pulls SciMLBase v3.6.0 and the
full v7 SciML ecosystem consistent with the OrdinaryDiffEq v7 compat
already present.

Verified by Manifest resolution: DiffEqBase v7.0.0, SciMLBase v3.6.0.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
1. Widen ChainRulesCore compat from "1.24" to "1":
   The alldeps CI job (job 73119426790) fails because with Symbolics
   pinned to 7.4.1 (its minimum), the resolver pulls DataInterpolations
   8.7.0+ which requires ChainRulesCore >=1.25. Our compat entry
   "1.24" is a single-minor pin that blocks 1.25+. MTKStdlib only uses
   ChainRulesCore.frule (stable since 1.0), so widening to "1" is safe.

2. Fix docs/Project.toml ModelingToolkit compat "10" → "11":
   The docs instantiation (job 73119426967) fails with
   'Unsatisfiable requirements for ModelingToolkit': Symbolics 7.4.1+
   requires ModelingToolkit >=11, but docs/Project.toml said "10".
   The main Project.toml already says ModelingToolkit = "11".

The StochasticDelayDiffEq precompile failure (job 73119426798,
StochasticDelayDiffEq v1.13.0 missing handle_callback_modifiers! from
StochasticDiffEq v6.102.0) is in a transitive dep of the MTK
downstream test suite — not in MTKStdlib's code or compat — and is
out of scope for this PR.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
OrdinaryDiffEq v7 only re-exports a small surface (DefaultODEAlgorithm,
Tsit5, AutoTsit5, Vern6-9, Rosenbrock23, Rodas5P, FBDF). Tests were
relying on it to pull in SciMLBase, ImplicitMidpoint and NLNewton, which
no longer works.

- Add OrdinaryDiffEqSDIRK / OrdinaryDiffEqNonlinearSolve / SciMLBase to
  test extras + targets, with v1/v2 and v2/v3 compat respectively.
- Import ImplicitMidpoint from OrdinaryDiffEqSDIRK in
  test/Mechanical/translational_modelica.jl.
- Import NLNewton from OrdinaryDiffEqNonlinearSolve in
  test/Hydraulic/isothermal_compressible.jl.
- Add `using SciMLBase` to the nine test files that reference
  SciMLBase.successful_retcode / SciMLBase.FullSpecialize.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
@ChrisRackauckas
ChrisRackauckas merged commit afba3fe into SciML:main May 1, 2026
6 of 11 checks passed
ChrisRackauckas-Claude pushed a commit to ChrisRackauckas-Claude/ModelingToolkitStandardLibrary.jl that referenced this pull request May 1, 2026
After the v7 import fixes (SciML#445) and docs fixes (SciML#448, SciML#449), several
Tests jobs hit `ExtraVariablesSystemException` from MTK 11's stricter
mtkcompile balance check. The dangling variables aren't bugs in the
test models — they're sensor / output connectors that the test never
consumes — so mark them as `outputs=` (excluded from the balance check)
or pass `fully_determined=false`:

- `test/Blocks/utils.jl` "SISO Check": `outputs = [so.output.u]`
- `test/Thermal/thermal.jl` "Heat flow system":
  `outputs = [mass1.T, hf_sensor2.port_b.Q_flow]`
- `test/Mechanical/rotational.jl` "sensors": `fully_determined=false`
  (11 dangling sensor variables make an `outputs=` listing impractical)
- `test/Mechanical/translational.jl` "AccelerationSensor":
  `mtkcompile(sys; fully_determined = false)`

Two further test failures are upstream-only and not addressed here:
- `test/Blocks/sources.jl` BSplineInterpolation / Initialization:
  SymbolicUtils `MethodError: fntype_X_Y(::Type{Real})` from
  `promote_symtype` when MTK substitutes through a callable parameter
  of a `ParametrizedInterpolation`. Needs a SymbolicUtils fix.
- `test/Blocks/test_analysis_points.jl` `get_looptransfer`: MTK
  initialization rejects with "Cyclic guesses detected" inside
  `varmap_to_vars`. Needs an MTK fix or explicit `missing_guess_value`.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
ChrisRackauckas-Claude pushed a commit to ChrisRackauckas-Claude/ModelingToolkitStandardLibrary.jl that referenced this pull request May 1, 2026
After the v7 import fixes (SciML#445) and docs fixes (SciML#448, SciML#449), several
Tests jobs hit `ExtraVariablesSystemException` from MTK 11's stricter
mtkcompile balance check. The dangling variables aren't bugs in the
test models — they're sensor / output connectors the test never feeds
back, so semantically they're outputs. Declare them via `outputs=` so
mtkcompile excludes them from the balance check (no `fully_determined=false`,
no skipped tests):

- `test/Blocks/utils.jl` "SISO Check": `outputs = [so.output.u]`.
- `test/Thermal/thermal.jl` "Heat flow system":
  `outputs = [mass1.T, hf_sensor2.port_b.Q_flow]`.
- `test/Mechanical/rotational.jl` "sensors": switch from `@mtkcompile`
  to `@named model = Sensors(); sys = mtkcompile(model; outputs = [...])`
  listing the 11 dangling sensor/connector variables.
- `test/Mechanical/translational.jl` "AccelerationSensor":
  `outputs = [mass.v, mass.flange.s]`.

Two further test failures remain on this PR (intentionally — not
disabled, not skipped) and are upstream-blocked:
- `test/Blocks/sources.jl` BSplineInterpolation / Initialization:
  SymbolicUtils `MethodError: fntype_X_Y(::Type{Real})` from
  `promote_symtype` when MTK substitutes through a callable parameter
  of a `ParametrizedInterpolation`. Root cause is in SymbolicUtils
  (and/or the `(interpolator::interp_type)(..)::eltype(u)` declaration
  in `src/Blocks/sources.jl`).
- `test/Blocks/test_analysis_points.jl` `get_looptransfer`: MTK
  initialization rejects with "Cyclic guesses detected" inside
  `varmap_to_vars`. Needs an MTK fix or an explicit
  `missing_guess_value`.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
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