First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models


Chronological Thread 
  • From: m.cooling at auckland.ac.nz (Michael Cooling)
  • Subject: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
  • Date: Thu, 31 Jan 2008 11:30:14 +1300
> because if connections don't have directionality, then it makes no
> sense in the language to say
> that a connection is from A to B, as opposed to from B to A, and we
> wouldn't want to force users to duplicate information and provide both

Oops I didn't mean to imply directionality. I shouldn't have used the
words 'from' and 'to', sorry. It's not the language that I want to
change.

> I'm not sure what you mean there. In CellML 1.1, there can be attributes
> like public_interface="in" private_interface="out", I have used
> something more like public_interface="yes" or public_interface="no"
> here, thereby removing the directionality - in and out correspond to
> yes, none corresponds to no.

Ah I see. I suspect just having an optional public_interface="yes"
would be the way to go, private="yes" being always
implicit. I.e. private by default, and public includes private. As you
say this will no doubt be discussed later.

> The mathematical model you get from this would be sub-optimal without
> some intelligence on the part of software tools - there would be two
> state variables with identical rates and initial values for the
> concentration of b and the concentration of y

This is why I am wary of such convenience components....they imply an
interface that doesn't really exist - I think they can be useful but
since one never
knows what might get connected to what....
If one tries to use them as an interface to the system that MUST be
used (not that you were doing this)
then you limit the usefulness of your model...essentially you are
assuming that your interface is sufficient for all future
requirements. Even for ion channels, that might not be true in the future.
I think duplications may also be resolved by chosing a particular substance_b
(ie human decision) at model aggregation-time facilitated by tools
identifying this situation.

Quoting Andrew Miller <ak.miller at auckland.ac.nz>:

> Michael Cooling wrote:
>> First just to check that in the the connection elements 'flux' should
>> be 'fluxes'? For example, 'substance_a' component contains no variable
>> 'flux', I assume you meant the set_of_lambda_of_real 'fluxes'?
>>
>
> Thanks for pointing that out - it is hard to validate something before
> there is a specification or tools, so I'm sure there are lots of little
> mistakes like that in my example.
>
>> I think I like this! When will it be released? ;-P
>>
>> I don't know enough about the lambda elements in MathML to check the
>> syntax (BTW which MathML spec would we use for CellML 1.2, MathML
>> 2.0?)
>
> We really can't refer to the drafts for MathML 3, so we are stuck with
> MathML 2 unless MathML 3 goes final before CellML 1.2 is frozen.
>
>> but I think I get the idea and presuming it works like how the
>> species are tracking their own ODEs and the reactions just deal in
>> fluxes for the species involved.
>
> I'm not sure what you mean by 'species are tracking their own ODEs' -
> there is one state variable per species, representing the concentration,
> and the ODE for [species] is in the component for that species.
>
>> We can do this with cellml 1.0 but
>> better to minimise the 'gluing code' of course.
>>
>
> You could express an equivalent mathematical model in CellML 1.0 or
> CellML 1.1, but the point is that the model would not be re-usable if
> you wanted to add a new chemical reaction to it. Instead, you would be
> forced to take one of the following strategies:
>
> a) add an extra real scalar term into the rate equation, and expose
> that all the way up through abxy_system, and then either connect it to a
> variable with constant value 0 if you don't want to add anything to the
> system, or connect it to the new fluxes otherwise. You would need to do
> this for every species in the model, making it very cumbersome to work with.
> b) actually change the original model to add in the new fluxes to the
> rate equation every time you add in a new reaction (i.e. copy and edit
> rather than re-use by reference).
>
>> Minor question: what is the purpose of the component abxy_system? Is
>> this to help monitor the individual fluxes from one location?
>>
>
> abxy_system is a convenience component which provides a top-level
> interface to the system. The model could be run as it is right now, or
> alternatively, you could import abxy_system into another model, and you
> might also want to import the bcyz_system, which has some species in
> common and some species different. The top-level model would import the
> convenience components from abxy_system and bcyz_system, and would then
> connect flux_b from abxy_system to flux_b from bcyz_system, and flux_y
> from abxy_system to flux_y from bcyz_system.
>
> The mathematical model you get from this would be sub-optimal without
> some intelligence on the part of software tools - there would be two
> state variables with identical rates and initial values for the
> concentration of b and the concentration of y (something tools might be
> able to detect and optimise if there was sufficient demand to do so),
> but nevertheless, the two models would have been correct composited into
> a single model.
>
>> Very minor point: I notice the units for your kb terms should be just
>> 'per_second'?
>>
>
> Good catch.
>
>> directionality - I suspect we can just leave those redundant (in/out)
>> tags out?
>>
>
> I'm not sure what you mean there. In CellML 1.1, there can be attributes
> like public_interface="in" private_interface="out", I have used
> something more like public_interface="yes" or public_interface="no"
> here, thereby removing the directionality - in and out correspond to
> yes, none corresponds to no.
>
>> connections structure - makes me think about something that is more a
>> toolset UI issue:
>> One thing I've found when constructing models is that I don't think
>> about connections
>> from an A->B, then A->C then A->D perspective (letters here are
>> components), but by considering all connections from A to other
>> components. For example, if I have a new component A I'd much rather
>> declare something like:
>>
>> <connections from A>
>> <variable whatever1 to B:whateverinB>
>> <variable whatever2 to C:whateverinC>
>> </connections from A>
>>
>> if you see what I mean, rather than hunt around the CellML for each
>> variable connection which is, in my opinion, tedious and poor
>> workflow. Now I don't think what I've written there is as good a
>> structure as the current CellML and I'm not suggesting CellML should
>> be changed, but what I'm getting to is I think it would be helpful for
>> the PCEnv/COR tool if from the UI a more workflow-friendly linking was
>> possible, and it sorted out the more elegant connection components as
>> written in CellML from that.
>>
> Yes, this would have to be provided by tools, because if connections
> don't have directionality, then it makes no sense in the language to say
> that a connection is from A to B, as opposed to from B to A, and we
> wouldn't want to force users to duplicate information and provide both
> directions.
>
> Best regards,
> Andrew
>
>> Cheers,
>>
>>
>> Quoting Andrew Miller <ak.miller at auckland.ac.nz>:
>>
>>
>>> 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:apply><m:eq/>
>>> <m:apply><m:diff/>
>>> <m:bvar><m:ci>time</m:ci></m:bvar>
>>> <m:ci>concentration</m:ci>
>>> </m:apply>
>>> <m:apply><m:sum />
>>> <m:bvar><m:ci>f</m:ci></m:bvar>
>>> <m:condition>
>>> <m:apply>
>>> <m:in/>
>>> <m:ci>f</m:ci>
>>> <m:ci>fluxes</m:ci>
>>> </m:apply>
>>> </m:condition>
>>> <m:apply>
>>> <m:ci>f</m:ci>
>>> </m:apply>
>>> </m:apply>
>>> </m:apply>
>>> </m:math>
>>> </component>
>>>
>>> <component name="substance_a">
>>> <!-- Identical to substance_x. This would normally be defined once
>>> and imported.
>>> -->
>>> </component>
>>>
>>> <component name="substance_b">
>>> <!-- Identical to substance_x. This would normally be defined once
>>> and imported.
>>> -->
>>> </component>
>>>
>>> <component name="substance_y">
>>> <!-- Identical to substance_x. This would normally be defined once
>>> and imported.
>>> -->
>>> </component>
>>>
>>> <!-- Represents a reaction A + B -> X -->
>>> <component name="reaction_a_b_x">
>>> <c12:variable name="concentration_a" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_b" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_x" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="flux_a"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_b"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_x"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <variable name="kf" units="litres_per_mol_per_second"
>>> initial_value="0.5" />
>>> <variable name="kb" units="litres_per_mol_per_second"
>>> initial_value="0.1" />
>>> <variable name="overall_rate" units="mol_per_litre_per_second" />
>>> <m:math>
>>> <m:apply><m:eq/>
>>> <m:ci>overall_rate</m:ci>
>>> <!-- First order law of mass action... -->
>>> <m:apply><m:minus/>
>>> <m:apply><m:times/>
>>> <m:ci>kf</m:ci>
>>> <m:ci>concentration_a</m:ci>
>>> <m:ci>concentration_b</m:ci>
>>> </m:apply>
>>> <m:apply><m:times/>
>>> <m:ci>kb</m:ci>
>>> <m:ci>concentration_x</m:ci>
>>> </m:apply>
>>> </m:apply>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:apply><m:minus/>
>>> <m:ci>overall_rate</m:ci>
>>> </m:apply>
>>> </m:lambda>
>>> <m:ci>flux_a</m:ci>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:apply><m:minus/>
>>> <m:ci>overall_rate</m:ci>
>>> </m:apply>
>>> </m:lambda>
>>> <m:ci>flux_b</m:ci>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:ci>overall_rate</m:ci>
>>> </m:lambda>
>>> <m:ci>flux_x</m:ci>
>>> </m:apply>
>>> </m:math>
>>> </component>
>>>
>>> <!-- Represents a reaction A + X -> Y -->
>>> <component name="reaction_a_x_y">
>>> <c12:variable name="concentration_a" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_y" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_x" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="flux_a"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_y"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_x"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <variable name="kf" units="litres_per_mol_per_second"
>>> initial_value="0.5" />
>>> <variable name="kb" units="litres_per_mol_per_second"
>>> initial_value="0.1" />
>>> <variable name="overall_rate" units="mol_per_litre_per_second" />
>>> <m:math>
>>> <m:apply><m:eq/>
>>> <m:ci>overall_rate</m:ci>
>>> <!-- First order law of mass action... -->
>>> <m:apply><m:minus/>
>>> <m:apply><m:times/>
>>> <m:ci>kf</m:ci>
>>> <m:ci>concentration_a</m:ci>
>>> <m:ci>concentration_x</m:ci>
>>> </m:apply>
>>> <m:apply><m:times/>
>>> <m:ci>kb</m:ci>
>>> <m:ci>concentration_y</m:ci>
>>> </m:apply>
>>> </m:apply>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:apply><m:minus/>
>>> <m:ci>overall_rate</m:ci>
>>> </m:apply>
>>> </m:lambda>
>>> <m:ci>flux_a</m:ci>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:apply><m:minus/>
>>> <m:ci>overall_rate</m:ci>
>>> </m:apply>
>>> </m:lambda>
>>> <m:ci>flux_x</m:ci>
>>> </m:apply>
>>> <m:apply><m:in/>
>>> <m:lambda>
>>> <m:ci>overall_rate</m:ci>
>>> </m:lambda>
>>> <m:ci>flux_y</m:ci>
>>> </m:apply>
>>> </m:math>
>>> </component>
>>>
>>> <component name="abxy_system">
>>> <c12:variable name="concentration_a" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_b" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_x" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="concentration_y" units="mol_per_litre"
>>> public_interface="yes" />
>>> <c12:variable name="flux_a"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_b"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_x"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> <c12:variable name="flux_y"
>>> public_interface="yes"
>>> type="set_of_lambda_of_real"
>>> units="mol_per_litre_per_second" />
>>> </component>
>>>
>>> <c12:connection component_1="substance_a" component_2="reaction_a_b_x">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_a" />
>>> <variable_ref variable_1="flux" variable_2="flux_a" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_b" component_2="reaction_a_b_x">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_b" />
>>> <variable_ref variable_1="flux" variable_2="flux_b" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_x" component_2="reaction_a_b_x">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_x" />
>>> <variable_ref variable_1="flux" variable_2="flux_x" />
>>> </c12:connection>
>>>
>>> <c12:connection component_1="substance_a" component_2="reaction_a_x_y">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_a" />
>>> <variable_ref variable_1="flux" variable_2="flux_a" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_x" component_2="reaction_a_x_y">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_x" />
>>> <variable_ref variable_1="flux" variable_2="flux_x" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_y" component_2="reaction_a_x_y">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_y" />
>>> <variable_ref variable_1="flux" variable_2="flux_y" />
>>> </c12:connection>
>>>
>>> <c12:connection component_1="substance_a" component_2="abxy_system">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_a" />
>>> <variable_ref variable_1="flux" variable_2="flux_a" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_b" component_2="abxy_system">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_b" />
>>> <variable_ref variable_1="flux" variable_2="flux_b" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_x" component_2="abxy_system">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_x" />
>>> <variable_ref variable_1="flux" variable_2="flux_x" />
>>> </c12:connection>
>>> <c12:connection component_1="substance_y" component_2="abxy_system">
>>> <variable_ref variable_1="concentration"
>>> variable_2="concentration_y" />
>>> <variable_ref variable_1="flux" variable_2="flux_y" />
>>> </c12:connection>
>>>
>>> <c12:encapsulation>
>>> <component_ref component="abxy_system">
>>> <component_ref component="substance_a"/>
>>> <component_ref component="substance_b"/>
>>> <component_ref component="substance_x"/>
>>> <component_ref component="substance_y"/>
>>> <component_ref component="reaction_a_b_x"/>
>>> <component_ref component="reaction_a_x_y"/>
>>> </component_ref>
>>> </c12:encapsulation>
>>>
>>> <!-- Units would also be defined here, as in CellML 1.1... -->
>>> </model>
>>>
>>> _______________________________________________
>>> cellml-discussion mailing list
>>> cellml-discussion at cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>>
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



Archive powered by MHonArc 2.6.18.

Top of page