I’m pleased to announce Jonathan Cooper and I have made our web portal interface to the cardiac electrophysiology virtual experiments publicly available. It’s called ‘Functional Curation for Cardiac Electrophysiology’, which is a bit of a mouthful, so I’m calling it the Web Lab for now.
As shown in Fig. 1, the idea is to separate out the model (quantitative assumptions and hypotheses about how something works – in this case taking the form of a system of ordinary differential equations ‘ODEs’), from the experiment that you are performing (generally intervening with the system somehow, or just observing it evolve, and analysing what happens).
The ingredients are shown in Figure 1, we need:
- Model descriptions: these are already provided by the CellML repository (we just strip out the stimulus protocol).
- Protocol descriptions: these are in our own language, loads of examples on the Web Lab are probably the best place to start, but a full reference guide can be found here.
- Interface descriptions or what we have called ontology annotations: we’re currently using a little list of metadata tags for this (which we’ve stuck into copies of the CellML files here). Future plans include a full ontology so you can say nice things like “plot all the SR currents”, “clamp all the intracellular concentrations”, “run a simulation with just potassium currents”, etc… and merging it all back into the main CellML repository if everyone’s happy.
- Simulator: The Web Lab provides an interface to the simulator running on a server here in Oxford, and also a nice database to store and view models, protocols and results. You can download and install it all yourself and run this stuff from the command line, but we don’t tend to bother with that anymore!
It might seem trivial to separate model and protocol. If for instance you wanted to do 2Hz pacing instead of 1Hz pacing with an action potential model, you could just change one number in the code that was generated automatically from the CellML website – all well and good!
But sometimes this is more complicated: what if you wanted to clamp the voltage and isolate the L-type calcium current (in consistent units) under clamped concentrations (or reversal potentials if the model was too old to have concentrations)? This would be extremely fiddly to do for more than one model. What if you wanted to automate the post-processing and even graph plotting?
The Functional Curation system does all this for you, by working out what outputs rely on what inputs, and throwing away parts of the model you don’t need. As soon as a model or protocol is updated, you can re-run everything automatically.
This section contains some links to results on the Web Lab, which work at the moment, but might not if we do a major overhaul/re-run! If they stop working just go to the Web Lab and have a play on the ‘Experiments’ page.
So, you can have a look at the activation IV curve that is generated from voltage clamping just the fast sodium channel in the ten Tusscher model. Or you could compare it with the O’Hara model’s IV curve. Or you could see how a model behaves under different protocols – for example S1-S2 and steady state restitution curves, or look at summary graphs and underlying action potentials for block of the IKr channel. You can see the possibilities, for any model, for any protocol.
You can have a play with the Web Lab here, and register to upload your own models and protocols. Feedback is very welcome via the contact page there…
Please note that wacky behaviour is possibly down to either CellML being buggy, or the protocol (particularly the postprocessing) needing some work. It doesn’t necessarily mean the model itself is strange. But if you find any examples of behaviour that isn’t replicated when you try the same thing elsewhere let us know and we will try to figure out what is happening!
So at the moment, this is already a useful tool for selecting models for simulation studies. For example, you can check they replicate some basic behaviour you are relying on (restitution is an obvious one for tissue simulations of arrhythmia). You can also avoid ones that don’t get to steady state very well or seem a bit numerically… er… fragile.
But this is just the start. My vision for this relates to my last post. Imagine models being shipped with all the data that was used to parameterise them (and the algorithms that were used), that would make extending/adapting a model ‘properly’, possible for the first time. In another version of Figure 1, we tie experimental data to the protocol descriptions. You can easily imagine auto-validating models against novel real experimental results, and even think about auto-developing models as and when new data arrives by automatically re-parameterising them, and auto-selecting the most appropriate.