CellML Discussion List

Text archives Help


[cellml-discussion] embedded stimulus currents in CellML models


Chronological Thread 
  • From: j.lawson at auckland.ac.nz (James Lawson)
  • Subject: [cellml-discussion] embedded stimulus currents in CellML models
  • Date: Wed, 18 Jul 2007 12:10:13 +1200

Alan Garny wrote:
>>>> 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?

I actually replied to this somewhere else - I'll repeat it...
We just talked about this issue in the meeting. We decided that it was
probably worth providing one with and one without. Obviously the one
without would not be able to be simulated in PCEnv or COR.

>
> 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.

But is that because they a.) don't need 1.1, b.) don't know how to use
1.1 or c.) want to use 1.1 but don't because the repository doesn't
support it? I suspect it is either a or c, since most people would find
out how to use 1.1 if it was a tool they thought would be useful.

>
>> 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.
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion





Archive powered by MHonArc 2.6.18.

Top of page