Menu
▾
▴
#266 Limit the 'rate of change' construct targets.
closed
5
2015-06-24
2014-05-30
No
There was some desire, when allowing a new 'rate of change' construct in http://sourceforge.net/p/sbml/sbml-specifications/212/, to not make things too complicated: 'time' was the only element allowed to differentiate against, and a single 'ci' element was the only allowed argument.
For constant arguments, arguments that appear as the target of a RateRule, and arguments that are Species and appear in Reactions, the rate of change is simple to compute (and indeed, probably is already computed by a simulator).
However, for arguments that are targets of AssignmentRules, or which are calculated by using an AlgebraicRule, the rate of change is a much more complicated thing, and in fact might be arbitrarily complicated if people decide to put rates of change in the AssignmentRules itself. Do we:
1) Disallow targets of AssignmentRules and AlgebraicRules from being the argument of the new 'rate of change' function?
2) Allow it, but warn against it?
3) Allow it?
4) Allow it, and also relax the restriction that the argument of the new 'rate' can only be a 'ci' element?
From Andy:
I can think if a few cases where the algebraic rule would be non trivial, and you would need the rate of change of that value.
Say you are using the Guuy-Chapman model to define the charge in a double layer compartment, this would be:
q = n_0 exp(-ze(phi - phi_0)/kT)
and then your would also need the current which is dq/dt.
In my work, I use the Hemholtz model which is simpler, but I don't know if it will yield correct results or not.
In any case, here is an actual real use case of needing the rate of change of a non-trivial assignment rule.
I think Lucian is absolutely correct, it should be up to the simulators to decide for themselves if they (or their users) have a need for such features and decide for themselves if they want to implement this part of the spec or not.
From Chris:
A better approach in my opinion would be to have a separate "math package" that enables the inclusion of the arbitrary mathML "diff" operator. This would enable you to include that package to make it clear that you must support differentiation for your model. In this way, you can have derivatives in your tool that supports it while other tools can instead detect the need for derivatives and tell the user they cannot handle this model.
The "rate" function as it was discussed at Harmony and on the list was not meant to be a derivative function. It was meant as only a means to determine the rate of variables updated by reactions and rate rules as that case is easy to handle and indeed already handled by several tools.
I agree; I think if we allow anything, we we are potentially opening things up to very complicated things that cannot be solved. This is beginning to look like the same scenario as was brought on by the introduction of the 'delay' csymbol.
If there is a math package, than I think its reasonable to restrict the rate function to terminal symbols.
Just have to remember that if you get the rate of a species which is a concentration, and the compartment varies, you need to remember to use the quotient rule.
This is getting way too difficult, for what we intended when using rateOf to begin with. All that was done in COPASI (and in roadRunner) with the annotation, was to expose the rate of an already computed quantity. Species, in the case of reactions, or whatever rate was available with an already existing rateRule.
Supporting just these two, you don't loose any expressiveness. You just make it explicit by forcing tools to export rateRules for the quantities whose rate should be referred to later on. This would also be trivially to implement by everyone.
So I would want an option 5 to say just that.
That would be option one, then! Sorry if that wasn't clear.
OK, so following Frank's suggestion, can we state what the 'rate' csymbol would allow for an argument? Would it be:
1) any variable that appears as the LHS of a RateRule object in the model
2) a Species that appears as a reactant or product in a Reaction object?
(Note that this purposefully does not state "any species", because you could very well define a species that is not referenced in a reaction, or is only a modifier in a reaction.)
That would work, but it might just be simpler to say any argument not defined by a assignment or algebraic rule.
Species that do not participate in reactions and are not defined by rules are really easy, their rate is simply 0.
Note, the tricky bit is there needs to be some language stating that rates can not be recursive, basically the same restriction as on assignment rules.
Consider the rate of change of a species is the species row in the stoich matrix doted with the reaction rate vector. The restriction here needs to be that no kinetic law contributing to the said species can refer to the rate of change of said species.
Rate rules are much easier, but they still need to say that the rate rule expression for a symbol can not refer the to the rate of change of that symbol.
Last edit: Lucian Smith 2014-06-10
Oh, right :-). Yes, that's much easier.
I think it's better stated as the converse: any SId that does not appear as the 'variable' of an AssignmentRule, nor as the solved variable in an AlgebraicRule. Everything else is either going to be zero, or determined by RateRules and/or KineticLaws.
There's one extra niggle, in that a Species set 'hasOnlySubstanceUnits=false' cannot be a target if its Compartment is the target of an AssignmentRule or AlgebraicRule, either.
I think this is pretty clear.
OK, we still need one more editor to vote (Dagmar, Sven, and/or Nicolas), but the new text I came up with for this is as follows:
The rateOf for a symbol whose SId appears as the variable of an AssignmentRule or which is calculated from an AlgebraicRule may not be referenced by the rateOf csymbol. It is not the intention of this csymbol to introduce full symbolic differentiation into core SBML: this is reserved for a possible SBML package. Rather, the intent of this csymbol is intended to allow the modeler access to variables that must be explicitly calculated by a simulator already.
Similarly, it is also not valid to use the rateOf csymbol to reference a Species with a hasOnlySubstanceUnits attribute value of false, whose compartment appears as the variable of an AssignmentRule or whose size is calculated from an AlgebraicRule.
Then, in the paragraph right after the one about algebraic loops:
Similarly, the combined set of RateRule and Reaction objects constitute a set of definitions of the rates of change of various symbols (the variable attributes of the RateRule objects, and the species attributes of the SpeciesReference objects in each Reaction). These rates of change may be referenced directly using the rateOf csymbol, but may not thereby contain algebraic loops---dependency chains between these statements must terminate. To put his more formally, consider a directed graph in which nodes are the rates of change of variables, and directed arcs exist for each appearance of a rateOf csymbol in the model that appears in any RateRule or KineticLaw. Let the directed arcs point from the variable referenced by the rateOf csymbol to the variable or variables that are determined by the Math in which it appears. This graph must be acyclic.
The above text is checked into SVN and can be viewed at https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-2/core/spec/sbml-level-3-version-2-core.pdf if people would like to see how it looks in context before voting.
If accepted, the change will be incorporated into the forthcoming L3v2 specification, and if not, the change will be reverted and replaced by a different explanation.
This text looks good to me.
Chris
Last edit: Lucian Smith 2014-06-26
Fine
This issue has now been accepted, and will be listed on the list of L3 design changes (as opposed to the L3 errata; http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification ), and will be incorporated into the upcoming L3v2 specification.
I realized when going through libsbml's documentation that we probably need to explicitly call out this restriction when talking about AlgebraicRules, too. So, I wrote the following new paragraph, to go at the end of section 4.9.2:
"Finally, any symbol that appears as the target of a \emph{rateOf} \token{csymbol} may not be determined by an \AlgebraicRule. This is because the \emph{rateOf} \token{csymbol} is defined as applying only to symbols whose rates of change are easily determinable, which is not true of the potentially arbitrary math in algebraic rules."
Does this seem reasonable?
Seems reasonable.
I'm not sure the ", which is not true of the potentially arbitrary math in algebraic rules" bit is necessary though.