CellML Discussion List

Text archives Help


Re: [[cellml-discussion] ] enable c calls to cellML ?


Chronological Thread 
  • From: Jonathan Cooper <jonathan.cooper AT cs.ox.ac.uk>
  • To: cellml-discussion AT lists.cellml.org
  • Subject: Re: [[cellml-discussion] ] enable c calls to cellML ?
  • Date: Wed, 16 Apr 2014 09:30:53 +0100
  • Organization: University of Oxford

Hi Hans,

While I know you want to avoid 'big packages', it's worth mentioning that the CellML support in Chaste can be easily adapted to generate source code for other settings too. As well as using annotations as described below to identify variables, we also handle units conversions, to ensure a correct interface between the cell model and the reaction-diffusion equations - getting the ionic currents right is particularly tricky!

We've also discovered that it's both possible and efficient to use CVODE for multi-cellular simulations, which was a surprise to us too. If the voltage is provided by the tissue equations, and not allowed to vary in the ODE solve, then you can treat it like a parameter, and CVODE seems to cope very well with it changing between solves. There is a higher memory cost in having all the CVODE state for each cell, but on today's machines that doesn't tend to be a show-stopper.

Caveats:

* We only support CellML 1.0 (but that accounts for most cardiac
electrophysiology models, and there is a 1.1 -> 1.0 converter on the
CellML website).
* The metadata annotations Chaste uses are slightly different from
those used by OpenCOR - our approach pre-dates the standardisation
here! Eventually we'll move over, but we haven't had any users
calling for it yet...

For further info, see

* https://chaste.cs.ox.ac.uk/trac/wiki/ChasteGuides/CodeGenerationFromCellML
* https://chaste.cs.ox.ac.uk/trac/browser/projects/cellml (Our
collection of annotated CellML files)
* https://chaste.cs.ox.ac.uk/trac/wiki/UserTutorials/SingleCellSimulation
(Contains helpful general guidance for using CVODE)
*
https://chaste.cs.ox.ac.uk/trac/wiki/UserTutorials/Monodomain3dExampleWithCvode
* https://chaste.cs.ox.ac.uk/trac/ticket/2116 (The work on getting
CVODE working in tissue)


Best wishes,
Jonathan

On 16/04/2014 04:53, Alan Garny wrote:
Just for the record: currently seating a few meters away from Hans, David
Nickerson and I suggested him a possible solution to his 'problem'.

For those curious/interested, the solution basically consists in using
David's CSim tool (see https://code.google.com/p/cellml-simulator/). Now,
because Hans wants to solve a reaction/diffusion problem, he shouldn't use
the solver used by CSim, which is CVODE (see
http://computation.llnl.gov/casc/sundials/description/description.html#descr_cvode).
CVODE is a probably the best solver for single cell simulations, but it's
not particularly suitable for multicellular modelling (it requires to be
reset after each diffusion step, something that can be quite time consuming).
So, instead of using CVODE, he should use a simpler solver or, rather, a
solver that doesn't need to reset itself after each diffusion step (or
doesn't take long to do so).

Finally, and for convenience, we also suggested to Hans to annotate the
CellML file(s) he wants to use for his work, and this using OpenCOR (see
http://www.opencor.ws/ and
http://www.opencor.ws/user/plugins/editing/CellMLAnnotationView.html). The
idea is to associate a particular ontological term (which one doesn't
actually matter, as long as the annotation is consistent through the CellML
files he wants to be able to use) to the various model parameters is
interested in. This done, and using CSim, he will be able to query model
parameters using their annotation information. The advantage of this approach
is that all his simulation framework needs to know is that the membrane
potential has, for example, been annotated using this or that ontological
term. Without this annotation, his framework would need to know the name of
the model parameter (and possibly the name of the component in which it was
defined), something that may vary from one model to another.

Alan

-----Original Message-----
From:
cellml-discussion-request AT lists.cellml.org
[mailto:cellml-discussion-
request AT lists.cellml.org]
On Behalf Of
hans.dierckx AT ugent.be
Sent: 16 April 2014 01:00
To:
cellml-discussion AT lists.cellml.org
Subject: [[cellml-discussion] ] enable c calls to cellML ?

Hi all,

Inspired by Herbert Sauro's suggestion in this week's CellML workshop, I'd
like
to ask whether cellML currently has possibilities to make simple c calls.
If not, can they be included in the near future?

As many researchers in cardiac modeling, I use my own code to solve the
reaction-diffusion equations. I know there's much advantage in using 'big'
software packages, but so is there in code which you fully control and
understand. It would be great for users like me if we could import cellML
models to use as a black box to give correct/verified reaction kinetics.

In c-language, I would be looking for calls like

#include "cellMLimports.h"
/ / to enable imports

void import_cellMLmodel(char[] modelname); / / specify the model to be
imported by a string or char array (by some cellML identifier or URL)

void give_reactionterm(double** u, double* Fu); / / **u is a pointer to an
array of state variables in one point of the domain / / *Fu is an array
containing the corresponding reaction term in du/dt =
F(u) to which the result is written

void update_state(double** u, double dt); / / **u is a pointer to an array of
state variables in one point / / dt is a time interval over which du/dt=F(u)
is
integrated at a time resolution needed by the model; the resulting state
vector is returned to u

void stimulate_point(double **u, double I_amp, double dt, double
voxelvolume); / / to apply a current stimulus (in physical units)

double give_resting_state(int whichvariable); / / to return the resting
potential and equilibrium values for state variables

I only mention the c-example as it applies to me, but similar arguments apply
also to calls from other languages (fortran, python, matlab, …). A useful
extension may be to support also parallel calls, e.g. in openMP.

Many thanks in advance to discuss the possibility,


Hans Dierckx

(I am a postdoc in Ghent University, Belgium, currently visiting the Auckland
Bioengineering Institute.)





Archive powered by MHonArc 2.6.18.

Top of page