Skip to content

Replace OrdinaryDiffEq weakdep with OrdinaryDiffEqSymplecticRK#496

Open
ChrisRackauckas-Claude wants to merge 1 commit intoTuringLang:mainfrom
ChrisRackauckas-Claude:bump-ordinarydiffeq-v7-compat
Open

Replace OrdinaryDiffEq weakdep with OrdinaryDiffEqSymplecticRK#496
ChrisRackauckas-Claude wants to merge 1 commit intoTuringLang:mainfrom
ChrisRackauckas-Claude:bump-ordinarydiffeq-v7-compat

Conversation

@ChrisRackauckas-Claude
Copy link
Copy Markdown

@ChrisRackauckas-Claude ChrisRackauckas-Claude commented May 5, 2026

Note

This PR should be ignored until reviewed by @ChrisRackauckas.

Summary

Replaces the OrdinaryDiffEq weakdep with the smaller OrdinaryDiffEqSymplecticRK sub-package. The DiffEqIntegrator extension only ever used the symplectic solvers (VerletLeapfrog and friends) plus the standard init / step! / DynamicalODEProblem interface — none of which requires the full meta-package.

Why

  • Lighter dep graph. Users no longer pull in BDF, Rosenbrock, Tsit5, Verner, Default, OrdinaryDiffEqCore, NonlinearSolve, LinearSolve, etc. just to use a leapfrog inside HMC.
  • Honest deps. The extension actually only uses symplectic RK methods.
  • Sidesteps the OrdinaryDiffEq v6 ↔ v7 compat ratchet entirely. OrdinaryDiffEqSymplecticRK v1 (built against OrdinaryDiffEq v6) and v2 (built against v7) both expose the same surface, so compat is just "1, 2".
  • Aligns with the v7 ecosystem story. In OrdinaryDiffEq v7, VerletLeapfrog no longer re-exports out of OrdinaryDiffEq itself (it lives in the symplectic sublib). Depending on the sublib directly is the forward-compatible shape.
  • Unblocks downstream Turing v0.45 + SciML stack composition (e.g. SciMLExpectations.jl/docs), where Turing 0.45 → AdvancedHMC ≥ 0.8.3 and OrdinaryDiffEq 7 cannot currently coexist due to the OrdinaryDiffEq = "6" weakdep compat.

Changes

  • Project.toml: weakdep OrdinaryDiffEqOrdinaryDiffEqSymplecticRK; extension entry, compat ("1, 2"), and [extras] updated.
  • ext/AdvancedHMCOrdinaryDiffEqExt.jlext/AdvancedHMCOrdinaryDiffEqSymplecticRKExt.jl (rename + module name + import).
  • test/runtests.jl, test/integrator.jl: switch using OrdinaryDiffEq to using OrdinaryDiffEqSymplecticRK.
  • src/AdvancedHMC.jl: register_error_hint message updated ("Did you forget to load OrdinaryDiffEqSymplecticRK?").
  • src/integrator.jl: inline comment updated.

Verification

Tested locally on Julia 1.10:

  • AHMC_TEST_GROUP=AdvancedHMC test suite: 5052 tests, exit 0, no errors.
  • Integrator testset: 35/35 pass.
  • Numerical equivalence check (independent script): DiffEqIntegrator(VerletLeapfrog()) produces bit-identical trajectories to native Leapfrog over 1000 steps; Hamiltonian drift ~1.7e-5 over the same trajectory.

Relation to existing CompatHelper PRs

CompatHelper opened #494 and #495 with the simpler compat-only bump on the OrdinaryDiffEq weakdep ("6""6, 7"). That approach works but keeps the whole meta-package as a dep, and breaks the existing test/integrator.jl test which references OrdinaryDiffEq.VerletLeapfrog (in v7 that name moved to OrdinaryDiffEqSymplecticRK). This PR avoids both problems by depending on the sublib directly. Closing #494 and #495 in favor of this would be reasonable.

Test plan

  • Extension precompiles against both OrdinaryDiffEqSymplecticRK v1 and v2
  • Full AdvancedHMC test group passes locally on Julia 1.10
  • DiffEqIntegrator(VerletLeapfrog()) matches native Leapfrog numerically
  • CI: GitHub Actions (Julia 1, min, pre × ubuntu/macOS/windows)
  • CI: buildkite CUDA tests

🤖 Generated with Claude Code

The DiffEqIntegrator extension only ever used the symplectic solvers
(VerletLeapfrog and friends) plus the standard `init`/`step!`/
`DynamicalODEProblem` interface. None of that requires the full
OrdinaryDiffEq meta-package; everything lives in or is re-exported by
OrdinaryDiffEqSymplecticRK.

Switching the weakdep from OrdinaryDiffEq → OrdinaryDiffEqSymplecticRK:

- Drops the heavy meta-package: users no longer pull in BDF, Rosenbrock,
  Tsit5, Verner, Default, OrdinaryDiffEqCore, NonlinearSolve, LinearSolve,
  etc. just to use a leapfrog integrator inside HMC.
- Makes the dependency graph honest about what the extension actually
  uses (symplectic RK methods only).
- Sidesteps the OrdinaryDiffEq v6 ↔ v7 compat ratchet entirely:
  OrdinaryDiffEqSymplecticRK v1 (works against OrdinaryDiffEq v6) and v2
  (works against v7) both expose the same surface, so compat is just
  `"1, 2"`.
- Aligns with the v7 ecosystem story: in v7 `VerletLeapfrog` no longer
  re-exports out of OrdinaryDiffEq itself (it lives in the symplectic
  sublib), so depending on the sublib directly is the forward-compatible
  shape.

Renames:
- weakdep `OrdinaryDiffEq` → `OrdinaryDiffEqSymplecticRK`
- extension module `AdvancedHMCOrdinaryDiffEqExt` →
  `AdvancedHMCOrdinaryDiffEqSymplecticRKExt`
- extension file matched

Updates `test/runtests.jl`, `test/integrator.jl`, the
`register_error_hint` message, and the inline source comment in
`src/integrator.jl` to refer to the new package name.

Verified locally on Julia 1.10:
- AHMC_TEST_GROUP=AdvancedHMC: 5052 tests, exit 0, no errors
- Integrator subtests: 35/35 pass
- Numerical equivalence: DiffEqIntegrator(VerletLeapfrog()) matches
  native Leapfrog bit-for-bit over 1000 steps; Hamiltonian drift
  ~1.7e-5 over the same trajectory.

Unblocks downstream Turing v0.45 + SciML stack composition (e.g.
SciMLExpectations.jl docs).

Co-Authored-By: Chris Rackauckas <[email protected]>
@ChrisRackauckas-Claude ChrisRackauckas-Claude force-pushed the bump-ordinarydiffeq-v7-compat branch from fa28d9f to 3bb142f Compare May 5, 2026 19:14
@ChrisRackauckas-Claude ChrisRackauckas-Claude changed the title Bump OrdinaryDiffEq weakdep compat to "6, 7" Replace OrdinaryDiffEq weakdep with OrdinaryDiffEqSymplecticRK May 5, 2026
@ChrisRackauckas-Claude ChrisRackauckas-Claude marked this pull request as ready for review May 5, 2026 19:17
@ChrisRackauckas
Copy link
Copy Markdown
Contributor

This version I think is better, just moving to the smaller dep that you actually use. I think this is good to go.

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