Chronological Thread 

< Chronological >      < Thread >

---

> From Alan Garny (following some discussion on stimulus currents with
> the Auckland group):
>
> > CellML models that require a stimulus protocol to generate an action
> > potential currently implement one in the CellML model itself (Noble 98
is
> > one such example indeed). Still, I don't think such a protocol should be
> > part of the model. The only reason Penny Noble did it that way in the
> first
> > place is that we had no other choice in COR (she was waiting for me to
> > implement my concept of COR project).
> >
> > Still, what happens if I want to use that model in a multi-cellular
> > environment? Ideally I would, in that environment and at some point,
> specify
> > the different cellular models that I want to use by selecting different
> > CellML files. Now, if those CellML files contain a hard-coded stimulus
> > protocol in them, this will obviously cause problems.
> >
> > We may therefore want to think of another way of incorporating a
stimulus
> > protocol, not to mention that one could come up with a different
protocol
> > and still get an action potential (granted, the underlying physiology
will
> > likely be different, but that's another debate). What about, therefore,
> > making the stimulus protocol(s?) available in some metadata? From there,
> the
> > modelling software could extract that protocol and use it, if and only
if
> > the user wants it.
> >
> > I would imagine you guys have already discussed this before, in which
case
> I
> > would appreciate any conclusion that has been drawn about this.
>
> While I think that we have discussed this before, but perhaps not
> officially, I'll kick it off here :-)
>
> 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...

> From Andrew Miller:
>
> There probably is a case for making stimulus protocols a little more
> explicit in domain specific interfaces. The proper way to handle this
> without compromising the generality of CellML would be to add metadata
> describing which variables are, for example, stimulus voltages, and
> which components (which will generally be imported components) are
> stimulus currents.

This might be a very useful thing to have indeed (or rather: it wouldn't
harm having such information available).

> A domain specific command could then perform tasks
> such as, for example, replacing the stimulus protocol connected to the
> designated variables with a 'standard' stimulus of a user defined nature
> (which could be an arbitrary mathematical function, or even a FieldML
> field).
>
> A curve-based graphical editor for some small subset of MathML (which
> lets you drag points around on the screen to edit MathML parameters)
> would also make it easier to input and edit stimuli.

Yes, that's the kind of thing we had started doing long before CellML was
available, and therefore something that some modellers would at least very
much welcome indeed.

Alan.

---

• [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/17/2007
  • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/17/2007
    • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/17/2007
      • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/17/2007
        • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/17/2007
        • [cellml-discussion] embedded stimulus currents in CellML models, James Lawson, 07/18/2007
          • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/18/2007
            • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/19/2007
              • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/19/2007
              • [cellml-discussion] embedded stimulus currents in CellML models, James Lawson, 07/19/2007
              • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/19/2007
              • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/19/2007

---

Archive powered by MHonArc 2.6.18.