FEniCSx pre-run gate checks only geometry: most offered BioModels then fail in the solver

[jcschaff]

Problem

FenicsSolver.unsupportedReasons (vcell-core/.../org/vcell/solver/fenics/FenicsSolver.java:232) is the pre-run check that lets VCell refuse a FEniCSx run with a reason instead of starting a container. It checks the geometry (2D/3D; analytic or image subvolumes, not CSG) and the moving-boundary cases, but nothing in the math.

A coverage survey of saved public BioModels shows the result. On a seeded sample of 600 of the 3,423 spatial, deterministic applications, run through the vcell-fenics CLI on regenerated math, the gate offers FEniCSx for 578 applications and 527 of those then fail inside the solver. The user finds out from a failed job with a solver traceback-style message, possibly after a cluster queue wait, rather than from the Problems panel.

What the gate could check (all visible in the MathDescription)

check	apps failing for it (of 600)	vcell-fenics issue
Membrane species (MembraneVariable with an equation) on a membrane whose other compartment has no species	129	virtualcell/vcell-fenics#185
OdeEquation in a CompartmentSubDomain (non-diffusing species)	118	virtualcell/vcell-fenics#186
An analytic subvolume that touches the domain box	72	virtualcell/vcell-fenics#187
MembraneRegionVariable / VolumeRegionVariable (membrane potential, region averages)	29	virtualcell/vcell-fenics#188
Field data (vcField(...), FieldFunctionArguments)	10	virtualcell/vcell-fenics#190
Three or more compartments with species coupled through membranes	3	virtualcell/vcell-fenics#193
Mesh too large: estimated tetrahedra at the simulation's mesh size above the solver limit (3D images)	23	virtualcell/vcell-fenics#192

A further 67 applications fail because VCell's own math generation fails for their BioModel today. VCell shows those already, before any solver is involved.

Options

1. Mirror the checks in Java, as movingBoundaryReasons does. Fast and runs in the Problems panel, but the two lists drift as vcell-fenics grows. Keep them in sync with a test that runs a fixture set through both.
2. Ask the solver: a vcell-fenics --check mode (import + validate + plan, no mesh or solve) that returns the same reasons. Accurate by construction, but it needs the container, so it's too slow for the Problems panel. It would suit the run/submit path.
3. Both: the cheap structural checks (rows 1, 2, 4, 5, 6) in Java for the Problems panel, and --check at submit for the rest.

Survey and per-category detail: docs/integration/fenics-coverage-survey.md in virtualcell/vcell-fenics.

🤖 Generated with Claude Code

[jcschaff]

One more check the FEniCSx gate needs: a FastSystem in the math, VCell's rapid-equilibrium reduction (e.g. fast calcium buffering). vcell-fenics does not solve fast systems, and solving without one is silently wrong for the buffered species. vcell-fenics now refuses such a task at start (it reads the element from the SimulationTask XML, since pyvcell drops it), but the Problems panel should say so up front. MathDescription's subdomains expose it through getFastSystem(). It is common: 116 of 600 sampled public applications (19%), including most electrophysiology-with-calcium models.