Hi Andrew,
This looks quite intriguing. As you mention later in this thread I
currently take the approach of adding an extra real scalar term and
exposing that as a way to hook future (in my case) currents into ion
concentration rate equations. Such and approach works well when I only
have three ion concentrations to deal with, but gets overwhelming when
considering many different species, such as happens when adding
metabolic processes to an electrophysiology model.
Just to try and better understand your proposal by use of an example
closer to my own work and perhaps to also check that this approach is
not limited to metabolic models...
Using this method, I would be able to say that each calcium membrane
current is in the set of calcium fluxes and then formulate the time
derivative of intracellular calcium concentration to be a sum over all
fluxes in that set. Then as I extend the model I simply specify any new
calcium currents as being in the set of calcium fluxes and the
intracellular calcium concentration automatically has them included.
Have I got that right?
Assuming I have understood this, how hard do you expect it to be to
implement support for such set summation techniques in the current
Auckland API implementation? I would guess this falls into the code
generation services rather than the core API implementation?
Andre.
Andrew Miller wrote:
Hi all,
To aid in working out what features we should include in CellML 1.2, I
have been looking into one of the major difficulties with creating
re-usable metabolic models at the moment: that to compute a derivative,
you need to know all the fluxes, but when a model is extended, new
fluxes can be added to the model. Ideally, we should be able to define
CellML 1.2 so that structured types can be leveraged to avoid this issue.
I have come up with an example of how this might look in CellML 1.2.
This is based in part off a discussion that I had earlier with Poul, so
most of the credit for this goes to him, while most of the blame for the
inelegant parts goes to me.
Note that the lambda constructs without any bound variables are there to
defer interpretation of the fluxes until they are taken from the set.
The rationale for needing this is that if we had two statements that a
certain real-valued flux belongs in the set, and two of them happened to
have the same value at a particular point in time, then summing over the
set would only include the flux value once (e.g. saying x is an element
of N, where N is in the natural numbers, means that the value of x is a
natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is
in the set of natural numbers twice). On the other hand, we can have two
different zero argument lambda functions in a set, which just happen to
evaluate to the same value. This is consistent with the declarative
nature of CellML - we are not saying 'add this flux to the set of
fluxes', but rather, we are making a series of statements about what is
in the set of fluxes, and the processing software is then summing over
all fluxes which have been explicitly mentioned. Because we can connect
the set of fluxes up to an importing model, doing things this way gives
a great deal of extra flexibility.
Notes:
1) In practice, the substance could become an import which is re-used
many times, and likewise for components representing various general
types of chemical reactions.
2) I have invented a possible way in which we could remove
directionality from connections. No one has come up with a formal
proposal to do it this way yet.
3) I have followed Randall's earlier suggestion about how to structure
connections without using component_ref. This again needs a formal
proposal and discussion.
4) The model uses a potential way in which we could get rid of the
generality of groups, by replacing group and relationship_ref with a
simple encapsulation element. This again needs to be formally proposed
and discussed at some point.
?xml version=1.0 encoding=UTF-8?
model
xmlns=http://www.cellml.org/cellml/1.1#;
xmlns:c11=http://www.cellml.org/cellml/1.1#;
xmlns:c12=http://www.cellml.org/cellml/1.2#;
xmlns:m=http://www.w3.org/1998/Math/MathML;
name=_1_2_example
component name=substance_x
c12:variable name=fluxes type=set_of_lambda_of_real
units=mol_per_litre_per_second public_interface=yes /
c12:variable name=concentration units=mol_per_litre
public_interface=yes /
c12:variable name=time units=second public_interface=yes /
m:math
m:applym:eq/
m:applym:diff/
m:bvarm:citime/m:ci/m:bvar
m:ciconcentration/m:ci
/m:apply
m:applym:sum /
m:bvarm:cif/m:ci/m:bvar
m:condition
m:apply
m:in/
m:cif/m:ci
m:cifluxes/m:ci
/m:apply
