Upgrade to Catalyst 16 / Oscar 1.7 (handles #61; unblocked by CDDLib 0.10.3)

[ChrisRackauckas-Claude]

Warning

Please ignore until reviewed by @ChrisRackauckas.

Follow-up to the dependabot bump in #61 (dependabot/julia/all-julia-packages-beba857eae).

TL;DR

The large bump in #61 (Catalyst 16, ModelingToolkit 11, SymbolicUtils 4, ReactionNetworkImporters 1.3, Hecke 0.39, Nemo 0.55, CDDLib 0.10, Polyhedra 0.8, Combinatorics added) cannot currently be satisfied: getting to Catalyst 16 forces an Oscar version that is mutually exclusive with CDDLib through cddlib_jll. This PR therefore:

1. Fixes the speices -> species typo that fails the SpellCheck CI job.
2. Keeps the package on its working baseline (Catalyst 14.4.1 / MTK 9.46.1 / SymbolicUtils 3.7.2 / Oscar 1.1.1 / Nemo 0.47 / Hecke 0.34 / RNI 0.15.1).
3. Applies only the achievable bumps from Bump the all-julia-packages group across 1 directory with 9 updates #61 that resolve and need no source migration:
   • CDDLib = "0.9.4, 0.10"
   • Polyhedra = "0.7.8, 0.8"
   • adds Combinatorics = "1" (the dep previously had no compat bound).

No source migration was performed because Catalyst 16 / MTK 11 / SymbolicUtils 4 is not reachable (see below), so any states->unknowns / SymbolicUtils-4 changes would be untestable here.

Resolution analysis (why Catalyst 16 is blocked)

Verified locally on Julia 1.11 with Pkg.resolve against the General registry. The constraint chain is:

• Catalyst 16 depends on ModelingToolkitBase (not ModelingToolkit directly anymore), Symbolics = "7.13.0 - 7", SymbolicUtils = "4.9.1 - 4".
• Resolving Catalyst 16.1 + Nemo picks Nemo 0.55.1; pinning Nemo to 0.50 or 0.51 is unsatisfiable (Catalyst 16 -> Symbolics 7 transitively requires Nemo >= 0.52, via the Symbolics/Groebner stack). Confirmed: Nemo = 0.52 resolves with Catalyst 16, Nemo = 0.50/0.51 do not.
• The algebra stack (Oscar/Nemo/Hecke) is independent of Catalyst, but Oscar pins Nemo: Oscar 1.4 -> Nemo 0.50, Oscar 1.5/1.6 -> Nemo 0.52, Oscar 1.7 -> Nemo 0.54. So reaching Nemo >= 0.52 requires Oscar >= 1.5.
• Oscar >= 1.5 -> Polymake 0.13 -> polymake_jll >= 400.1400 -> cddlib_jll = "0.94.15".
• CDDLib (every released version 0.9.4 - 0.10.2, and even master) pins cddlib_jll = "=0.94.14" (exact pin).
• cddlib_jll 0.94.14 and 0.94.15 are mutually exclusive => unsatisfiable.

Net: Catalyst 16 + Oscar + CDDLib is currently an unsatisfiable set. CDDLib is a real dependency — src/cycles.jl::elementary_flux_modes uses CDDLib.Library() as the exact-arithmetic polyhedron backend — so it cannot simply be dropped. The block is upstream: CDDLib has not released (and master does not yet support) cddlib_jll 0.94.15.

Two ways to unblock Catalyst 16 in the future, both out of scope for a dependency-bump PR:

• Land a CDDLib release that allows cddlib_jll 0.94.15 (the real upstream fix), or
• Switch elementary_flux_modes off CDDLib to another exact polyhedra backend compatible with Oscar 1.5+ (an architectural change that needs its own review + EFM-correctness validation).

Other secondary issues found in #61's compat (would have failed even without the CDDLib block):

• ModelingToolkit = "...11.26" — 11.26 does not exist in the registry (latest is 11.25). Catalyst 16 no longer depends on ModelingToolkit directly anyway.
• Nemo = "...0.55" — no Oscar version supports Nemo 0.55 (max is Oscar 1.7 -> Nemo 0.54).
• Combinatorics = "1.1.0" — conflicts with SymbolicUtils 4 (SymbolicUtils 3.32-4 requires Combinatorics = "1 - 1.0.2").
• SBMLToolkit = "0.1.29" was not bumped; Catalyst 16 needs SBMLToolkit >= 0.1.32 (Catalyst = "14 - 16"). SBMLImporter needs v4 for Catalyst 16. (Moot here since Catalyst 16 is blocked.)

Source migration

None required: staying on Catalyst 14.4.1 means no Catalyst-16 / SymbolicUtils-4 API changes apply. Reviewed src/ for states->unknowns, istree/iscall, and Catalyst accessor changes — none are needed on the current stack. The only source change is the comment typo fix.

CDDLib 0.10 / Polyhedra 0.8 breaking changes (Julia >=1.10 floor, JuMP export removal, Mesh moved to an extension) do not touch the API used in cycles.jl (CDDLib.Library(), polyhedron, hrep, vrep, HyperPlane, HalfSpace, rays).

Local verification (Julia 1.11)

• Pkg.resolve() on this branch: OK.
• Full instantiate + using CatalystNetworkAnalysis + an elementary_flux_modes smoke test exercising CDDLib 0.10 / Polyhedra 0.8: see results posted below / in CI.
• Runic: runic --check src is clean (exit 0).

Notes

• Docs CI / Julia 1.12: the Documentation job failure is environmental — an Oscar/CxxWrap precompile error on Julia 1.12.6 (invalid subtyping in definition of StdString with supertype CppBasicString -> failed to precompile CxxWrap). This is an upstream Oscar/CxxWrap-on-1.12 binary issue, not a source bug. It does not reproduce on Julia 1.11.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Local verification output (Julia 1.11)

Pkg.resolve() on this branch: OK.

Full Pkg.instantiate() resolved to (note both bumped packages are picked up and Catalyst stays on the working 14.4.1 baseline):

  [3391f64e] CDDLib v0.10.2          <- bumped (was 0.9.4)
  [67491407] Polyhedra v0.8.1        <- bumped (was 0.7.8)
  [861a8166] Combinatorics v1.0.2    <- now compat-bounded
  [479239e8] Catalyst v14.4.1
  [961ee093] ModelingToolkit v9.84.0
  [d1185830] SymbolicUtils v3.32.0
  [2edaba10] Nemo v0.47.5
  [3e1990a7] Hecke v0.34.9
  [f1435218] Oscar v1.2.2
  [b4db0fb7] ReactionNetworkImporters v0.15.1

using CatalystNetworkAnalysis loads cleanly, and an elementary_flux_modes smoke test (which uses CDDLib.Library() through Polyhedra 0.8) runs correctly:

rn = @reaction_network begin
    (k1, k2), A <--> B
    (k3, k4), B <--> C
    (k5, k6), C <--> A
end
elementary_flux_modes(rn)   # -> 6x5 Matrix{Int64}, EFMs computed OK

runic --check src is clean (exit 0).

Full Pkg.test() results will follow.

[ChrisRackauckas-Claude]

Full Pkg.test() results (Julia 1.11)

Test Summary:                                               | Pass  Fail  Total     Time
CatalystNetworkAnalysis.jl                                  |  146     6    152  4m21.8s
  Concentration Robustness                                  |   12           12  2m21.8s
  Concordance Helpers                                       |   17           17    21.9s
  Siphons                                                   |   12           12    19.2s
  Persistence                                               |    4            4     2.0s
  Deficiency One Algorithm                                  |   16           16    18.3s
  Specific Stoichiometric Compatibility Class Functionality |    2            2    32.6s
  Linear programming utilities                              |    3     2      5     2.8s
  Network Translation                                       |   80     4     84    23.1s

The package precompiles and loads on the bumped stack (CDDLib 0.10.2, Polyhedra 0.8.1, Oscar 1.2.2, Catalyst 14.4.1, ...). 6 failures remain, all in two testsets.

These failures are pre-existing on main and are not caused by this PR. The relevant files are byte-identical between main and this branch (git diff main HEAD -- test/lp_utils.jl test/network_translation.jl src/lp_utils.jl src/translated.jl is empty), and main's own CI is currently red. The failures are test-fragility issues in the package, independent of the dependency bump:

• test/lp_utils.jl:13 and :21 — @test !C.has_positive_solution(b) where b = -rand(1:10, 10, 10) is the same matrix that line 10 just asserted has_positive_solution(b) is true for. Lines 10 and 13 are mutually contradictory for the same random b, so one of them necessarily fails. This is a pre-existing test bug (line 13 almost certainly meant to test a = [1 -1; -1 1], not b).
• test/network_translation.jl:92/93/150/152 — assertions on the specific output of C.WRDZ_translation(...). WRDZ_translation (src/translated.jl:58) selects reactions via pop! on a Set{Int}, whose iteration order is not stable; the algorithm can return a different (still valid) translation, so Y_T*D_T, effectivedeficiency, and isweaklyreversible assertions are fragile. Notably, all of the EFM-based assertions in the same testset (which exercise CDDLib 0.10 + Polyhedra 0.8) pass.

I am NOT touching these tests in this PR (no skipping/loosening). They should be fixed separately as genuine test-robustness bugs on main. I am confirming the same failures reproduce on a clean main checkout and will note the result here.

[ChrisRackauckas-Claude]

Baseline confirmation: the 6 failures are pre-existing on main

Ran the two failing testsets against a clean checkout of main (Catalyst 14.4.1, Oscar 1.1.1, CDDLib 0.9.4, Polyhedra 0.7.8 — i.e. none of this PR's bumps) on Julia 1.11:

test/lp_utils.jl on main:

Test Summary: | Pass  Fail  Total   Time
lp_utils      |    3     2      5  10.9s
  Test Failed at .../test/lp_utils.jl:13   Expression: !(C.has_positive_solution(b))
  Test Failed at .../test/lp_utils.jl:21   Expression: !(C.has_positive_solution(b))

Same 2 failures, same lines — identical to this branch.

test/network_translation.jl on main:

Test Failed at .../test/network_translation.jl:92
  Expression: C.effectivedeficiency(translation) == 0
   Evaluated: 2 == 0

Same failure, same evaluated value (2 == 0) — identical to this branch.

So this PR introduces no new test failures. The 6 failures reproduce on unmodified main (whose CI is also currently red), and the relevant files are byte-identical between main and this branch. They are pre-existing test-robustness bugs in the package (RNG-dependent assertions in lp_utils.jl; Set-iteration-order-dependent WRDZ_translation output in translated.jl) and should be fixed in a separate PR. Per repo policy I have not skipped, loosened, or otherwise masked them here.

[ChrisRackauckas-Claude]

Updated: this now performs the full Catalyst 16 upgrade (the #61 goal)

The upstream blocker is resolved. CDDLib v0.10.3 (released today, via JuliaPolyhedra/CDDLib.jl#108) bumps its cddlib_jll pin to =0.94.15, which is exactly what Oscar ≥ 1.5 requires. Since Catalyst 16 → Symbolics 7 → Nemo ≥ 0.52 forces Oscar ≥ 1.5, the previously-unsatisfiable Catalyst 16 + Oscar + CDDLib set now resolves.

New commit 32df9a3 extends the achievable-subset compat in 0bf337c to the full upgrade.

Resolved stack (verified locally, Julia 1.11): Catalyst 16.2.0, ModelingToolkit 11.26.7, Oscar 1.7.3, Nemo 0.54.2, Hecke 0.39.15, SymbolicUtils 4.34.2, Symbolics 7.26.0, CDDLib 0.10.3, cddlib_jll 0.94.15, Polyhedra 0.8.1, ReactionNetworkImporters 1.3.0, SBMLToolkit 0.1.33, Combinatorics 1.0.2.

Compat corrections vs the naive #61 bump

• Combinatorics = "1" — not 1.1.0; SymbolicUtils 4 caps Combinatorics at 1.0.2.
• Nemo = "0.47, 0.54" — not 0.55; no Oscar release supports Nemo 0.55 (max is Oscar 1.7 → Nemo 0.54).
• Oscar = "1.1.1, 1.7" — Bump the all-julia-packages group across 1 directory with 9 updates #61 left Oscar unbumped, but Catalyst 16 requires Oscar ≥ 1.5.
• ModelingToolkit = "9.46.1, 11", SymbolicUtils = "3.7.2, 4", Hecke = "0.34, 0.39", CDDLib = "0.9.4, 0.10", Polyhedra = "0.7.8, 0.8", ReactionNetworkImporters = "0.15.1, 1.3".
• SBMLToolkit needs no compat change (existing "0.1.29" already permits the required 0.1.33).

Source migration (needed by the new stack; backward-compatible with Catalyst 14)

• Catalyst.symmap_to_varmap — Catalyst 16 no longer exports symmap_to_varmap (it still exists), so the 3 unqualified uses in src/steadystates.jl errored. Qualified them.
• Combinatorics.combinations — Oscar 1.7 now exports combinations, making the unqualified name ambiguous under using Oscar, Combinatorics, so src/translated.jl errored. Qualified it (matching the existing src/utils.jl usage).

Test results (Pkg.test, Julia 1.11)

• This branch: 146 pass, 6 fail, 0 error.
• main baseline (Catalyst 14.4.1, same run): 148 pass, 4 fail, 0 error.

The 8 errors on the first Catalyst-16 attempt were the two unqualified-name issues above; both are fixed (0 errors now). The remaining failures are pre-existing, not introduced by this PR:

• test/network_translation.jl:92,93,150,152 (4) — identical failures on main (the network-translation feature is buggy/WIP independent of this bump).
• test/lp_utils.jl:13,21 (2) — flaky: the test draws unseeded rand(1:10,10,10) (lines 6/9). The LP solver stack is bit-identical between the two environments (JuMP 1.30.1, HiGHS 1.23.0, MathOptInterface 1.51.1, HiGHS_jll 1.14.0+0), so the bump cannot change has_positive_solution; the baseline simply drew a passing sample. (Also note lines 10 and 13 assert contradictory things about the same random matrix — a pre-existing test bug.)

I did not touch the failing tests (no skips/silencing); fixing the network-translation algorithm and seeding/repairing the LP test are out of scope for this dependency bump.

Please ignore until reviewed by @ChrisRackauckas.