Presentation delivered at the 3rd IEEE Track on Collaborative Modeling & Simulation - CoMetS'12. Please see http://www.sel.uniroma2.it/comets12/ for further details.

1. 3rd IEEE Track on Collaborative Modelling and Simulation – CoMetS 12
Modules for Reusable and
Collaborative Modelling of
Mathematical Biological Systems
Mandeep Gill, Steve McKeever, David Gavaghan
mandeep.gill@cs.ox.ac.uk

2. Overview
● Biological and Cardiac Modelling
● Ode DSL
● Collaborative Model Reuse
● Modules
● Model Module Repositories
● Partial Results
● Summary

3. Biological Modelling
● Overall goal to model entire human body, from
genomic level upto organ and body level in an
integrative manner
– DNA, Protein, Cellular Compartments, Cells,
Tissue, Organs, Entire Body
● Several major aims, including,
– Increased understanding of biological processes
– Personalised medicine and treatment
– In-silico experiments into disease and drug function

4. Biological Modelling
● Individual models are painstakingly derived from
multiple sets of experimental data, from multiple
disciplines, even across multiple species in a
collaborative process
● Requires a knowledge and research in a variety of
disciplines from multiple users utilising a range of
modelling approaches
– Physiologists
– Biologists / Biochemists
– Mathematicians
– Software Engineers / Computer Scientists

5. Biological Modelling
● Typically model from a continuous, deterministic
perspective, using ODEs and PDEs
– i.e. Cell cycles, signalling pathways, cardiac
electrophysiology
● Our research is focused on cardiac modelling as it is
highly developed with a range of specific models
backed by experimental data
● Cardiac diseases and disorders comprise one of the
largest sets of health risks in the Western world

6. Cardiac Modelling
● Computational modelling of the electrical and
mechanical activity of the heart is recognised as a
powerful technique in the detailed investigation of
cardiac behaviour
– Particularly in respect to modelling disease and
the effects of drugs on cardiac function
● Cardiac cell models typically investigate electrical
changes during an action potential
– These are governed by the function of ion
channels within the cell
– Flow of charged ions within capacitative
membrane causes changes in cellular potential

7. Cardiac Modelling
● We traditionally model cardiac function at multiple
levels
– Cellular level, treated as spatially homogeneous
entity and modelled using ODEs
– Tissue level and organ level, using PDEs
● Simulation complex, solvers specific to each model
● Simulation extremely computationally intensive
– Modern cell models can require 20min
– Whole organ models can require 9min to simulate
100ms of rabbit ventricular activity
● Utilising a 2048-core computer cluster

8. Cardiac Cell Model Example
−I stim + ∑ I ion
δV =
Cm

9. Multi-Scale Cardiac Models

10. Ode DSL
● DSL for developing mathematical (cardiac) biological
cell models
● Features
– Numbers, Booleans, Functions, structures and
mathematical operators
– Direct support for ODEs (potentially DAEs)
– Syntax similar to Python and MATLAB
– Based on sound, computational foundation
– Support for model validation and model reuse

11. Ode DSL Aims and Goals
● Enable rapid model construction and prototyping
● Executable model specification
● Facilitate model reuse and collaborative development
● Ease of use for non-programmers
● Specific support for biological modelling
● High simulation performance
● Investigation into multi-scale APIs/integration

12. Model Validation - Type System
● Ode is type checked statically during compilation to
enforce correctness of model equations
– i.e. checks nonsensical statements,
– 5 + True // error
● This ensures that a valid model may always be
simulated successfully
– although makes no guarantees regarding the
correctness of the results
● Type information is used to guide optimisations during
implementation

13. Model Validation - Units System
● Many models of physical systems are expressed in
terms of units-of-measure
– type-system extended to support static checking of
units
– speed : m/s = 100m / 10s
● Units can be created within the model and assigned to
values
– used to check that all equations are dimensionally
consistent
● Algorithm can infer the correct units in many cases,
● Where proven safe, the system can automatically
convert between units of the same dimension

14. Collaborative Model Reuse
● Models are continuously developed and improved
from,
– newer experimental research and data
– previous models and simulations
● More complex, integrative models derived from the
composition of existing, smaller models, e.g.
– Cardiac models derived from multiple ion channel
models
– 2D and 3D tissue and whole organ models derived
from finite element method and single cell models
● Require a mechanism to reuse models within DSL

15. Collaborative Model Reuse
● Cardiac models have gone from 2 channels with 4
ODEs to over 11 channels with 60 ODEs to describe
the same cell type within a species
● We can consider the single cell model as composed
from multiple independent channels

16. Collaborative Model Reuse
● From modelling perspective, can consider each
individual component as implementing an interface
● This interface is then utilised by the structure/cell to
comprise the final model
● Providing these components exhibit the same
interface, they may be,
– developed by multiple users
– replaced by different implementations
– altered to investigate differing model properties
● Effect of drugs on well-known models

17. Modules
● The idea of reusable, composed components shown in
the cell model is encapsulated with a flexible module
system
– enables sharing/reuse within and between models
– leads to repository of reusable model components
● Module system allows grouping logically related model
components into an connected, independent structure
● Type system used to generate a signature for the
module that forms its interface
– ensures module may be correctly used and
composed

18. Modules
Potassium Sodium Calcium
Channel Channel Channel
Interface
calc_I :: (milliV, milliV)
-> microA/cm^2
Cardiac Model
module CardiacModel {
import HH.CaChannel
import HH.KChannel
import HH.NaChannel
// model code goes here
}

19. Parameterised Modules
● Allows a module to take user-defined modules as
parameters
● Increases module flexibility and enables specialisation
by module users
● Type system ensures safe module composition,
checks all implementations exhibit same interface
module CardiacModel(KChannel) {
Potassium Parameterised // as before...
Channel #1 Cardiac }
model
Potassium Interface
calc_I :: (milliV, milliV)
Channel #2
-> microA/cm^2

20. Module Repositories
● Modules may be contained within repositories
● Multiple repository hierarchies may be enabled by
the modeller and utilised within the simulation
environment
● Modules are referenced by a unique name derived
from location within the repository directory structure
Repo1/Cardiac/HH58.ode
module SodiumChannel {...}
...
Name
import Repo1.Cardiac.HH58.SodiumChannel

21. Module Repositories
● When backed by version control software a
repository can form a collaborative environment
– Multiple users can create, modify and share
modules
● Simulation-time type and units system ensures
integrity of modules and their valid composition
– Invalid modules easily detected
● Intend to have multiple repositories for differing
biological modelling domains
– Including a canonical model repository

22. Model Repositories – Future areas
● Semantic Metadata
– quality, correctness, origins, ontologies
● Web interface to repository
● Best Practices
– i.e. Module naming and name-spacing
– Recommended interfaces for known entities
● Dependencies
– Intra- and Inter-repository
– Automatic retrieval of dependencies
● Some of these handled by CellML
– XML language for biological model curation

23. (Partial) Results
● We are using DSL to create several human cardiac
cell models that share a common lineage
● Use module features to parametrise modules through
ion channels into reusable components with common
interface
● Intend to simulate ad-hoc model variants derived
from module composition in order to investigate
parameter differences and relate to initial
experimental data
● Intend to simulate models utilising custom high-
performance GPU-based simulation engine

24. Summary
● DSL created to enable rapid prototyping of models
(and high-performance simulation)
● Modularisation enables development by multiple
parties within an interdisciplinary field
● Modules may be reused, composed and customised
within more complex models
– Usage validated by strong type and units-checking
present at the module interfaces
● Module repositories combined with a version control
system enable both collaborative and centralised
development

25. Acknowledgements
● Supervisors
– Dr. Steve McKeever, University of Oxford, UK
– Prof. David Gavaghan, University of Oxford, UK
● Thank you for listening
● Questions?