>> 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 :-) 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 :-) >> 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). yep - and I think this is part of the general annotation of variables in models. Again, there is really nothing special about a stimulus current variable in a model, just in the simulation software's use of the variable. >> 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. Its also something that is currently available in CMISS :-) Andre. _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
