CellML Discussion List

Text archives Help


[cellml-discussion] embedded stimulus currents in CellML models


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] embedded stimulus currents in CellML models
  • Date: Tue, 17 Jul 2007 10:21:04 +0100

> >> I think the current use of an embedded stimulus current is due to
> the
> >> repository being limited to CellML 1.0 models. The "correct" way to
> >> approach this problem is this: (1) define the mathematical model
> >> independent of parameter values and boundary/initial conditions; (2)
> >> (this is an optional step) import the mathematical model into a
> model
> >> which defines the common parameters and boundary conditions; (3)
> then
> >> import this model into any simulation specific models - it is at
> this
> >> level you define the particular stimulus protocol or other
> simulation
> >> specific parameter values and/or boundary conditions.
> >>
> >> For the case of a tissue/multi-cellular simulation, you'd probably
> use
> >> either (1) or (2) depending on the requirements of the tissue model
> and
> >> then connect the diffusive "stimulus" current to the single cell
> model
> >> stimulus current.
> >>
> >> While people (including myself) often point out the stimulus current
> as
> >> a special case, it is not really. Any extra or modified current
> being
> >> added to a model can be handled in the same way. For example, the
> way a
> >> (potassium) stimulus current is handled should not be any different
> to
> >> the case where you add the K(ATP) current to a model which does not
> >> already have one.
> >
> > This looks like a very sound approach to me, but this relies on using
> CellML
> > 1.1 and though I would very much welcome a wider use of CellML 1.1, I
> cannot
> > help but wonder what to do with CellML 1.0 models...
>
> Unfortunately, I can't see any way to do this with 1.0 models other
> than
> to have multiple copies of the entire model with and without various
> boundary conditions imposed. This is, of course, one of the main
> reasons
> for CellML 1.1 :-)

Shouldn't we therefore offer at least two different sets of CellML 1.0
files? One that only contains the model itself and another that also
includes some simulation specific information?

Though CellML 1.1 is the obvious way to go, we have to accept the fact that
most CellML users probably only use CellML 1.0.

> Generally what I have done in the past for tissue models, is to use the
> simulation software to "override" aspects of the (1.0) cellular model
> as
> required for the particular tissue simulation. This would be enhanced
> by
> the use of the kinds of metadata mentioned below, which would allow
> software to automatically interpret certain key variables (stimulus
> currents, for example in electrophysiology models) - rather than the
> manual process currently employed (in CMISS).
>
> Personally, I would hope switching an application to using the CellML
> API and hence being able to handle CellML 1.1 models would be a much
> easier process than writing code to interpret certain pieces of
> metadata :-)

Agreed in principle. I am just not sure whether this is always that easy in
practice. If it had been that 'easy', I would certainly have done it for
COR... :)

Alan.





Archive powered by MHonArc 2.6.18.

Top of page