Four BMDB models fail at a second point, revealed once the COPASI annotation cast was fixed

[jcschaff]

Split out from the baseline accept (PR to follow) so these do not disappear into test_cases.ndjson as permanent known-bad.

The COPASI annotation ClassCastException fix (#1974, issue #1461) let twelve SYSBIO_BIOMD archives get past SBML import for the first time. Eight now run clean. These four fail at a later stage — the cast had been masking a second fault in each, and nightly run 32005421226 is the first diagnosis we have of what that fault actually is.

model	new failure_type	message
BIOMD0000000849	DIVIDE_BY_ZERO	Solver (CVodeSolverStandalone) status: Aborted (CVODE solver could not generate input file: …)
BIOMD0000000872	SBML_IMPORT_FAILURE	Error binding global parameter 'beta' to model: 'UNRESOLVED.initConc' is either not found in your model or is not allowed to be used…
BIOMD0000000925	SOLVER_FAILURE	Solver (CVodeSolverStandalone) status: Aborted (Could not e…)
BIOMD0000000961	SBML_IMPORT_FAILURE	Error binding global parameter 'rateOf_re15' to model: 're15' is either not found in your model or is not allowed to be used…

These are not regressions

Every one of them was failing before, at an earlier point, for a reason that told us nothing. Nothing got worse; we can just see further now. The baseline accept is therefore correct — they genuinely do fail, and documenting that is honest.

But recording them as known-bad also makes them silent again, which is the exact failure mode the nightly gate exists to prevent. Hence this issue.

Worth noting: two look like distinct, tractable bugs

• 872 and 961 are the same shape — a global parameter bound to something the model does not define (UNRESOLVED.initConc, rateOf_re15). rateOf is an SBML L3 construct; UNRESOLVED. looks like a VCell-side placeholder that escaped into a binding. Both are in our SBML importer, not the solver, and both may be one fix.
• 849 and 925 are CVODE aborting before it starts — "could not generate input file" is a solver-input generation failure, not a numerical one. DIVIDE_BY_ZERO and SOLVER_FAILURE may be misclassifications of the same underlying problem.

Not urgent — these are curated BioModels that have never worked in VCell, and no user is waiting on them. But four archives moving from "unknown import error" to two identifiable pairs is the most tractable this has ever been.

Suggested next step

Take 872 or 961 first. A rateOf / unresolved-parameter binding bug in the SBML importer is likely to affect more than these two models — the other ten just failed earlier for a different reason, so we have no idea how many otherwise-importable models hit it.

[jcschaff]

The 961 half is fixed in #1983, and it reaches further than expected — verified against the actual models, eight BMDB models now report a precise reaction-rate diagnosis instead of an opaque binding failure: 305, 542, 556, 575, 578, 731, 961, 1026. (570 was also in that group but turns out to be masking a compartment error.)

Correction to this issue: 872 and 961 are not the same bug. I inferred that from the message shape; reading the models disproved it.

model	references	mechanism
961	reaction re15	SBML reaction-rate reference — fixed in #1983
872	species s4 in a global parameter's initialAssignment	the species' initial concentration lives in the application scope; a Model-level parameter cannot see it

872 belongs to a much larger, pre-existing population: #803, now categorized — 31 BMDB models, all SBML global parameters reaching application-scoped initConc (24) or Size (7). Root cause is the Model/SimulationContext name-scope boundary, not a missing symbol. Two candidate fixes are written up there.

Also worth recording, since #1981's title suggested detecting rateOf: BIOMD0000000961 contains no rateOf csymbol at all. COPASI merely named its parameters rateOf_re15; the construct is a plain <ci>re15</ci>. Matching the csymbol would never have fired.

Still open here: 849 (DIVIDE_BY_ZERO) and 925 (SOLVER_FAILURE), both CVODE aborting on input-file generation.