Solution of the ODEs and PDEs involved in cardiac simulation is actually rather straightforward, and it’s been implemented over and over by many groups around the world. Even in my former lab, we used four different implementations during the course of my degree (some simultaneously). However, there are three major considerations that make implementation of a useful cardiac simulator difficult.
- Errors: Ionic models are notoriously finicky. Even the slightest typo in an equation can make the model behave incorrectly. If you’re lucky, it’s obvious, like if the cell doesn’t activate at all when stimulated. If you’re not so lucky, you might not even notice until after you’ve published a paper using a model that gives you physiologically incorrect results. Given all of the equations in one model, there are a lot of chances for something to go wrong. (Example: Variables and Equations in the second ten Tusscher human ventricular model) We have extensively validated the output of many of our models directly against the code written by the original authors of the models, to avoid letting any errors go undetected.
- Features: Hard-coding a simulation that does something simple the same way every time is relatively easy. Writing a simulator that can stimulate using intra- or extracellular voltage constraints, intra- or extracellular current injection, and ground electrodes, with square, sinusoidal, descending ramp, and other waveforms, in an arbitrary model geometry is much more difficult. In each case the boundary conditions must be set differently. Meshes may have one or more regions and several types of elements (tetrahedral, hexahedral, etc). Integrated analysis tools such as activation detection and pseudo-ecg generation have become requisite for doing efficient, useful scientific work with a cardiac simulator. Most of these features are not inherently difficult to build, but there are many of them to implement and test, and that takes a lot of programming time. We’ve done all of this and more already.
- Parallelization:
Parallel machines are hard to program and we should make them even harder – to keep the riff-raff off them.
I know how to make 4 horses pull a cart – I don’t know how to make 1024 chickens do it.
For models the size of dog and human hearts, and smaller hearts at high resolutions, a simulation could not until recently be run on one machine. Such simulations cannot be run on a single processor in a useful period of time, even if the machine has enough memory available (and you’re not going to find a machine with uniform memory access times to memory banks that large). Therefore, to run such simulations, the simulator must be capable of parallel computing. This requires knowledge of programming in MPI and/or OpenMP, and debugging follows programming. Parallel debugging is a nightmare, even with good tools. Again, we’ve already done this and our simulator scales very well on the appropriate hardware (see the quote about 1024 chickens above).
When it comes to cardiac simulation research, you have two options. You can spend most of your time reinventing the wheel and what little time you have left doing science, or you can use a working, well-tested, preexisting simulator and spend a little time learning and a lot on the science. Which would you rather do? And which are you qualified for?