Modules for Reusable and Collaborative Modelling of
Mathematical Biological Systems
Mandeep Gill, Steve McKeever, David Gavaghan
3rd IEEE Track on Collaborative Modelling and Simulation – CoMetS 12
Overview● Biological and Cardiac Modelling
● Ode DSL
● Collaborative Model Reuse
● Modules
● Model Module Repositories
● Partial Results
● Summary
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
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
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
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
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
Cardiac Cell Model Example
δV =−I stim+ ∑ I ion
Cm
Multi-Scale Cardiac Models
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
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
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
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
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
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
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
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
ModulesSodiumChannel
PotassiumChannel
CalciumChannel
module CardiacModel {
import HH.CaChannel
import HH.KChannel
import HH.NaChannel
// model code goes here
}
Interfacecalc_I :: (milliV, milliV)
-> microA/cm^2
Cardiac Model
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
PotassiumChannel #1
PotassiumChannel #2
module CardiacModel(KChannel) {
// as before...
}
ParameterisedCardiacmodel
Interfacecalc_I :: (milliV, milliV)
-> microA/cm^2
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
module SodiumChannel {...}...
import Repo1.Cardiac.HH58.SodiumChannel
Repo1/Cardiac/HH58.ode
Name
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
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
(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
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
Acknowledgements● Supervisors
– Dr. Steve McKeever, University of Oxford, UK
– Prof. David Gavaghan, University of Oxford, UK
● Thank you for listening
● Questions?
Recommended
