Menu
▾
▴
#211 Spec unclear re what changes species amounts in some cases
closed
5
2014-05-27
2012-02-15
No
The specification is clear about how to change a species quantity when it participates in a reaction, and when it is the subject of a rate/algebraic/assignment rule, etc.
What is not clear is what to do when it does not participate in anything at all, but its compartment changes. Does the amount not change? Or does the concentration not change? The consensus among the editors seems to be 'the amount does not change', so this needs to be explicitly stated in the spec.
Secondly, it needs to be decided if a species set 'hasOnlySubstanceUnits=false', whose compartment is set 'constant=false', is allowed to be set 'constant=true' or if this is a validation error. (Or, more complicatedly, if the rule needs to be 'its compartment is actually changed by constructs in the model'.) My vote is for 'it is a validation error if [the species in question] is set 'constant=true' but its compartment is set 'constant=false'.'
Clarification in general will need to be added to the spec, perhaps including Table 4.
I agree with the proposed change and that it should be done.
I am accepting this issue as valid.
I accept that this is a valid issue, but I believe all problems can be addressed by interpreting constant as true is that the amount is constant and not the concentration.
I agree with the proposed change and that it should be done.
That the amount should stay constant.
I am accepting this issue as valid.
I am accepting this issue as valid.
With respect to the first point, doesn't the text on p. 46 lines 14-28 explicitly answer this?
With respect to the second point, doesn't the text on p. 46 lines 35-39 implicitly answer this?
I think Mike is correct.
I think you're right. However, I would still recommend a change to Table 4, from 'What can change the species quantity?' to 'What can change the species amount?"
Actually, I would recommend that change for the entirety of section 4.6.6 (page 45): wherever it now says 'quantity' change it to say 'amount', and the same when it says 'its value'. I forget exactly, but when I encountered this issue, I probably looked at 4.6.6 to try to answer it. (Perhaps a reference to 4.6.8 from 4.6.6 would be good?)
I'm changing the title of this item to reflect that the issue is a matter of clarity.
Table 4 should not be changed. The reason the term "quantity" is used is that in the cases being described by Table 4, it can be that either amount or concentration changes. To change 'quantity' to 'amount' in the table would actually be incorrect.
The section 4.6.6 similar must not change for that reason.
However, readers could perhaps be better alerted to the possible impact of hOSU. I think a warning in the caption of Table 4, referring to 4.6.8, might be a good diea.
I still believe 'amount' is indeed the correct term. If the species has 'hasOnlySubstanceUnits=false', and is set 'const', its quantity can actually be changed by changing the volume of its compartment. Its amount, however, cannot be changed.
Table 4, and, indeed, the entire section, only concerns itself with how the species amount changes in time. Whether the species concentration changes in time is dependent on both the species *and* the compartment size changing.
Section 4.6.6 and table 4 are not solely concerned with the case of species with hOSU=false and constant=true. Consider a species which (1) has hOSU=false, (2) constant=false, (3) is in a compartment of constant size, and (4) is the subject of (e.g.) an assignment rule. In that case, the assignment will result in a change to BOTH its concentration and amount. This is within the scope of section 4.6.6 and table 4. Therefore, it is not true that table 4 and section 4.6.6 are only concerned with how the species amount changes in time.
We are talking about this from opposite ends of the same issue. What I am concerned about is, for example, the first line of Table 6. It says that if a species is flagged constant=true and boundarycondition=true, that the 'species quantity' 'never changes'. This is false. The species *amount* never changes, but the species quantity may change anyway. The same can be said for that entire column. We must either change the title of that column, "What can change the species quantity?" to "What can change the species amount?" or we must change the entries in that column to add "Or a rule or event that changes the species compartment size if the species has the attribute 'hasOnlySubstanceUnits=false' to all four entries. Of those two options, I believe the former is cleaner and easier to understand.
So while the possibilities you mention are indeed true, the point of section 4.6.6 (in my head) is to describe what the *restrictions* are for various combinations of the 'constant' and 'boundaryCondition' attributes. Those restrictions concern themselves with species amount. They do not place any additional restrictions on species concentration that could not be derived from the restrictions on amount, and they do not simply apply wholesale to species concentration because the compartment size can change.
Consider also the whole mathematical purpose of the 'constant' flag: its use in algebraic rules. When a species is flagged 'constant=false' and 'hasOnlySubstanceUnits=false', appears in no reactions or rules other than a single algebraic rule, that rule may be used to change the species concentration. However, concentration is a function of two 'truths' (amount and compartment size) and mathematically, a solver could choose either or both to be determined by the algebraic rule. However, we resolve that potential ambiguity by declaring that it is actually the *amount* that the algebraic rule may change, and that the compartment size is controlled independently. A model with a 'constant=false' compartment C, a constant=false and hOSU=false species S, an initial size of 5 for C, an initialConcentration of 10 for S, and a single rule '0=S - 3" is an exactly determined SBML model, even though it is mathematically overdetermined, because SBML has rules that state that rules override initial* attributes, and because rules change species amounts, not concentrations (directly).
Similar arguments can be made for almost every statement in this section: "When a species is a product or reactant of one or more reactions, its quantity is determined by those reactions." This is incomplete; it should either say "its amount is determined by those reactions" or it should say "its quantity is determined by those reactions and, if it is set hasOnlySubstanceUnits=false, by any rules that affect the size of its compartment."
"The constant attribute indicates whether the species' quantity can be changed at all" Again, incorrect. Either "the species' amount can be changed at all" or "the species' quantity can be changed at all, assuming that it set hasOnlySubstanceUnits=true or, if not, if its compartment size does not change. If the compartment size does change, that is the only SBML construct allowed to change the species quantity."
That's why I claim that this section 'is concerned with' the species amount: because it is placing restrictions on what can change the species amount that is is not placing on species concentration, and because keeping the 'quantity' wording would require extensive changes to the text to caveat the concentration/compartment size issue everywhere that would make the section (IMO) needlessly complicated. I would rather see the section left as-is with a global replacement of 'quantity' with 'amount' and then a single clarifying paragraph added to explain how these amount restrictions affect species with hOSU=false.
I am accepting this issue as valid.
OK, I agree there is a problem with the table and the section needs improved clarity.
I see that actually we have a 4/5 majority of editors agreeing there's a problem, so I'm also going to move this to accepted status.
With respect to whether there are conformance implications, it's unclear to me which way to call it. I'm going to say "without conformance implications" because nothing is being changed and the rest of the spec should have some of these problems clear.
Adding L2v4 to this issue.
Fixed in SVN for both L2v5 and L3v2, and will be part of the forthcoming release of those specifications.