← back

Simulating the Cell

Biological simulation software, and where the real constraints sit
2026-06-26 · for a systems engineer scoping the landscape

A survey of the tools that compute what a cell does — kinetic ODE engines, spatial PDE solvers, genome-scale flux models, whole-cell models, agent-based tissue sims, and the new ML "virtual cell" front. One finding shapes everything downstream: for mechanistic models the wall is data, parameters, and identifiability, not FLOPs. Only agent-based tissue sims are genuinely compute-bound.

One sentence

The solvers are mature, fast, and embeddable — so don't write one, and the wall above them is data, parameters, and identifiability, not FLOPs. This page surveys what computes a cell and where the real constraints sit; for what a systems engineer should actually build, see what to build.

1. The landscape, by orthogonal axis

Seven tool classes, each defined by the one thing it does that the others structurally can't. Pick by category, not by a single best-to-worst score — they solve different problems.

ClassWhat it computesScaleFlagshipStack
Kinetic / ODE-SSASpecies concentrations over time (deterministic, stochastic, hybrid)10s–1000s speciesCOPASI, libRoadRunnerC++ / LLVM JIT / Py
SpatialReaction-diffusion-advection on real geometry; particle stochasticsingle cell, 3DVCell, Smoldyn/MCell4Java / C++ / Py
Rule-basedNetworks too big to enumerate (multisite, scaffolds)rules, not reactionsBioNetGen + NFsimPerl / C++ / Py
Constraint-basedSteady-state flux under mass balance (LP), knockout screensgenome-scaleCOBRApy, COBREXAPython / Julia
Whole-cellEvery cellular process, integrated1 cell → colonyvEcoli (Karr→Covert)Py + Cython / Nextflow
Agent-basedOff-lattice 3D multicellular tissue + diffusion~5×105–106 cellsPhysiCell, BioDynaMoC++ / OpenMP
ML foundationPredicted cell state / perturbation response (no chemistry)108 cells trainedSTATE, scGPT, Evo 2Transformers / GPU
SBML is the connective tissue for the mechanistic half: COPASI, libRoadRunner/Tellurium, VCell, SimBiology, and BioNetGen all read/write it, so a kinetic model moves between solvers. Constraint-based and ML models live outside SBML — FBA uses the fbc stoichiometry package; ML uses AnnData/h5ad single-cell formats. That format split is itself a fault line a runtime has to bridge.

2. The wall is data, not FLOPs

This determines what's worth building. Across the mechanistic and ML paradigms, the people closest to the tools say the same thing: raw compute is rarely the limit.

Tool classWhere the bottleneck really is
Kinetic (COPASI, roadRunner)Parameters + identifiability. roadRunner JIT-compiles SBML via LLVM — the fastest SBML simulator going. Rate constants are the scarce resource, which is why COPASI ships heavy parameter-estimation machinery.
Spatial (VCell, Smoldyn)3D PDE/particle compute and unmeasurable diffusion coefficients + geometry. Spatial parameters are harder to measure than well-mixed ones.
Rule-based (BioNetGen/NFsim)Memory (network-free particle counts) + per-rule rate params. NFsim's trick: cost scales with rules, not the implied reactions.
Constraint-based (COBRA)The LP is cheap; the gap is missing kinetics/regulation + reconstruction quality. FBA sidesteps parameters by assuming steady state — and pays by predicting no concentrations or dynamics.
Whole-cell (Karr, vEcoli)Parameter aggregation across the whole cell — the defining hard problem (see §4).
Agent-based (PhysiCell, BioDynaMo)Raw compute genuinely matters here — diffusion solve + cell-cell mechanics at scale. The one compute-bound class.
ML foundation (STATE, scGPT)Benchmarks + cross-context generalization + data noise, not GPU hours. Even the AI people concluded their wall is data and evaluation.
Same conclusion across both paradigms: biology's simulation wall is data, parameters, and identifiability. A faster solver buys you little; the leverage is anywhere that attacks the parameter/data constraint rather than the numerics.

3. Mechanistic engines, head to head

Kinetic — speed is solved, parameters aren't

libRoadRunner / Tellurium
JIT-compiles SBML to native code via LLVM (2.0 LLJit >3× the old MCJit). The fastest SBML simulator, and a C API explicitly built to be hosted by other applications "on large compute clusters for parameter optimization." RoadRunnerMap = thread-safe parallel handles. C++17 core. libroadrunner.org
COPASI
The gold-standard reference impl: ODE, Gillespie SSA, hybrid, events — plus the heavy machinery that matters (parameter estimation, sensitivity, metabolic control analysis). ParaCopasi parallelizes scans/PE. The PE focus is itself the tell: rate constants are the bottleneck. copasi.org

Both are SBML-native and fast enough. SimBiology (MATLAB) covers the same ODE/stochastic class for pharma QSP/PBPK/PK-PD with NLME fitting and virtual-population Monte Carlo — license-gated, FDA-standard for model-informed drug development. The shared lesson: solver speed is not the customer's pain. mathworks.com/products/simbiology

For a Rust engineer, libRoadRunner's C API is the clean FFI target — wrap it, own the orchestration in Rust, never write a solver. Speed only matters for batch sweeps, which is precisely where caching and parallel handles pay off.

Spatial — geometry is the moat

Virtual Cell (VCell) is the broadest spatial stack: reaction kinetics + diffusion + flow + membrane transport + electrophysiology on real geometries derived from 2D/3D microscope images, solved as finite-volume PDEs, with spatial-stochastic via Smoldyn and rule-based via BioNetGen. NIH-funded, decades mature, free, server-backed compute (Java client). 3D PDE solves in complex geometry are genuinely compute-heavy — but the practical wall is still diffusion coefficients + geometry. vcell.org

Smoldyn / MCell4 push particle-based single-molecule resolution; MCell4 fuses MCell3's spatial engine with BioNetGen's network-free rules. Particle count drives cost (and historically capped memory near a few million).

Rule-based — beating combinatorial explosion

BioNetGen + NFsim exist for systems where writing every species by hand is impossible — multisite phosphorylation, receptor/scaffold complexes, polymers. The key trick: NFsim's network-free cost scales with the number of rules, not the implied reactions, so it handles models that would generate intractably many species. Hybrid particle/population methods address the memory wall. PMC5079481

Constraint-based — genome-scale, no kinetics

COBRApy dominates: FBA, FVA, gene-deletion screens, dynamic FBA, community modeling — thousands of reactions, solved as a cheap LP under mass-balance constraints. It buys genome-scale coverage by giving up time-resolution and concentrations. The 2025 frontier COBRA-k (Science Advances 2025, sciadv.aeb3022) injects nonlinear kinetic rate laws into COBRA to jointly constrain fluxes, enzyme abundances, and metabolite concentrations — directly attacking FBA's "no kinetics" gap. Scalable cousins: COBREXA 2 (Julia, HPC-scale).

FBA / COBRA — wins
Genome-scale out of the box. LP is fast. No rate constants needed — steady-state assumption sidesteps the parameter problem entirely. Knockout / community screens at scale.
FBA / COBRA — loses
No dynamics, no concentrations, no regulation. Quality is capped by reconstruction accuracy. Can't answer "what happens at t=30s" — only "what flux is feasible at steady state."

4. Whole-cell — the parameter lesson, distilled

The whole-cell program proved the data-not-FLOPs thesis first, the hard way.

Karr & Covert 2012 built the first complete whole-cell model of Mycoplasma genitalium — chosen for the smallest known bacterial genome (~500 genes). 28 submodels, 401 genes, 1,857 reactions, 1,836 parameters scavenged from ~900 publications. A single simulated cell cycle was computationally feasible; the multi-year effort was data assembly. github.com/CovertLab/WholeCell

vEcoli is the live successor (Covert lab, 4,000+ commits): a whole-cell E. coli model — transcription, translation, metabolism, replication — built as composable Vivarium modules, scaling up to colony/population runs with single-cell heterogeneity. Larger-than-RAM analytics via Parquet + DuckDB; orchestrated with Nextflow, parallelizable to GCP/AWS; uv for deps; test install ~10 min on an M2 Air. github.com/CovertLab/vEcoli, vivariumlab.com

vEcoli's architecture is itself instructive: the hard part is multi-scale integration and composition (Vivarium) wrapped in workflow orchestration (Nextflow) and columnar analytics (Parquet/DuckDB). A systems-engineering stack bolted onto a science problem, built bespoke per-lab.

5. ML "virtual cells" — different paradigm, same wall

These don't simulate chemistry. They learn to predict cellular state and perturbation response from massive single-cell data.

ModelWhat it predictsTraining scaleSource
STATE (Arc, 2025)Drug / cytokine / genetic perturbation responseSE: 167M cells; ST: 100M+ across 70 contextsCell, S0092-8674(25)00675-0
scGPTGPT-style multi-omics, shared token vocabularytens of M cellsNature Methods 2024
GeneformerMasked LM over gene expression30M cellsvirtualcellmodels.cziscience.com
scFoundation / AIDO.CellMasked autoencoder50M cells, up to 650M params
Evo 2 (Arc + NVIDIA)Coding + noncoding mutation effects; genome-scale design9.3T nucleotides, 128k+ genomesarcinstitute.org/news/evo2
The Arc team and the survey literature are explicit that the bottleneck is not GPU hours. It is: (1) cross-context generalization — "generalization to unseen cell types remains a significant challenge"; (2) benchmark rigor — why the Arc Virtual Cell Challenge exists, a recurring Turing-test-style benchmark on a held-out cell context; (3) data quality — single-cell data carries "substantial technical noise" and poor perturbation reproducibility, which directly caps performance; (4) no reliable uncertainty estimates yet. arxiv 2510.07706

The convergence: the AI people independently reached the diagnosis mechanistic modelers gave 15 years ago — data and evaluation, not FLOPs. CZI's Billion Cell Project and the virtualcellmodels.cziscience.com platform are the data-scaling response.

6. What this means for what to build

The takeaway for a systems engineer: the solvers are mature and embeddable, and the wall above them is data, parameters, and identifiability, not raw compute, so a faster solver buys little. The build direction that follows from this lives on its own page — see what to build.