Appearance
Bayesian Calibration of a Hemolysis Model
This study infers the parameters of a computational hemolysis model that predicts red blood cell damage under mechanical stress, calibrating it against experimental measurements. Three collaborators with complementary expertise built it together: a domain expert on macOS, working in Python, who holds the experimental data and judges whether results are physically plausible; a UQ-methods expert on Windows, also in Python, who designs the calibration and judges whether the results are statistically meaningful; and a research software engineer on Linux, working across languages, who builds and maintains the study and supports both collaborators' experiments.
The study is built from three units. A forward model takes control variables and design parameters and returns a predicted hemolysis index; it exists in both Python and Julia, selectable at runtime. An MCMC unit queries the forward model in an online loop to infer its parameters. A report unit compiles results and diagnostics from the MCMC output. Beyond a single calibration run, the study can also fan out across a sweep of experimental datasets, or across competing hemolysis model implementations, applying the same calibration setup to each.
Patterns
The core of the calibration is Pattern C: the MCMC unit queries the forward model in a tight online loop. Around that core, the same calibration setup can also sweep across a design of experimental datasets (Pattern A), or fan out across competing forward-model implementations for comparison (Pattern B). See Workflow Patterns for how these compose.
Recommendations applied
The Python and forward-model-adjacent units run in their own conda environments (Iso1); the Julia forward model, which conda cannot manage, is containerised with Docker instead (Iso2), and a matching container definition builds the Apptainer image used on HPC (Iso3), so porting the study needs no changes to unit code. Conda lock files and CI automation were added after the study was first assembled (Iso4).
Experimental data is fetched from a remote repository and preprocessed to CSV; MCMC output is written in NetCDF through the ArviZ interface. Both are language-agnostic formats exchanged through the filesystem, so any unit can consume them regardless of the language it's written in (Int1, Int2). The MCMC unit queries the forward model over the UMBridge interface, exchanging data between the two units without any language bridging (Int3).
Each unit declares its inputs, outputs, script, and environment as a self-contained contract, and the full workflow is automated in Nextflow (Orch1), which limits concurrency to the available resources when calibrations run in parallel (Orch2) and skips completed runs on rerun (Orch3). The forward-model server writes its network port to a sentinel file in a shared directory; the MCMC client waits for that file before connecting (Orch4).
Porting the study to HPC needed only an updated Nextflow executor profile and Apptainer images built from the existing container definitions, with no changes to unit code. The Julia forward model, ported later, gave a 10-100x speedup over the Python baseline. Diagnostic units were added after the study was first assembled, without modifying any existing unit.
Repository
The study is available at nicodirkes/bpc_hemolysis.