Choose the SCC block container from the specialization level, and precompile a multi-block SCC initialization - #5202

🚧 UNREVIEWED — awaiting review by @ChrisRackauckas. Opened by an AI agent running as @ChrisRackauckas; Chris has not reviewed this change.
Harness: Claude Code 2.1.280 · Model: claude-opus-5-5[1m]
Conversation: https://claude.ai/code/session_01Wt79fZeNaZxiwQ3LagMYXH

Please ignore until reviewed by @ChrisRackauckas.

Depends on an SCCNonlinearSolve release. At AutoDespecialize, small homotopy initialization problems now take SCCNonlinearSolve's vector path, which threw MethodError: no method matching probvec(::HomotopyProblem). Fixed in SciML/NonlinearSolve.jl#1321 and released by SciML/NonlinearSolve.jl#1323. Until 1.15.4 is registered, test/homotopy_initialization_scc.jl will error on CI here. The SCCNonlinearSolve floor (currently "1.13") must be raised to "1.15.4" before merging. I left it unchanged so CI can resolve now.

What changed and why

SCCNonlinearProblem now picks its block container from the specialization level: AutoDespecialize always stores the blocks in a vector, FullSpecialize always in a tuple, and AutoSpecialize keeps the existing heuristic (tuple for ≤ 5 blocks). Previously every level used the heuristic, so an initialization problem with 2–5 blocks had a type specific to its block count and the kind of each block, and no precompile workload could cover a user's model. Initialization problems built by ODEProblem are AutoDespecialize by default, so they now share one type across models.

The DAE precompile workload also never reached this path: precompile_dae_problem has a single algebraic block, which builds a plain NonlinearProblem initialization (its docstring said SCC; corrected). This adds precompile_scc_dae_problem — a nonlinear block followed by a linear block — built in the package workload and solved in the FBDF, Rodas5P and default-algorithm extension workloads.

Verification

Julia 1.12.6, aarch64-linux (Jetson AGX Orin), --startup-file=no.

New tests fail without the container change and pass with it. test/scc_nonlinear_problem.jl, the two added testsets, run with src/problems/sccnonlinearproblem.jl reverted to master:

SCC block container follows the specialization level:  Test Failed
  Expression: prob.probs isa container          (x2)
Test Summary: ... | Pass 16  Fail 2  Total 18

container actually produced on master, by level:
  n=2  FullSpecialize -> Tuple    AutoSpecialize -> Tuple    AutoDespecialize -> Tuple
  n=7  FullSpecialize -> Vector   AutoSpecialize -> Vector   AutoDespecialize -> Vector

Initialization `SCCNonlinearProblem` type does not depend on the block count:  Test Failed
  Expression: allequal(typeof.(initprobs))
  Expression: typeof(workload) === typeof(initprobs[1])
Test Summary: ... | Pass 7  Fail 2  Total 9

With the change: 18/18 and 9/9 pass.

First solve of a user model in a fresh session, this checkout at master versus master + this PR, everything else identical, pkgimages built before each timed run. Chain DAE with array parameters, FBDF:

The 6-block case improves too although it was already a vector on master, because nothing precompiled the SCC path before. The row with tolerances barely moves: the workloads solve without keyword arguments, and passing abstol/reltol re-specializes __init's keyword body — a separate, finite axis for a follow-up.

Runtime cost of the vector container, the same blocks stored as a tuple versus a vector, warm solve(prob, NewtonRaphson()), 10th percentile of 2000 (medians were noisier; a test suite was running alongside):

About 10–20 µs per initialization solve, once per solve. FullSpecialize keeps the tuple for anyone for whom that matters.

Suite (this branch, with SCCNonlinearSolve from SciML/NonlinearSolve.jl#1321 dev'd):

• GROUP=InterfaceII: Pass 1367, Broken 7 — Testing ModelingToolkit tests passed.
• GROUP=Initialization: Pass 922, Broken 12 — Testing ModelingToolkit tests passed. Against registered SCCNonlinearSolve 1.15.3 the same group has one error, the probvec(::HomotopyProblem) above.
• GROUP=QA: Pass 39, Fail 1. The failure is No unapproved public reexports for [:ap_var, :canonical_constraints, :constraint_residual], none of which this PR touches. Master's own CI fails identically at e167d97: https://github.com/SciML/ModelingToolkit.jl/actions/runs/35838708180/job/107109419276
• Docs (docs/make.jl): builds through doctests, @docs expansion and cross-references. The only error is linkcheck on https://docs.sciml.ai/PDEBase/stable/interface/ in docs/src/API/PDESystem.md (not touched here), which returns HTTP 403 from this machine with curl too.

Runic: no changes on the touched files. typos: clean on added lines.

Not verified

• x86-64: all numbers are from one aarch64 machine.
• Test groups other than InterfaceII and Initialization; no downstream packages.
• NoSpecialize and FunctionWrapperSpecialize take the vector path here (anything that is not FullSpecialize or the AutoSpecialize heuristic). That was not specified; push back if either should keep the heuristic.

🤖 Posted by an AI agent — harness: Claude Code 2.1.280 · model: claude-opus-5-5[1m]
Conversation: https://claude.ai/code/session_01Wt79fZeNaZxiwQ3LagMYXH

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wt79fZeNaZxiwQ3LagMYXH