CellML Discussion List

Text archives Help


[cellml-discussion] Identifying time-points at which the modelbecomes stiff


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Identifying time-points at which the modelbecomes stiff
  • Date: Wed, 18 Apr 2007 15:35:25 +1200

David Nickerson wrote:
> Hi Andrew,
>
> Are you thinking that you'd have metadata like "when variable IStim is
> non-zero reduce maxDt to x" or more like "when variable IStim is
> non-zero system becomes stiff" and let the software decide the best way
> to handle that?
I was actually thinking more along the lines of "when stiff_indicator is
zero, a transition to stiffness occurs". stiff_indicator would be
expected to be defined in such a way that it gradually approaches zero,
rather than suddenly falls to zero, or it is stiff too and so not much
help. The key point here is that we are trying to define exact points
(which could even be a singularity), rather than ranges over which the
integrator has to be more careful.

It would be up to the software how to handle this, but one possible
algorithm would be to derive a polynomial (linear equation?), and solve
for stiff_indicator = 0. The integrator would then make sure that it
stops at or before the point (and if before, it can re-evaluate the
polynomial). This would work well for the typical stimulus protocol
case, because you know well ahead of time when the stimulus is going to
happen, so you can ensure that stiff_indicator falls linearly towards
zero right back at the previous actual potential. For other models, such
as for yeast cell cycle division, you might not be able to get a linear
equation (and so a singularity wouldn't work, you would need a short
period over which the changes could happen), but you can still give the
integrator a better idea that something is going to happen, which would
in effect cause it to go into progressively shorter timesteps until it
hits the point.
> I guess these are not exclusive choices, but the first
> one probably belongs in the simulation metadata whereas the second could
> be external to the simulation metadata.
>
I think it is potentially useful information about the mathematics, so
it could be in its own mini-specification, and referenced by the
simulation metadata.
> Might also be worth noting that there will probably be overlap with the
> TEDDY project when representing this kind of information, but not really
> too sure yet where TEDDY is going.
>
Although from the initial discussions, it looks like it might be a
little too general to be able to work with for this type of application.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page