Bump the all-julia-packages group across 1 directory with 2 updates

[dependabot]

Updates the requirements on DiffEqBase and SciMLBase to permit the latest version.
Updates DiffEqBase to 7.0.0

Changelog

Sourced from DiffEqBase's changelog.

OrdinaryDiffEq.jl v7 Breaking Changes

This release bumps to SciMLBase v3, RecursiveArrayTools v4, and includes breaking changes across DiffEqBase, OrdinaryDiffEqCore, and all solver sublibraries.

Themes of the v7 release

Most of the breaking changes fall into a small set of recurring themes. Keep these in mind while reading the migration table — they explain why an individual change exists and often suggest the right migration direction:

• Time to first solve (TTFS) reduction. Direct deps on Static.jl, StaticArrayInterface.jl, Polyester.jl, and StaticArrays.jl were dropped; using OrdinaryDiffEq now loads only the default solver set; ODEFunction switched to AutoSpecialize. All of this means less code loaded and more precompilation caching on first solve.
• Type stability everywhere. All Bool solver/solve keyword arguments (autodiff, verbose, alias, lazy, …) were replaced by typed objects. Passing a Bool no longer changes dispatch in ways the compiler cannot specialize on, and the reverse is no longer allowed to silently fall back through slow generic paths.
• Generality beyond ForwardDiff. chunk_size, diff_type, standardtag, etc. encoded ForwardDiff-specific or FiniteDiff-specific knobs on every solver. They are replaced by the ADTypes interface (AutoForwardDiff, AutoFiniteDiff, AutoEnzyme, AutoZygote, …) so every solver automatically generalizes to any AD backend.
• Controller is now an object, not a pile of solve kwargs. gamma, beta1, beta2, qmin, qmax, qsteady_min, qsteady_max, qoldinit were moved onto concrete PIController / PIDController / IController / PredictiveController structs, and EEst moved to the controller cache. This is prep work for pluggable controllers and removes a large amount of dead state from the integrator struct.
• Cleanup of old re-exports / deprecations. Functions like has_destats (now has_stats), sol.destats (now sol.stats), DEAlgorithm/DEProblem/DESolution abstract types, tuples()/intervals(), QuadratureProblem, fastpow, concrete_solve, etc. were on a deprecation path for one or more minor releases. v7 removes them.

Recommended upgrade path

The cleanest path is not to jump straight from an old environment onto v7. Most renamed APIs (e.g. DEAlgorithm → AbstractDEAlgorithm, u_modified! → derivative_discontinuity!, has_destats → has_stats, sol.destats → sol.stats, the construct* tableau functions, alias_u0/alias_du0, beta1/beta2, PID kwargs) already exist under their new names in SciMLBase v2 / OrdinaryDiffEq v6 with deprecation warnings. The recommended sequence is:

1. Stay on SciMLBase v2 / OrdinaryDiffEq v6. Update your code to the new names (has_stats, sol.stats, AbstractDEAlgorithm, derivative_discontinuity!, ODEAliasSpecifier, ODEVerbosity, ADTypes-based autodiff, explicit controller = … objects, new tableau names) while the deprecation shims still exist.
2. Verify your tests pass on v6 with no deprecation warnings.
3. Then bump to v7. At this point your code should compile and run against v7 without further changes aside from the genuinely new breakage (RAT v4 array semantics, ensemble prob_func/output_func signature, struct type parameter removals, kwargs that truly no longer exist, default changes like CheckInit and williamson_condition=false).

Doing it in two steps keeps the diff small per step and lets the deprecation warnings on v6 point you at the exact call sites that will break on v7.

Fallback for RAT v4 indexing

If you cannot update sol[i] / length(sol) / eachindex(sol) call sites yet (see the RAT v4 table below), you can opt back into v3 semantics on a per-solution basis by converting the container type to the ragged variant:

using RecursiveArrayToolsRaggedArrays
sol_old = RaggedVectorOfArray(sol)   # indexes like v3: sol_old[i] is the i-th timestep

RecursiveArrayToolsRaggedArrays.jl preserves the previous AbstractVectorOfArray indexing behavior (timestep-first, not element-first). This is the escape hatch for code that assumes sol[i] returns the i-th timestep. It is, however, recommended that you update to the sol.u[i] / sol[:, i] style — the ragged wrapper is a compatibility layer, not the canonical API going forward.

---

RecursiveArrayTools v4

ODESolution is now an AbstractArray

AbstractVectorOfArray (the parent type of ODESolution, RODESolution, DAESolution, etc.) now subtypes AbstractArray. This changes the semantics of several common operations:

Operation	v3 (old)	v4 (new)	Migration
sol[i]	Returns i-th timestep (Vector)	Returns i-th scalar element (column-major)	Use sol.u[i] or sol[:, i]
length(sol)	Number of timesteps	prod(size(sol)) (total elements)	Use length(sol.t) or length(sol.u)
eachindex(sol)	1:nsteps	CartesianIndices(size(sol))	Use eachindex(sol.u)
iterate(sol)	Iterates over timesteps	Iterates over scalar elements	Use for u in sol.u
first(sol) / last(sol)	First/last timestep	First/last scalar element	Use first(sol.u) / last(sol.u)

... (truncated)

Commits

• See full diff in compare view

Updates SciMLBase to 3.4.2

Release notes

Sourced from SciMLBase's releases.

v3.4.2

SciMLBase v3.4.2

Diff since v3.4.1

Merged pull requests:

• Fix ntuple(Val(-1)) in RODE calculate_solution_errors! for scalar noise (#1324) (@​ChrisRackauckas-Claude)

Commits

• 58a7b2b Merge pull request #1324 from ChrisRackauckas-Claude/fix-scalar-rode-errcalc-...
• 8ab9dd2 Apply suggestion from @​ChrisRackauckas
• d86fd28 Apply suggestion from @​ChrisRackauckas
• 703dd06 Apply suggestion from @​ChrisRackauckas
• 9475bb4 Fix ntuple(Val(-1)) in RODE calculate_solution_errors! for scalar noise
• c803b74 Merge pull request #1323 from ChrisRackauckas-Claude/add-daeproblem-specializ...
• 81b49ae Make DAEProblem{iip} AutoSpecialize default explicit
• 92274de Add DAEProblem{iip, specialize} two-parameter constructor
• ca95e2e Merge pull request #1322 from ChrisRackauckas-Claude/fix-iterate-timeseriesol...
• a2cce0e Apply suggestions from code review
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot recreate.

[dependabot]

Looks like these dependencies are no longer updatable, so this is no longer needed.