Breaking dependency updates: CUDA 6, DiffEqBase 7, OrdinaryDiffEq 7, Optimization 5 (supersedes #59)

[ChrisRackauckas-Claude]

Note

This PR was prepared by an AI agent. Please ignore until reviewed by @ChrisRackauckas.

Supersedes #59 (the dependabot compat bumps are included as the first commit) and makes the changes actually required for the test suite to resolve and pass with the new majors.

Root cause analysis of the CI failures on #59

• CUDA CI jobs (resolution failure): ParametricMCPs — including its latest release 0.1.17 — caps ForwardDiff at 0.10 through a weak dependency (its ForwardDiffExt). With force_latest_compatible_version=true (which julia-runtest enables automatically on dependabot PRs), ForwardDiff gets forced to 1.4.0, which is unsatisfiable alongside ParametricMCPs.
• The "passing" CPU Tests jobs on Bump the all-julia-packages group across 1 directory with 5 updates #59 were not actually testing the update: the centralized tests workflow runs with force-latest-compatible-version: false, and the same ParametricMCPs → ForwardDiff 0.10 → NNlib ≤ 0.9.31 → CUDA < 6 constraint chain silently held the resolved environment at DiffEqBase 6.213 / OrdinaryDiffEq 6.109 / CUDA 5.11 / ForwardDiff 0.10.39.
• Downgrade CI jobs: these fail because force_latest_compatible_version=true (auto-enabled on dependabot PRs) is inherently contradictory with downgraded compat bounds (NonlinearSolve@1.7.0 vs forced latest 4). That is a quirk of the centralized downgrade workflow on dependabot PRs, not something fixable in this repo; on this (non-dependabot) PR the downgrade jobs run normally.

Changes

• Remove ParametricMCPs from the test dependencies and drop its comparison half of the benchmark testset in test/core/cpu/mcp.jl. The ComplementaritySolve.jl half of the benchmarks is kept (it exercises forward solves and Zygote adjoints for both in-place and out-of-place problems). There is no released ParametricMCPs version compatible with ForwardDiff 1, so it cannot coexist with NonlinearSolve ≥ 4.17, NNlib ≥ 0.9.32, or CUDA ≥ 6.
• No source changes were required: the package precompiles and all tests pass against the new stack as-is.

Verification (local, Julia 1.12.6)

A fresh environment from the updated test/Project.toml now freely resolves the full new stack: CUDA 6.1.0, DiffEqBase 7.5.5, OrdinaryDiffEq 7.0.0, Optimization 5.6.1, ForwardDiff 1.4.0, NonlinearSolve 4.19.1, SciMLSensitivity 7.112.0, SciMLBase 3.18.0, NNlib 0.9.35.

Test results against that stack (BACKEND_GROUP=CPU):

Group	Result
Core	212 pass, 6 broken (pre-existing @test_broken), 0 fail
Applications	41 pass, 1 broken (pre-existing @test_broken), 0 fail
QA	5 pass, 1 broken (pre-existing), 0 fail

Identical pass/broken counts to CI on the old stack, i.e. no regressions. CUDA groups could not be run locally (no GPU on this machine); the GPU CI failure on #59 was at version resolution, which this PR fixes, so the self-hosted runners will validate the rest.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

CI status after the second round of fixes:

• CUDA Applications: now passes (the ForwardDiff 1.x GPU seeding fix resolved the scalar-indexing errors).
• CUDA Core: failed with Out of GPU memory at CUDA context creation (cuDevicePrimaryCtxRetain) on runner demeter4-2 — an infrastructure issue, not a code failure; every test errored before running anything. Pushed an empty commit to retrigger since this account lacks rerun permissions.
• Downgrade (all groups): these are failing on main as well (every run since at least 2026-06-02), with the same class of error — julia-downgrade-compat pins minimum versions that are mutually unsatisfiable (on main: GPUArrays 8.4.2 vs CUDA needing ≥ 8.6; on this branch: DiffEqBase 6.121.1 vs SteadyStateDiffEq 2.x needing ≥ 6.140). This is pre-existing breakage independent of this PR; a separate fix raising the compat lower bounds is being prepared.

[ChrisRackauckas-Claude]

Final CI status: all jobs green except the three Downgrade jobs, which fail identically on main (broken since the workflow was introduced on 2026-06-02) and are fixed separately in #64.

• Tests (Core/Applications/QA): pass, and the resolved environment confirms the new stack is actually being tested — CUDA 6.1.0, DiffEqBase 7.5.5, OrdinaryDiffEq 7.0.0, Optimization 5.6.1, ForwardDiff 1.4.0, NonlinearSolve 4.19.1, SciMLBase 3.18.0.
• CUDA Core + CUDA Applications: pass on the GPU runners with CUDA 6.1.0 (the earlier CUDA Core failure on this branch was an out-of-GPU-memory infrastructure error at context creation; it passed on retrigger).
• Downgrade: pre-existing main breakage — the minimum compat bounds were never mutually resolvable. Fixed in Fix Downgrade CI: raise compat lower bounds to a resolvable, testable minimum set #64, which raises the lower bounds and verifies all three groups pass locally at the pinned minimums.

[ChrisRackauckas-Claude]

Removed the ForwardDiff.seed! type piracy per review feedback (c3a8fa9), along with the JLArrays regression test that exercised it. The limitation is now documented instead — in the README CUDA footnote and next to DEFAULT_NLSOLVER in the source: with ForwardDiff ≥ 1, ForwardDiff-based jacobians seed dual arrays with scalar setindex! loops, so solvers computing jacobians through ForwardDiff error on CUDA arrays until that is fixed upstream in ForwardDiff.

Consequence to expect on CI: the CUDA Core job (and the CUDA solver paths in CUDA Applications) will fail again with ForwardDiff 1.4 resolved, since the workaround is gone. Local CPU verification after the removal: Core 212 pass / 6 broken (pre-existing), QA 5 pass / 1 broken (pre-existing), piracy count back to the original 2 instances.

[ChrisRackauckas-Claude]

Follow-up per review (b329b5f):

• The ForwardDiff ≥ 1 GPU limitation is now documented in CUDA solver paths error with ForwardDiff >= 1: seed! scalar-indexes GPU dual arrays #65 instead of the README/source comments (those were reverted).
• The affected CUDA tests are marked @test_broken (referencing CUDA solver paths error with ForwardDiff >= 1: seed! scalar-indexes GPU dual arrays #65): the NonlinearReformulation/BokhovenIterativeAlgorithm solve, batched, and adjoint paths in test/core/cuda/{lcp,mcp}.jl. InteriorPointMethod does not use ForwardDiff jacobians and keeps its regular assertions on CUDA. @test_broken records Broken when the expression throws (verified locally), so the GPU CI should go green and will flag an unexpected pass once ForwardDiff fixes seeding upstream.

[ChrisRackauckas-Claude]

Status update on the last two CI rounds:

• The previous round confirmed the @test_broken approach works on the GPU runners: CUDA Core reported 2 passed / 73 broken / 0 failed except for 4 Unexpected Pass results — the size(M) = (2,2,5), size(q) = (2,1) batched adjoint combination actually works on CUDA (it takes the batched code path that avoids ForwardDiff jacobian seeding), so ec0932d restored its regular assertions.
• The latest round failed on runner infrastructure only: both CUDA jobs aborted with error: could not lock config file /home/chrisrackauckas/.gitconfig: File exists (exit 255) on the demeter hosts (demeter3-2 and demeter4-4 — looks like they share an NFS home, so concurrent jobs race on the same ~/.gitconfig.lock, or a stale lock file is left behind). No test failures. The earlier green CUDA runs were on arctic hosts. @ChrisRackauckas — a stale ~/.gitconfig.lock on the demeter home may need removing.
• Tests (Core/Applications/QA) all pass. Downgrade failures remain the pre-existing main breakage addressed in Fix Downgrade CI: raise compat lower bounds to a resolvable, testable minimum set #64.

Retriggered CI with an empty commit (f06e553).