Merged
Conversation
Three changes for v3 compatibility: 1. Replace `DiffEqBase.DEProblem` with `SciMLBase.AbstractDEProblem` in `multiple_shooting_objective` and `two_stage_objective`. The bare `DEProblem` alias is removed in SciMLBase v3; `AbstractDEProblem` is the supported abstract supertype. 2. Port the ensemble tutorial's `prob_func` to the new v3 signature `(prob, ctx)`, using `ctx.sim_id` (previously the `i` argument). 3. Extend SciMLBase compat to `"1.69, 2, 3.1"` and bump version to 2.4.0. Limitations: local tests cannot be run — Pkg resolution fails on any env containing SciMLBase 3.1 because OrdinaryDiffEq still pins RecursiveArrayTools ≤ 3.54 while SciMLBase 3.1 requires RAT v4. This PR is intended to land once upstream OrdinaryDiffEq releases RAT-v4-compatible versions; CI here is the only venue where the full matrix can be tested. Deliberately out of scope for this PR: the `sol[i]` / `length(sol)` / iteration call sites in `cost_functions.jl` and `multiple_shooting_objective.jl`. The behavior of scalar-int indexing on `AbstractTimeseriesSolution` in v3 could not be verified against the SciMLBase v3.1 source (no explicit `Base.getindex(::AbstractTimeseriesSolution, ::Int)` override exists there), and making destructive changes to the cost machinery on an unverified claim would be reckless. Track as a follow-up once CI actually exercises those code paths and either passes or produces concrete failures. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
SciMLBase v3 changes the behavior of single-integer indexing on `AbstractTimeseriesSolution` for non-scalar ODEs: `sol[i]` used to return the i-th state vector (`sol.u[i]`) but now returns the i-th scalar in the flat representation (equivalent to `sol.u[end][end]` for `sol[end]`). Replace `sol[i]` → `sol.u[i]` at the single-int call sites: - `cost_functions.jl` — `length(sol[i])` in the L2Loss timeseries method (both weighted and unweighted branches) and in the diff_weight branch; `logpdf(distributions[i], sol[i])` in LogLikeLoss MultivariateDistribution branch. - `multiple_shooting_objective.jl` — `sol[k][1] - sol[k-1][end]` in the discontinuity penalty, where `sol[k]` is a Julia `Vector`-indexed sub-solution and the subsequent `[1]`/`[end]` are single-int indexing into each ODE solution. Left unchanged: 2-arg `sol[j, i]` indexing (handled by RecursiveArrayTools and unaffected), iteration `for s in sol` on ensemble solutions (ensemble iteration semantics unchanged), `length(sol)` (iteration protocol still per-timestep per SciMLBase v3 `solution_interface.jl:188`), and the NoTime-method `sol[i]` (explicitly defined as `A.u[i]` in v3). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Contributor
Author
This was referenced Apr 13, 2026
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
DiffEqBase.DEProblemwithSciMLBase.AbstractDEProbleminmultiple_shooting_objectiveandtwo_stage_objective. The bareDEProblemalias was removed in SciMLBase v3.prob_func(prob, ctx)signature, usingctx.sim_idinstead of theiargument.SciMLBasecompat to"1.69, 2, 3.1"and bumpDiffEqParamEstimto2.4.0.Supersedes the Project.toml-only bump in #289.
Known limitation — please read before merging
Local
Pkg.resolve()fails on any environment that contains SciMLBase 3.1, becauseSciMLBase3.1 pinsRecursiveArrayTools = 4whileOrdinaryDiffEqin the registry still pinsRecursiveArrayTools ≤ 3.54. CI on this PR will reproduce the same unsatisfiable resolution until upstreamOrdinaryDiffEqreleases a RAT-v4-compatible version.That means:
Pkg.add/instantiatestep with anUnsatisfiable requirements detected for package RecursiveArrayToolserror, not at Julia runtime. OnceOrdinaryDiffEqbumps, re-running CI here should succeed without further edits.What is NOT in this PR (and why)
The
sol[i]/length(sol)/for x in solcall sites insrc/cost_functions.jlandsrc/multiple_shooting_objective.jlare deliberately untouched. I could not conclusively verify in the SciMLBase v3.1 source whether scalar integer indexing onAbstractTimeseriesSolutionchanged behavior — no explicitBase.getindex(::AbstractTimeseriesSolution, ::Int)override is present there. Rewriting the cost-function machinery on an unverified claim would be reckless.Once CI on this PR actually exercises those code paths (either passing silently or producing concrete failures), the real scope of any follow-up work will be visible, and we can land a second PR for cost-function indexing if needed.
Test plan
(prob, ctx)signature.🤖 Generated with Claude Code