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 for1. Solver not to become unstable

2. 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?

C = closed stateO = open stateI = inactivated state

C 3 C 2 C 1 O

I

C 3 C 2 C 1 O

I

C 2 C 1 O

IModel A Model B Model C

C 1 O

I

Model D

IC 1

C 1 O

I

Model E

IC 1

C 2

IC 2

C s O s

I s

Model F

IC s

C f O f

I fIC f

Model G

C 1 O 2

I 2I 1

C 2

IC 1

O 1S 2 S 1 S 0(

(4

Existing hERG Channel / IKr Models

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

Data

Data

Data

Abstraction for functional curation tasks

Model

Model

Model

Protocol

Protocol

Protocol

Ontology

Output

Output

Output

Experimental data

Experimental data

Experimental data

One-to-one matching(for well-designed protocols)

Abstraction for parameter fitting tasks

Parameter Distribution Experiment Output ObjectiveExperimental

data

Algorithm-specific distribution update

Experiment

Experiment

Experiment

Objective

Objective

Objective

Ontology

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 Jonathan Cooper• 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

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?