Tracking: DynamicQuantities × SciML (DiffEq) compatibility rollout

[MilesCranmerBot]

Summary

Tracking issue for the DynamicQuantities × SciML (DiffEq stack) compatibility rollout.

Goal: land a minimal, semantically-correct patch stack across repos to support unitful ODE workflows with DynamicQuantities without type-level zero(::Type{Quantity}) assumptions.

Primary staging reference:

• Bundle PR: DQ×DiffEq: unitful ODE patch stack MilesCranmerBot/dqdeq-units-bundle#1

---

Rollout plan (2 waves)

Wave 1 (root dependency)

• DynamicQuantities.jl PR merged
• DynamicQuantities.jl release/tag published (release process started; tag pending)

Wave 2 (open downstream PRs in parallel after DQ release)

• DiffEqBase.jl PR
• OrdinaryDiffEqCore.jl PR
• OrdinaryDiffEqDifferentiation.jl PR
• (optional) ArrayInterface.jl PR
• (optional) DifferentiationInterface.jl PR

---

Dependency graph

graph TD
  DQ[DynamicQuantities.jl] --> DB[DiffEqBase.jl]
  DQ --> ODEC[OrdinaryDiffEqCore.jl]
  DQ --> ODED[OrdinaryDiffEqDifferentiation.jl]
  DB --> ODED
  DQ --> AI[ArrayInterface.jl]
  DQ --> DI[DifferentiationInterface.jl]

Loading

---

Notes / constraints

• No CI-hack edits in upstream repos just to force green.
• Keep semantic behavior aligned with Unitful/SciML expectations.
• SciML hooks (value, unitfulvalue) for DQ types should be owned by DynamicQuantities via extension (not downstream piracy).
• Prefer minimal per-repo diffs with explicit dependency links in each downstream PR body.

---

PR links

• DynamicQuantities.jl: fix: SciMLBase/RecursiveArrayTools extensions for SciML compatibility #201
• DiffEqBase.jl: fix: add DynamicQuantities extension for unitful factorization paths SciML/DiffEqBase.jl#1293
• OrdinaryDiffEqCore.jl: fix: DynamicQuantities compatibility in core + differentiation paths SciML/OrdinaryDiffEq.jl#3126
• OrdinaryDiffEqDifferentiation.jl: fix: DynamicQuantities compatibility in core + differentiation paths SciML/OrdinaryDiffEq.jl#3126
• ArrayInterface.jl (optional): TBD
• DifferentiationInterface.jl (optional): TBD

[MilesCranmerBot]

Wave 1 PR opened: #201

[MilesCranmerBot]

Wave 2 downstream PRs are now open:

• DiffEqBase: fix: add DynamicQuantities extension for unitful factorization paths SciML/DiffEqBase.jl#1293
• OrdinaryDiffEq (Core + Differentiation paths): fix: DynamicQuantities compatibility in core + differentiation paths SciML/OrdinaryDiffEq.jl#3126

Note: ODE core local test still sees registered DynamicQuantities until the new DQ tag is available; once tag propagates, this should validate on released deps instead of source overrides.

[MilesCranmer]

@MilesCranmerBot are the ArrayInterface.jl ones actually optional? I was confused by that comment in the issue body. I remember from the stacked PR discussion we needed it, did we not? Please share any context as necessary.

[MilesCranmerBot]

Yes — for the current DiffEq/OrdinaryDiffEq rollout, the ArrayInterface.jl changes are optional.

Context from the stacked/bundle PR: we initially hit failures because ArrayInterface’s constructors (, , ) allocate caches by calling things like / on the element type. For DynamicQuantities quantities that’s intentionally unsupported ( / are undefined because the dimensions are runtime).

In the final wave-2 plan we avoided relying on those ArrayInterface paths for the ODE stack by moving the unitful linear-solve/factorization handling into the SciML side (DiffEqBase ext: value-space factorization via a bridge, plus ODE init/cache tweaks in OrdinaryDiffEq). With that in place, unitful ODEs don’t require ArrayInterface to know about DQ.

So the ArrayInterface PR would be more of a hardening / ecosystem nicety: it makes not error, which could matter for other packages or less-traveled solver/cache paths. But it’s not a blocker for the main ODE compatibility wave.

(For reference, the proposed ArrayInterface ext was basically this: https://raw.githubusercontent.com/MilesCranmerBot/dqdeq-units-bundle/patches/ArrayInterface/ext/ArrayInterfaceDynamicQuantitiesExt.jl.)

[MilesCranmerBot]

Follow-up (my previous comment got mangled by shell backticks):

Yes — for the current DiffEq/OrdinaryDiffEq rollout, the ArrayInterface.jl changes are optional.

Why it came up in the stacked/bundle PR: ArrayInterface’s instance constructors like lu_instance, qr_instance, svd_instance are used for cache allocation and (for some eltypes) they end up calling things like zeros(T, ...) and/or real(T) on the element type T. For DynamicQuantities quantities, zero(::Type{<:Quantity}) / oneunit(::Type{<:Quantity}) are intentionally undefined because the dimensions are runtime-stored.

Why it’s optional now: in the wave-2 plan we avoided relying on those ArrayInterface cache constructors for the main unitful-ODE paths by handling unitful linear solves/factorizations in the SciML side instead (DiffEqBase ext does value-space factorization via a DQUnitlessLU bridge; OrdinaryDiffEqCore avoids type-level identity assumptions during init/caching). With that in place, unitful ODEs don’t require an ArrayInterface patch.

So an ArrayInterface PR would be more of a hardening / ecosystem nicety: it makes ArrayInterface.lu_instance/qr_instance/svd_instance(::Matrix{<:Quantity}) not error, which could matter for other packages or less-traveled solver/cache paths, but it’s not blocking the main ODE compatibility wave.

Reference implementation from the bundle PR: https://raw.githubusercontent.com/MilesCranmerBot/dqdeq-units-bundle/patches/ArrayInterface/ext/ArrayInterfaceDynamicQuantitiesExt.jl