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: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
  • Date: Thu, 31 Jan 2008 10:56:09 +1300
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
>



Archive powered by MHonArc 2.6.18.

Top of page