Section 3.4.8 initially confused me

[sbmlsecretary]

The breakdown of when different rules/assignments applied (the 1. 2. 3. 4. bit) initially confused me: Because the description of 'InitialAssignment' stuff was in the 'At time t(i)' section, and it included a description of what happened between t(i) and t=0, I thought the next section was going to apply only *after* t=0. I would recommend breaking things down slightly differently:

1. At time t(i):

-(first paragraph unaltered) -Any InitialAssignment definitions apply, and can override initial values -Any AssignmentRules and AlgebraicRules apply, and can also override initial values (note that no single value may have both an InitialAssignment and an AssignmentRule. [And maybe it's bad practice but legal to have AlgebraicRules that override InitialAssignments?]

2. at time t(i) < t < 0: [Or maybe t(i)<= t <= 0 ?]

-InitialAssignment definitions apply -AssignmentRules apply

3. at time t=0: [Same current paragraph]

4. at time t>0: [Same current paragraph]

Reported by: luciansmith

Original Ticket: sbml/sbml-specifications//147

[sbmlsecretary]

The separation according to time intervals which Lucian suggest is clearer than the current split. It is not immediately clear that the section about t_i is actually valid for the time interval t_i <= t <= 0.

Original comment by: shoops

[sbmlsecretary]

I am accepting this issue as valid.

Original comment by: shoops

[sbmlsecretary]

I am accepting this issue as valid.

Original comment by: s_sahle

[sbmlsecretary]

I also notice t_i is not defined in the specs. From the context it seems t_i is the earliest time that is referenced by a delay term in the model, but this may be unknown. Delay can be an arbitrary mathematical expression and therefore t_i is only known after the simulation is finished.

About the clash between algebraic rules and initial assignments: This is indeed a problem, but I think the spec is sufficient. The spec says that the model must not be overdetermined. I guess this means that the model also must not be overdetermined before t=0. So no, an algebraic rule cannot override an initial assignment. Basically what can happen now is that we can encode a model that is exactly determined until t=0 but underdetermined after t=0. This is certainly bad practice, but we decided in the past that underdetermined models should not be illegal. Not allowed are models that are exactly determined after t=0 but overdetermined before t=0.

Original comment by: s_sahle

[sbmlsecretary]

• milestone: --> Reported/Proposed

Original comment by: mhucka

[sbmlsecretary]

I am accepting this issue as valid.

Original comment by: fbergmann

[sbmlsecretary]

Ha, I wasn't even an editor back then. At any rate, I can have a go at writing an updated specification, incorporating both my own original ideas of how to re-order the presentation, and include the clarification from Sven below.

Original comment by: luciansmith

[sbmlsecretary]

I agree with the proposed change and that it should be done.

Original comment by: luciansmith

[sbmlsecretary]

I agree with the proposed change and that it should be done.

Original comment by: sarahkeating

[sbmlsecretary]

I am accepting this issue as valid.

Original comment by: ccmyers

[sbmlsecretary]

• status: open --> pending

Original comment by: lenov

[sbmlsecretary]

• labels: Level 2 Version 4 --> Level 2 Version 4, Level 3 Version 1 Core
• Description has changed:

Diff:

--- old
+++ new
@@ -1,12 +1,12 @@
-The breakdown of when different rules/assignments applied \(the 1. 2. 3. 4. bit\) initially confused me:  Because the description of 'InitialAssignment' stuff was in the 'At time t1' section,  and it included a description of what happened between t1 and t=0, I thought the next section was going to apply only \*after\* t=0.  I would recommend breaking things down slightly differently:
+The breakdown of when different rules/assignments applied \(the 1. 2. 3. 4. bit\) initially confused me:  Because the description of 'InitialAssignment' stuff was in the 'At time t(i)' section,  and it included a description of what happened between t(i) and t=0, I thought the next section was going to apply only \*after\* t=0.  I would recommend breaking things down slightly differently:

-1\. At time t1:
+1\. At time t(i):

 -\(first paragraph unaltered\)
 -Any InitialAssignment definitions apply, and can override initial values
 -Any AssignmentRules and AlgebraicRules apply, and can also override initial values \(note that no single value may have both an InitialAssignment and an AssignmentRule.  \[And maybe it's bad practice but legal to have AlgebraicRules that override InitialAssignments?\]

-2\. at time t1 < t < 0:  \[Or maybe t1<= t <= 0 ?\]
+2\. at time t(i) < t < 0:  \[Or maybe t(i)<= t <= 0 ?\]

 -InitialAssignment definitions apply
 -AssignmentRules apply

• status: pending --> open

Original comment by: luciansmith

[sbmlsecretary]

I reported this issue, then became an editor, then rolled off of being an editor, and nothing ever happened on this front. Re-reading the original section (now 3.4.8, page 24) I actually think that we should still make this change! We treat the time before t0 sort of uniquely in SBML, and this needs to be a bit more clear. I'll see if I can draft a new version and send it around.

Original comment by: luciansmith

[sbmlsecretary]

I forgot to indicate: I accept this issue as valid.

Original comment by: mhucka

[sbmlsecretary]

Five years to the month after I originally reported this, I now have written a revised version of this section that hopefully is more clear, and that also addresses a few nuances that have developed between then and now. Technically, enough editors have signed off on this over the years that the status of this could be 'accepted', but now that we have an actual thing to look at, let's poll the current editors instead.

For ease of reference, here's my newly-written section. For L2v5, much of the Event stuff would be removed:

---

The following is how the definitions of the model should be applied:

1. At time ti: • Every Species, SpeciesReference, Compartment, Parameter, and package element with mathematical meaning whose definition includes an initial value is assigned that value. If an element has constant=“false”, its value may be changed by other constructs or reactions in a model according to the steps below; if constant=“true”, only an InitialAssignment can override the value. • All InitialAssignment definitions take effect, overriding any initial values on any Species, SpeciesReference, Compartment, Parameter, or package element with mathematical meaning. • All AssignmentRule and AlgebraicRule definitions take effect. These rules also override any initial values of any Species, SpeciesReference, Compartment, Parameter, or package element with mathematical meaning. Only elements set constant=“false” can be affected in this way. (Note there cannot be both an AssignmentRule and an InitialAssignment for the same identifier, nor may an AlgebraicRule determine the value of any element that has an InitialAssignment; see Section 4.9.) • The identifier of any Reaction is the value of its KineticLaw. This cannot yet affect the Species referenced by the Reaction, but the identifier itself may appear in other Math elements calculated above. • The value of any Event Trigger is the value of that Trigger’s initialValue attribute. This cannot be overridden.

2. For time ti < t < 0 • Any element with mathematical meaning with no InitialAssignment or Rule that targets it continues to have its initial value, as defined by the relevant attribute. • Any InitialAssignment definition continues to take effect. Since InitialAssignments contain mathematical formulas, different values may be computed at each time step t in ti ≤ t ≤ 0. • Any AssignmentRule or AlgebraicRule definition continues to take effect, and may not be overridden. Again, different values may be computed at each time step t in ti ≤ t ≤ 0. • The identifier of any Reaction continues to be the value of its KineticLaw. Again, different values may be computed at each time step t in ti ≤ t ≤ 0. 14 • The value of any Event Trigger continues to be the value of that Trigger’s initialValue attribute.

3. At time t = 0: • The value of any Event Trigger is now calculated according to the Trigger’s Math child, and may therefore cause the Event to trigger and its EventAssignments to execute. This can happen directly due to its value changing from an initialValue of “false” to a now-calculated value of “true”, or it can happen indirectly due to an event cascade initated by a direct change in a different Event. (Note that an Event cannot be defined to change the value of a variable that is also the subject of an AssignmentRule, nor can it change the value of a variable whose value is determined by an AlgebraicRule; see Section 4.12.) • Any element with mathematical meaning with no InitialAssignment or Rule that targets it continues to have its initial value, as defined by the relevant attribute, but may now be overridden by any EventAssignment executed as above. • Any InitialAssignment definition continues to take effect, but may now be overridden by any EventAssignment executed as above. • Any AssignmentRule or AlgebraicRule definition continues to take effect, and may not be overridden. • The identifier of any Reaction continues to be the value of its KineticLaw. It still does not affect the value of any referenced Species, even if the value of its fast attribute is set to “true”. • Constraint definitions begin to take effect (and a constraint violation may result; see Section 4.10).

4. For time t > 0: • The value of any element with mathematical meaning may now be overridden by any construct in SBML (though it may retain its original value if no such constructs apply). • The value of any element with an InitialAssignment may also now be overridden by any construct in SBML (though it may retain the value set by the InitialAssignment if no such constructs apply). • Any AssignmentRule or AlgebraicRule definition continues to take effect, and still may not be overridden by any other SBML construct. • RateRule definitions can begin to take effect. • Any Reaction can begin to affect its referenced Species. Its identifier continues to be the value of its KineticLaw. • EventAssignments may continue to execute. • System simulation proceeds.

Original comment by: luciansmith

[sbmlsecretary]

Quite verbose, but I believe it is correct.

Chris

Original comment by: ccmyers

[sbmlsecretary]

Just as a note: based on discussions on the editor's list, I now note that fast reactions can affect the values of parameters at t=0, and that this in turn can trigger events.

Original comment by: luciansmith

[sbmlsecretary]

• status: open --> closed
• Group: Reported-Proposed --> Accept-no-conformance-implications

Original comment by: luciansmith

[sbmlsecretary]

OK, new versions committed to SVN for both L3v2 and L2v5. Changes will be incorporated into the new releases of both versions.

Original comment by: luciansmith