Raise ModelingToolkitBase floor for array codegen

[ChrisRackauckas-Claude]

Important

Ignore this draft until it has been reviewed by @ChrisRackauckas.

Summary

• Raise the ModelingToolkitBase compatibility floor from 1.0 to 1.1.
• Add a focused regression that compiles a StateSpace block with array states and constructs its ODEProblem.

Root cause

The minimum-dependency job exposed by NeuralPDE.jl #1084 selected ModelingToolkitBase 1.0.0 together with SymbolicUtils 4.38.1 and OffsetArrays 1.17.0. In that combination, StateSpace and TransferFunction construction passed symbolic array indices directly to an OffsetVector and errored.

ModelingToolkit commit 0182154217a064ea2b99bc230b8a58dabb2442be changed ModelingToolkitBase array-variable assignment to linearize stable symbolic indices through the public SymbolicUtils API. The first ModelingToolkitBase release containing that change is 1.1.0. This PR therefore corrects a false lower-bound compatibility claim within the existing 1.x series; it does not change ModelingToolkitStandardLibrary's public API.

The focused test makes this dependency requirement explicit without relying only on the larger continuous-block suite.

Local verification

I ran the repository's native SciMLTesting harness with Julia 1.10 and the same julia-downgrade-compat@v2 dependency-mode resolver used by CI.

Resolved versions after this change:

• ModelingToolkit 11.2.0
• ModelingToolkitBase 1.1.0
• SymbolicUtils 4.38.1
• OffsetArrays 1.17.0
• SciMLBase 2.125.0

Observed before the floor change, at ModelingToolkitBase 1.0.0:

• Core/continuous.jl: 54 passed, 2 errored in StateSpace and TransferFunction construction.

Observed after the floor change:

• Core/array_state_codegen.jl: 1/1 passed.
• Core/continuous.jl: 76/76 passed.
• The same Core run also passed analog 100/100, Chua 1/1, demo 1/1, digital 34/34, isothermal-compressible 27/27, magnetic 3/3, and math 93/93.

The full Core run then exposed a distinct pre-existing error in Core/motor.jl: _check_if_dde receives ModelingToolkitBase.PleaseImportDynamicQuantities. I separately reproduced that exact error on a clean upstream-main checkout at ModelingToolkitBase 1.0.0, so it is not introduced by this branch. It is being investigated separately under the repository's clean-main failure policy; this PR remains a focused draft and does not claim the complete Core group is green yet.

Formatting verification:

• Runic repository check: 82/82 files passed.
• git diff --check: passed.

Process log

Task prompt: investigate the ModelingToolkitStandardLibrary downgrade failure surfaced while updating the downstream workflow.

1. Synced the fork and created a feature branch from upstream main.
2. Inspected the failing GitHub Actions log and reproduced it locally with the exact downgrade resolver.
3. Traced the exception into ModelingToolkitBase array-state code generation and identified the first fixed release from git history and release tags.
4. Raised the minimum compatible ModelingToolkitBase version and added a focused regression.
5. Re-ran the native Core group under downgraded dependencies, rebased onto the merged isothermal test fix in Fix isothermal domain test connections #478, and repeated verification.
6. Ran Runic across the repository and pushed the two focused commits.

[ChrisRackauckas-Claude]

Investigation checkpoint:

• Reproduced the original minimum-dependency failure with the CI resolver at ModelingToolkitBase 1.0.0: continuous reported 54 pass and 2 errors from symbolic OffsetVector indices.
• Verified from ModelingToolkit history that the stable linear-index fix first shipped in ModelingToolkitBase 1.1.0.
• With the corrected 1.1 floor, the focused regression passes 1/1 and continuous passes 76/76 under the same downgraded dependency set.
• Rebased onto upstream main after Fix isothermal domain test connections #478 merged; the isothermal suite then passed 27/27.
• A later motor failure was reproduced independently on clean upstream main and has been delegated to a separate baseline bisect/fix audit. This draft intentionally remains limited to the array-codegen compatibility floor.
• Repository-wide Runic check passed all 82 files.

[ChrisRackauckas-Claude]

CI checkpoint (Downgrade job):

• Resolver selected ModelingToolkitBase 1.1.0.
• Core/array_state_codegen.jl passed 1/1.
• Core/continuous.jl passed 76/76.
• The job then failed at Core/motor.jl with the same clean-main PleaseImportDynamicQuantities error documented above; no array-codegen failure recurred.

Job: https://github.com/SciML/ModelingToolkitStandardLibrary.jl/actions/runs/29243540209/job/86794967078

The motor baseline audit remains separate, so no unrelated fix is being added to this focused draft.

[ChrisRackauckas-Claude]

CI documentation checkpoint: the failed docs job is the unmodified clean-main documentation baseline, not a ModelingToolkitBase compat regression. It reports the four independently isolated failures:

• ParametrizedInterpolation callable symtype — fixed in source draft Fix callable interpolation builder symtype #480
• position-domain initialization, explicit OnePort bindings, and direct OrdinaryDiffEqSDIRK ownership — fixed in docs draft Repair documentation example setup #481

The stacked #481 documentation job is now green. #482 remains limited to the MTKBase floor/codegen regression; its Core magnetic and downgrade motor blockers are likewise handled separately by the active magnetic audit and #483.

[ChrisRackauckas-Claude]

The delayed ModelingToolkit downstream failure is unrelated to this MTKSL compat-floor change. The outer MTK test process first loads LinearSolve 3.87.0, then the downstream environment resolves 4.3.0; precompiling LinearSolveArnoldiMethodExt against the already-loaded 3.87 module fails because ArnoldiMethodJL was introduced later. All three downstream testsets error at precompile before exercising #482. The same mixed-version failure was independently reduced in closed MTK #4730; the current replacement fix is ModelingToolkit #4742, which broadens the parent test compat so the environments resolve a common current LinearSolve. Exact #482 job

[ChrisRackauckas-Claude]

Rebased onto current main (933a983a) after prerequisite fixes #481, #483, and #484 merged. The feature diff remains limited to the ModelingToolkitBase floor and symbolic-array-state codegen regression test; git diff --check upstream/main...HEAD exits 0. New head: f106c56a (compat commit b9b150ce). This rerun should remove the previously audited documentation, motor, and magnetic failures; the remaining downstream dependency interaction is tracked by ModelingToolkit #4742.

[ChrisRackauckas-Claude]

The rebased red Downgrade and Core / Julia LTS checks now expose the same exact clean-main piston fixture failure; they are not caused by this PR. Both fail test/piston.jl with PleaseImportDynamicQuantities passed as the independent variable into _check_if_dde. Clean main at 933a983a fails identically in all three Core lanes; for example LTS job 86822971377 has the same stack and line.

This is the next fixture after the motor test fixed by merged #483: importing DynamicQuantities only inside the motor safe-testset does not load its owner extension for the isolated piston safe-testset. The same cause also appears in ModelingToolkit clean-master downstream CI and #4742. I am assigning one separate cross-repository audit to reproduce/bisect/fix this shared fixture-owner issue; #482 assertions and compat change remain untouched.

#482 downgrade: https://github.com/SciML/ModelingToolkitStandardLibrary.jl/actions/runs/29253716628/job/86828223048
#482 LTS Core: https://github.com/SciML/ModelingToolkitStandardLibrary.jl/actions/runs/29253717082/job/86828778846
clean-main LTS Core: https://github.com/SciML/ModelingToolkitStandardLibrary.jl/actions/runs/29251201026/job/86822971377

[ChrisRackauckas-Claude]

Independent clean-main audit: the piston failure is a latent missing independent variable exposed by the folder-based SciMLTesting isolation. On Julia 1.10, current main (933a983) reproduces the CI exception exactly in an isolated test/piston.jl: _check_if_dde(..., ::ModelingToolkitBase.PleaseImportDynamicQuantities, ...). The pre-isolation parent 4252111 runs the old combined Thermal Demo at 10/10, while child c44704f (#464) fails when piston is isolated; the piston file itself is unchanged through current main. The upstream sentinel was introduced by ModelingToolkit 2785a86207 when DynamicQuantities moved to an extension. Plan: define the independent variable in the piston fixture through the exported/documented owner API ModelingToolkitBase.@independent_variables, matching the merged motor fix #483; then verify focused LTS/current/pre, native Core, Runic, and MTK downstream before publishing a focused draft PR.