CARDIAC ELECTROPHYSIOLOGY
WEB LAB
The underlying software
Cardiac simulation in Chaste
• Originally developed as an open-source tissue-level
electrophysiology simulator
• Parallel (MPI) finite-element code
• Supports CellML descriptions of cellular models
• Can also be used for single-cell investigations
• Easily parallelise multiple independent simulations
• Leverage the CellML interfacing support
• More flexibility than the Web Lab – full power of a general
purpose programming language (C++) available
• See also doi:10.3389/fphys.2014.00511
Features for single cell modelling
• Automatic use of CellML models on-the-fly
• Units conversion, including for ionic currents
• Handling different stimulus current conventions
• Handling naming variations (often within no or minimal annotation)
• See also doi:10.1016/j.pbiomolbio.2011.06.002
• Access to model ‘parameters’ and ‘derived quantities’
• By name, using annotations
• Access works whatever the ‘type’ of variable accessed
• Range of available ODE solvers
• Can check/enforce that variables stay within expected ranges
• Can use ‘analytic Jacobians’ to improve speed/accuracy
• Automatic lookup tables for speed/accuracy trade-off
Available ODE solvers
• Forward Euler
• Backward Euler
• Newton-Raphson style using Jacobian, mostly
• Runge-Kutta 2nd/4th order (explicit)
• Rush-Larsen
• ‘Analytic solution’ for some variables assuming V is constant over a
time step; forward Euler otherwise
• Generalised Rush-Larsen (1st or 2nd order)
• Linearise the RHS and solve ‘exactly’
• CVODE
• Adaptive time stepping to maintain specified error bounds
• Can take advantage of analytic Jacobian
Reference solutions
•
• We then ran CVODE with very tight tolerances to
generate reference voltage traces 𝑉𝑡 .
• And then found time step required for
1.
2.
Solver not to become unstable
Solution to meet MRMS < 0.05 (5%)
Evaluating the MRMS criterion
Timings for 60+ models
Compiler optimisation is good!
Analytic Jacobians
Using lookup tables
Tissue simulation timings
“Simple Sensitivity”
• A Chaste extension (“user project”) to simplify running
•
•
•
•
•
experiments with many model parameterisations
A separate file defines the parameterisations
Parameters are identified using same annotations as in
the Web Lab
Allows easy parallelisation if resources available
(multicore or MPI cluster)
The ‘virtual experiment’ can be defined by arbitrary C++
All Chaste functionality is available
Balances Web Lab abstraction with greater flexibility
Reproducibility
Or, can you trust the Web Lab results?
• The Web Lab stores all previously generated results
• You can compare with previous versions of models,
protocols and/or software
• This isn’t automatic
Functional Curation project
• The Web Lab’s simulator is also a Chaste extension
• Tests of this project are automated
• Low-level unit tests
• Regression testing against previous results
• Comparison against alternative implementation (more later)
• The results of these tests are public
• You can install the project yourself and run Web Lab style
experiments locally from the command line
Contributing to the Web Lab
• All components follow an open development model
• Source code and issue trackers are public
• Simulator hosted within the Chaste repository
• Website hosted at Bitbucket
• Components written in C++, Python, Java & Javascript
• Next talk covers our plans – collaborators welcome!
CARDIAC ELECTROPHYSIOLOGY
WEB LAB
Future plans
The Web Lab future?
Incorporating experimental data
• Comparison of web lab results against wet lab data
• Assessing parameter identifiability
• Fitting model parameters to data
• Reading protocol descriptions from patch clamp software
formats
• Ideally link to a community repository for data
What information is in an action potential?
Existing hERG Channel / IKr Models
Model A
C3
C2
C1
I
Model B
O
C3
C2
I
C1
O
Model E
Model D
IC 1
I
IC 2
Model C
I
C2
C1
Model F
IC 1
I
O
IC f
If
Is
IC s
Cf
C1
O
Model G
S1
S0
4
(
(S 2
C2
C2
C1
O
IC 1
I1
I2
C1
O1
O2
Cs
Of
Os
C = closed state
O = open state
I = inactivated state
V(t) = Asin(2πf1t)+Bsin(2πf2t)+Csin(2πf3t)
Assessing Accuracy of Parameter Estimation
PARAMETER ESTIMATION AND
MODEL SELECTION
Aidan Daly
Extension to Functional Curation and the Web
Lab
Motivation
• Parameter fitting and model selection experiments are
notoriously hard to replicate
• Settings and implementation details are unreliably reported
• Published code is often intrinsically tied to the model/data
• Abstracting the basic components, as in Functional
Curation, would allow us to:
• Easily update parameterized models when new data become
available
• Apply previously successful fitting strategies to new
models/protocols
• Easily compare the output of many algorithms, or the same
algorithm under differing conditions, for a modelling problem of
interest.
Abstraction of modelling experiments
Abstraction for functional curation tasks
One-to-one matching
Ontology
(for well-designed protocols)
Protocol
Model
Output
Protocol
Model
Output
Protocol
Model
Output
Experimental data
Experimental data
Experimental data
Abstraction for parameter fitting tasks
Parameter Distribution
Experiment
Output
Experimental
data
Objective
Algorithm-specific distribution update
Ontology
Data
Data
Data
Experiment
Experiment
Experiment
Objective
Objective
Objective
Algorithm
Algorithm
Algorithm
Abstraction of modelling experiments
• Combination of Functional Curation concepts of Model
and Protocol into Experiment
• Objective functions compare experimental recordings to
(analogous) simulated Experiment outputs
• Highest degree of generalization achieved when Experiment and
data follow naming conventions (i.e, the Oxmeta ontology)
• Algorithm uses data, Experiment, Objective and a prior
distribution to generate a posterior
• Prior outputs matched to Model parameters through an ontology
Analysing result sensitivity (UQ)
• Presenting a ‘single result’ is clearly insufficient
• Biological systems are variable: inter-individual, intra-individual,
adaptation over time
• Models can be chaotic – even minor changes to code layout can
give qualitative differences in simulation results if models have
bifurcations
• We want to incorporate indications of how sensitive the
results are to different input perturbations
• How best to do so is something of an open question
Standards & repositories
• Ideally the ‘Web Lab’ framework should be integrated with
community-standard model & data repositories
• Provide richer curation information for models
• Model annotations stored alongside the original models
• Similarly for model parameterisations?
• Reusing/linking to standard ontologies
• Essential for integration
• Protocols building more on SED-ML
• Although we suspect the post-processing requirements of cardiac
modelling will never be fully met by such a broad standard
• Dedicated protocol editing software is also needed
Technical developments
• The simulator is (mostly) C++ code built on Chaste
• This is being re-implemented entirely in Python
• Aim is for a faster, more flexible framework
• Make it easier to extend what protocols can do
• More flexible post-processing and data structures
• Friendlier error messages when post-processing fails
• Provides a basis for Aidan’s parameter fitting work
• Now mostly done, just some loose ends to sort out
Our vision
• CellML files are a great development
• But they aren’t enough
• Soon we can auto-validate models (hypotheses) against
new datasets
• But in order to truly build on existing models we need to
ship each model with all of the following:
• Training data used to set parameters
• Training protocols
• Parameter fitting algorithms
• Validation data used to evaluate model
• Validation protocols
Acknowledgments
Gary Mirams
• Additional development work by:
• Martin Scharm
• Aidan Daly
• Erich Kerekes
• Ideas and inspiration:
• Dagmar Waltemath
• Jon Olav Vik
• Steven Niederer
• Alan Garny
• David Gavaghan
• Denis & Penny Noble
Jonathan Cooper
CARDIAC ELECTROPHYSIOLOGY
WEB LAB
Panel discussion
Over to you…
• What is needed to develop the cardiac modelling field?
• How could the Web Lab fit in?
• What should we focus on next?