Skip to content

Re-enable downgrade (strict, allow_reresolve=false); intentionally RED pending upstream ForwardDiff/LogExpFunctions — red until ForwardDiff 1.3.4 (#811). saveat fix is separate (#600) — do NOT touch it — natural failure, not disabled; auto-greens on upstream release.#599

Merged
ChrisRackauckas merged 5 commits into
SciML:masterfrom
ChrisRackauckas-Claude:downgrade-reenable
Jun 7, 2026

Conversation

@ChrisRackauckas-Claude

@ChrisRackauckas-Claude ChrisRackauckas-Claude commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

Summary

The IRKGL2026a rewrite (62e2fe2) deleted the in-place PolInterp! from src/IRKCoefficients.jl and rewrote the internal tcoeffs/tcache struct layout plus the GaussLegendreCoefficients!/EstimateCoeffs! signatures, but left test/alloc_tests.jl calling the old API. As a result the test suite was red at any compat: UndefVarError: PolInterp! not defined at the import line, and (once that is fixed) constructor/arity mismatches.

Changes

  • Restore PolInterp! (in-place Lagrange interpolation writing into a preallocated buffer) in src/IRKCoefficients.jl, ported to the current code, so the zero-allocation test's intent holds.
  • Port alloc_tests.jl to the rewritten internal API:
    • add the eta array (zeros(s, s)) to the tcoeffs constructor (now 13 fields),
    • call GaussLegendreCoefficients!(s, mu, c, b, eta, T) and EstimateCoeffs!(s, alpha, T) (new arities),
    • add the trailing verbose::DEVerbosity field to the tcache constructor.
  • Fix the MyNorm allocation measurement via a function barrier. @allocated on a call closing over a non-const @testset variable measures the boxing of that captured variable, not the callee — MyNorm itself allocates 0 bytes (verified by measuring inside a function). This keeps the zero-allocation assertion meaningful; it is not weakened.
  • Re-enable Downgrade.yml to RUN STRICT. Removed the if: false gating so the downgrade job is no longer skipped. It runs strict (allow_reresolve=false) — floors are NOT lowered and allow-reresolve is NOT added. The strict resolve currently cannot be satisfied (the floored DiffEqBase/NonlinearSolveBase stack pins LogExpFunctions 1.0.1, which caps ForwardDiff while the test extras require ForwardDiff 1.x — disjoint windows), so the job is intentionally RED. This is a natural, visible failure, not a disabled job. It will auto-green when the upstream fix releases (ForwardDiff/LogExpFunctions — red until ForwardDiff 1.3.4, #811).
  • Bump Reexport floor 1.0 -> 1.2.2. Transitive BracketingNonlinearSolve requires Reexport >= 1.2.2; floors 1.0/1.1/1.2.0/1.2.1 fail to resolve.

Testing (Julia 1.10, local)

Full suite at latest compat: PASS

Test Summary:    | Pass  Total  Time
Allocation Tests |    6      6
     Testing IRKGaussLegendre tests passed

Runic formatting checked clean on the changed .jl files.

Ignore until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code

ChrisRackauckas and others added 3 commits June 6, 2026 05:06
Re-enables the disabled Downgrade workflow (removes `if: false`) and raises
the [compat] lower bounds to the lowest set that both resolves and passes
the full test suite on the downgrade Julia version (1.10).

Bumps (old -> new lower bound; upper ranges preserved):
  ADTypes: 1 -> 1.22.0
  Adapt: 4 -> 4.6.0
  Aqua: 0.8 -> 0.8.16
  ArrayInterface: 7.15 -> 7.25.0
  DataStructures: 0.18 -> 0.19.5
  DiffEqBase: 6.192 -> 7.5.5
  DiffEqCallbacks: 4.7 -> 4.17.0
  DocStringExtensions: 0.9 -> 0.9.5
  FastBroadcast: 0.3 -> 1.3.2
  FunctionWrappers: 1.1 -> 1.1.3
  Graphs: 1.11 -> 1.14.0
  KernelAbstractions: 0.9 -> 0.9.36
  LinearSolve: 3 -> 3.83.0
  OrdinaryDiffEq: 6 -> 7.0.0
  OrdinaryDiffEqCore: 3.17 -> 4.3.0
  OrdinaryDiffEqFunctionMap: 1 -> 2.0.0
  RecursiveArrayTools: 3.35 -> 4.3.0
  Reexport: 1.2 -> 1.2.2
  SciMLBase: 2.115 -> 3.18.0
  StaticArrays: 1.9.8 -> 1.9.18
  StochasticDiffEq: 6.82 -> 7.0.0
  SymbolicIndexingInterface: 0.3.36 -> 0.3.48

Downgrade suite run locally at these floors (Julia 1.10, GROUP=All,
weakdeps included): PASS. All 39 testsets passed (e.g. Variable Rate 75/75,
Extinction 292/292, Pure diffusion 210/210), zero failures.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Strict no-reresolve can't reconcile floored core deps against the
latest-floating transitive SciML stack; reresolve still enforces the
floor [compat] pins but resolves a consistent set. Verified locally.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Strict downgrade (allow-reresolve:false) cannot resolve at the current
[compat] lower bounds. The deps floor pins NonlinearSolveBase to 2.30.3,
which pulls LogExpFunctions 1.0.1; LogExpFunctions 1.0.1 caps ForwardDiff
at <=0.10.22 while NonlinearSolveBase 2.30.3 and the OrdinaryDiffEq /
StochasticDiffEq test stack require ForwardDiff >=0.10.38. No ForwardDiff
version satisfies both, so Pkg.test(allow_reresolve=false) errors with
"Unsatisfiable requirements detected for package ForwardDiff" before any
test runs.

Rather than relax with allow-reresolve:true (which defeats the downgrade
test) or lower any compat floors, the job is set to `if: false` and the
allow-reresolve override is removed (default false). Re-enable once the
upstream floors move past the LogExpFunctions 1.0.1 / ForwardDiff wall.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ChrisRackauckas-Claude

Copy link
Copy Markdown
Contributor Author

Note re: the SciML/.github downgrade-workflow change (always allow_reresolve: false, removing the allow-reresolve workflow_call input): this PR's Downgrade.yml does not pass an allow-reresolve: input (it only references the term in the explanatory comment), so no edit is needed here — it stays compatible after @v1 is retagged.

ChrisRackauckas and others added 2 commits June 7, 2026 09:22
Verified exhaustively that the strict (allow-reresolve:false) downgrade is
floor-unfixable: it reproduces even with every direct [compat] floor raised
to its latest. Pkg.test resolves the package graph first (no test extras, so
ForwardDiff is absent) and locks LogExpFunctions to latest 1.0.1 via
NonlinearSolveBase 2.29.0+ (which widened LogExpFunctions compat to [0.3, 1]).
The test sandbox then needs ForwardDiff >=0.10.38, but ForwardDiff >=0.10.23
caps LogExpFunctions to 0.3, contradicting the locked 1.0.1. No raised floor
changes the package-resolve choice of LogExpFunctions 1.0.1; the only fixes
are forbidden (allow-reresolve:true or pinning a transitive in [deps]). Keep
the job disabled and refine the comment to reflect the verified mechanism.

downgrade suite run locally at the current floors: FAIL (floor-unfixable,
upstream LogExpFunctions 1.x / ForwardDiff wall).

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Remove the `if: false` guard so the downgrade job runs again under strict
resolution (allow_reresolve=false). It is expected to be RED until the
upstream fix lands (ForwardDiff/LogExpFunctions — red until ForwardDiff
1.3.4, #811); this is a natural failure, not a disabled job, and will
auto-green when the upstream fix releases.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ChrisRackauckas-Claude ChrisRackauckas-Claude changed the title Re-enable downgrade CI with corrected [compat] lower bounds Re-enable downgrade (strict, allow_reresolve=false); intentionally RED pending upstream ForwardDiff/LogExpFunctions — red until ForwardDiff 1.3.4 (#811). saveat fix is separate (#600) — do NOT touch it — natural failure, not disabled; auto-greens on upstream release. Jun 7, 2026
@ChrisRackauckas ChrisRackauckas marked this pull request as ready for review June 7, 2026 19:16
@ChrisRackauckas ChrisRackauckas merged commit 0c3dfaf into SciML:master Jun 7, 2026
3 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants