BMDB nightly red since 08-18: the baseline accept captured an outlier pass for BIOMD0000001065, which has been failing intermittently since June (not a regression)

Start by reproducing the single-model run: BIOMD0000001065.omex (task vonDassow2000_1x4.timecourse1.sedml) at c93d087cc (passes) vs 6f4c62345c (hoist only) vs b6dba107fa (hoist + size swap), the three SBML-importer commits in the c93d087cc..ac5774d5a window. Diff the generated math for those importer revisions, checking whether EN_0_0's trajectory or any compartment size changed. Before coding, settle the open question: print the base with %.17g or check signbit at the C++ pow guard in SundialsSolverStandalone (vcell-solvers) to tell IEEE -0.0 from drift — that decides between fixing the domain guard (see #1646) and the importer. Done means one named commit identified as the cause; do not accept test_cases.updated.ndjson into vcell-cli/src/main/resources/test_cases.ndjson.

Summary

The BMDB nightly has failed on every run since 2026-08-18 with the same single change:

| BIOMD0000001065.omex | PASSED | FAILED (SOLVER_FAILURE) |

SOLVER_FAILURE count went 28 → 29; everything else in the report matches the baseline. This is
not part of the #1981 churn — that issue covers 849/872/925/961, and 1065 is none of them.

Latest run: 32343249649.

It is a deterministic regression, not a flake

Nightly	Result	1065
08-08 → 08-16 (9 runs)	✅ success	passing
08-17 (32005421226)	❌ failure	still passing — that run's 12 changes were all the COPASI annotation fix (#1981)
08-18 (32094317081, 32110561618)	❌ failure	first failure
08-20 (32343249649)	❌ failure	failing

Nine consecutive passes then three consecutive failures, with the same message each time.

The failure

vonDassow2000_1x4.timecourse1.sedml, task1, aborts at t = 450 after 483 ms:

CVODE solver failed : CV_REPTD_RHSFUNC_ERR: repeated recoverable right-hand side function errors
  : FunctionDomainException : pow(u,v) and u=-0.000000<0 and v=2.619640 not an integer
in "((0.0528… * ((0.000305 / (0.000305 + (EN_0_0 ^ 2.61964))) ^ 9.63095)
    / (5.76e-23 + (0.4 * ((0.000305 / (0.000305 + (EN_0_0 ^ 2.61964))) ^ 9.63095))))
    - (0.132 * ci_0_0))"
  where:
    EN_0_0 = -0.000000
    ci_0_0 = 1.000000

A Hill term raises the species EN_0_0 to a fractional power (2.61964). EN_0_0 has gone
very slightly negative, so pow is genuinely undefined and the solver's domain guard fires.
CVODE treats it as recoverable, retries with smaller steps, and eventually gives up
(CV_REPTD_RHSFUNC_ERR).

Note the guard wording differs from VCell's Java one
(ASTPowerNode.java:132 says u^v and u<0 …), so this is the C++ guard in
SundialsSolverStandalone — i.e. vcell-solvers, not this repo.

-0.000000 prints the same for true IEEE negative zero and for a tiny negative like -1e-9.
Which of the two it is has not been established, and it matters — see "open question" below.

Where it was introduced

Regression window is the 08-17 nightly commit → the 08-18 nightly commit,
c93d087cc..ac5774d5a — 10 commits. Three are SBML-importer changes from the #803 series, all
merged the evening of 08-17:

commit	PR	what it does
6f4c62345c	#1985	Hoist species initial conditions into global parameters — s4.initConc becomes a global s4_initConc, referenced symbolically
b6dba107fa	#1985	Use Structure.StructureSize for compartment sizes outside the application — makes a previously-conditional swap unconditional
089568c8c9	#1985	drops a log-only list

The remaining seven are a release-script fix, a baseline accept, and an error-message change —
none of which can move a trajectory.

Both structural changes alter the generated math for SBML imports, and either could move
EN_0_0 by the tiny amount needed to tip a knife-edge Hill term negative:

• b6dba107fa is the stronger suspect. Making the size swap unconditional means any model where
  the application's StructureMapping size differs from Structure.StructureSize now resolves to
  a different number, which rescales concentrations.
• 6f4c62345c should be mathematically neutral — it makes an initial condition symbolic rather
  than literal — but it does change the generated expression, and constant folding at a different
  point can change the last bits.

Suggested next step

A one-model bisect settles it cheaply — no full nightly needed:

BIOMD0000001065.omex at c93d087cc      (expected: passes)
                     at 6f4c62345c     (hoist only)
                     at b6dba107fa     (hoist + size swap)

Then diff the generated math for the two importer revisions. If EN_0_0's trajectory or any
compartment size changed, that identifies the commit and probably the fix.

Open question worth settling either way

Is EN_0_0 genuinely IEEE −0.0, or a small negative from integration drift?

• If it is −0.0, the solver's domain guard is wrong: -0.0 < 0 is false in IEEE, so
  pow(-0.0, 2.61964) should return +0.0 (C99 §F.9.4.4), not raise. That would make this an
  instance of #1646 ("VCell does not properly handle -0.0 … creating far-reaching problems"),
  which is currently marked Done on the project board — and would mean it is not fully fixed.
• If it is drift, the guard is correct and the real question is why this model now dips
  negative when it did not before, which points back at the importer change.

The two have completely different fixes, so this should be answered before anyone writes code.
Printing the base with %.17g at the guard, or checking signbit, distinguishes them immediately.

Meanwhile: the gate is red and staying red

Per the workflow's own message, accepting the result means committing the
test_cases.updated.ndjson artifact over vcell-cli/src/main/resources/test_cases.ndjson.
That should not be done here — the point of #1901's gate is that a real regression must not be
absorbed into the baseline and made silent again, which is exactly the argument #1981 makes for
its four models. Until this is diagnosed the nightly will keep failing, which is the gate working.

_{Found while triaging the nightly failure; run history, commit window and code references verified against the working tree.}