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

Open
  • Is something wrong?
#2,112 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
backend

Research direction

Start at FenicsSolver.unsupportedReasons and the existing movingBoundaryReasons in vcell-core/.../org/vcell/solver/fenics/FenicsSolver.java (line ~232) to see how structural refusals are produced for the Problems panel. Read the MathDescription API for MembraneVariable, OdeEquation, CompartmentSubDomain, region variables and FieldFunctionArguments to confirm each check in the issue table is derivable pre-run. The issue offers three options without a decision, so check the comment thread first; a focused first PR would mirror the cheap structural checks (rows 1, 2, 4, 5, 6) as unsupportedReasons and add a fixture test comparing them against docs/integration/fenics-coverage-survey.md categories in virtualcell/vcell-fenics. Done means the survey's failing categories are refused with an explanatory reason before any container starts.

Written by the indexing model from the issue text.

Description

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

Dominant language
Java
Stars
140
Forks
35
Avg merge
11h 28m
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from virtualcell/vcell

All issues in virtualcell/vcell

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.