Address the interpretation of rateOf in a stochastic setting

[sbmlsecretary]

UPDATE: Sven's last point has not been explicitly addressed in the draft specification: what do we say about stochastic simulations?

Option 1: We already say explicitly how to calculate rateOf: it's either the value of the relevant RateRule, or it's calculated from the various KineticLaws of the Reactions in which the symbol appears. We simply add a sentence saying that this applies to stochastic simulations as well.

Option 2: We say that the behavior is undefined for stochastic simulations, as Sven suggests.

---

Sven Sahle wrote the following quite some time ago, about the introduction of the rateOf csymbol. I'm logging this here to make sure it does not get dropped.

I agree with the way of encoding this (actually the final result is also the one I prefer). But I think we will have to be careful about specifying what is allowed as the argument, and about making sure that in SBML core (but may be not in future extensions) "time" is the only allowed differetiation variable.

Specifically we have to decide if the construct may only be used to access the rates of variables that are readily available to the simulation algorithm (i.e. species concentrations controled by reactions, variables with ODE rules, constant values), or if the construct can also be used to instruct the simulator to calculate rates, e.g. for variables that are determined by an assignment rule. In the latter case we would probably introduce models that only some simulators could simulate, e.g. COPASI currently only handles the first class.

Another issue is that the behaviour of this construct in the case of discrete events is tricky.

And perhaps more importantly: What do we say about non-ODE type modeling? My suggestion is that we say the the construct is defined for continuous simulation approaches, and that any stochastic simulator can decide whether to reject the model or to try to somehow approximate the bahviour of the deterministic simulation.

Reported by: mhucka

Original Ticket: sbml/sbml-specifications//331

[sbmlsecretary]

These are all important issues, but all but the last have been addressed in the current L3v2 draft spec:

From section 3.4.6, page 25:

"...represents the instantaneous rate of change, with respect to time, of an entity in the model." "...The intent of this csymbol is to provide a means for models to refer to quantities that must be naturally be computed as part of doing a dynamical analysis of a model. The rateOf csymbol is not intended to provide full numerical differentiation capabilities." "...anything whose value is directly or indirectly determined by an algebraic rule or an assignment rule is excluded." "...In the event of a discontinuity, such as might happen due to an Event, a piecewise function, the beginning of a time course simulation (i.e., at t = 0), or due to a new construct defined in a package, the rate of change is defined as the right-handed rateOf for the symbol, that is, the derivative with respect to time of the symbol moving forward in time from the current time, and not the derivative with respect to time from the recent past up until the current time. Thus, the rateOf of a symbol will always be calculable from the set of current values of symbols in the model."

For the last point: we don't explicitly mention stochastic simulations but we do say: "The rateOf for a symbol whose SId appears as the variable of a RateRule is the numerical value of that RateRule" and "The rateOf for the amount of a non-boundary Species that appears in one or more reactions can be calculated from the stoichimetries and KineticLaw Math of every Reaction in which the species appears, plus any appropriate conversionFactor values"

(There's then a longer discussion about how to calculate the rateOf when both the species and its compartment are changing.)

It seems to me that all we would need to say is that the above rules apply even to stochastic simulations: that the rate of change of a symbol is always calculated as described, even if it does not happen to be changing at the time.

Original comment by: luciansmith

[sbmlsecretary]

• summary: Address these issues about the limits of rateOf --> Address the interpretation of rateOf in a stochastic setting
• Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,10 @@
+UPDATE:  Sven's last point has not been explicitly addressed in the draft specification: what do we say about stochastic simulations?
+
+Option 1: We already say explicitly how to calculate rateOf: it's either the value of the relevant RateRule, or it's calculated from the various KineticLaws of the Reactions in which the symbol appears.  We simply add a sentence saying that this applies to stochastic simulations as well.
+
+Option 2: We say that the behavior is undefined for stochastic simulations, as Sven suggests.
+
+----
 Sven Sahle wrote the following quite some time ago, about the introduction of the `rateOf` csymbol. I'm logging this here to make sure it does not get dropped.

 >I agree with the way of encoding this (actually the final result is also the one I prefer). But I think we will have to be careful about specifying what is allowed as the argument, and about making sure that in SBML core (but may be not in future extensions) "time" is the only allowed differetiation variable. 
@@ -6,4 +13,4 @@

 >Another issue is that the behaviour of this construct in the case of discrete events is tricky. 

->And perhaps more importantly: What do we say about non-ODE type modeling? My suggestion is that we say the the construct is defined for continuous simulation approaches, and that any stochastic simulator can decide whether to reject the model or to try to somehow approximate the bahviour of the deterministic simulation. 
+>And perhaps more importantly: **What do we say about non-ODE type modeling? My suggestion is that we say the the construct is defined for continuous simulation approaches, and that any stochastic simulator can decide whether to reject the model or to try to somehow approximate the bahviour of the deterministic simulation. **

Original comment by: luciansmith

[sbmlsecretary]

I agree with Lucian that the L3V2 specification makes this point already clear. Just adding a sentence sayingh that the above rules also apply in non-ODE scenarios would be sufficient to answer potential questions.

Original comment by: andreas-draeger

[sbmlsecretary]

Here's my proposed addition:

"In simulations that progress in a stepwise fashion, such as stochastic simulations, the \emph{rateOf} \token{csymbol} is still calculated as above, from any appropriate \RateRule or \KineticLaw. This effectively means that for stepwise simulations, the \emph{rateOf} indicates the expected average rate of change of the corresponding symbol over time, even when the actual rate of change may be zero or discontinuous."

Original comment by: luciansmith

[sbmlsecretary]

Thanks Lucian, reads good to me.

Original comment by: dagwa

[sbmlsecretary]

I think (but I may be wrong) that we are discussing a non-problem. RateOf is a model construct, like the rateRules etc. It is used to build equations. The way these equations are then used is a simulation issue. When simulations are concerned, everything is generally discrete. So I am uncomfortable with "In simulations that progress in a stepwise fashion". What would be a simulation that would not progress in a stepwise fashion? There are no differences on this front between stochastic and deterministic algorithms. Actually, there are more differences between SSA and SDEs than between SDEs and ODEs.

We do not have to tell people how to calculate rateOf, no more than we tell them how to estimate the values from rateRules or ODEs built from kineticLaws.

rateOf "...represents the instantaneous rate of change, with respect to time, of an entity in the model."

That's it. No need to add anything. The fact that Sven mentions COPASI is a signature of the problem: it is ... yes, you got it ... a tool issue.

To answer Sven's 1st question

"Specifically we have to decide if the construct may only be used to access the rates of variables that are readily available to the simulation algorithm (i.e. species concentrations controled by reactions, variables with ODE rules, constant values), or if the construct can also be used to instruct the simulator to calculate rates, e.g. for variables that are determined by an assignment rule."

The construct can be used for whatever purpose a modeller would have.

To answer Sven's 2nd question

"What do we say about non-ODE type modeling?"

Nothing.

Original comment by: lenov

[sbmlsecretary]

"What would be a simulation that would not progress in a stepwise fashion?" The answer is 'a simulation that progresses in a continuous fashion'.

The issue is that in a stochastic simulation in particular, the rate of change of all model variables is always literally zero! Everything proceeds without changing at all, until a stochastic event hits, the levels take new values, and then everything proceeds without changing at all again. It is equivalent to an SBML model with no rules nor reactions, but only events. That's what I meant by a 'stepwise' simulation.

It is reasonable to ask the question, then, 'if I'm treating reactions as a series of discrete events, is the 'rateOf' the species that participate in that Reaction simply zero?' That's the purpose of the paragraph: it claims "You calculate the rateOf from rates and reactions, regardless of your simulation context."

Original comment by: luciansmith

[sbmlsecretary]

Again with the "how to model" stuff :-) What do we say about non-ODE type modeling?"

It would be good if such models included annotation that included their definition of RateOf?

Original comment by: bgoli

[sbmlsecretary]

Again, I might be wrong, but what you describe seems exactly what happens with every "deterministic" simulator as far as I know. You have values at T and values at T+DT, computed based on the values at T. DT can be fixed or variable depending on the algorithm. The only difference between SSA and ODEs is that in SSA processes are fired independently, while ODE simulators combine all processes affecting given variables (this is not always true. For instance, ECell3 compute the effect of processes separately, irrespective of the deterministic or stochastic nature). And of course SDE simulators are just ODE simulators with a noise function.

Original comment by: lenov

[sbmlsecretary]

My impression is that ODE simulators might output values at discrete timepoints, but their underlying fundamental model is (or can be) one where values are changing continually (and smoothly). It is possible to calculate a continuous interest rate that will be slightly different from one where you compound the interest at discrete intervals, even when those intervals are very short. The whole premise of calculus is that it is an exact mathematical model of continuous processes because it is taking infinitely-small steps.

Even if you can't account for how your values affect other values as they change within whatever dT you've chosen, a deterministic simulation still maintains that it is a model of a ramp, and not a model of a staircase. A stochastic simulation, in contrast, maintains that it is indeed a model of a staircase, and not a model of a ramp.

I'm getting off-topic, but this is interesting ;-)

In the end, I think it is worth it to say, "whether you're modeling ramps or staircases, you still calculate the value of a 'rateOf' function the same way."

Original comment by: luciansmith

[sbmlsecretary]

Are you suggesting that different simulation environments calculate rateOf differently? I was hoping that we could tell everyone to do the same thing; that 'rateOf' was calculated independently of your simulation paradigm.

Original comment by: luciansmith

[sbmlsecretary]

I don't know enough about stochastic simulation implementations to make any useful statement regarding this issue, but, that's what I imply from Sven's email. Maybe we should throw this onto sbml-discuss for comment and see what other people think?

Original comment by: bgoli

[sbmlsecretary]

I agree. rateOf of variables updated discretely does not make sense. Note updated discretely is not the same thing as updated on a time step. The time step is an approximation of a continuous change. There is defined values between the time points. For discrete updates, the value is fixed between the time points.

Ideally, this should not be about what simulator is used, since a stochastic simulation of reactions may be on a model with rate rules updated continuously. So, calculating rateOf for species updated by rate rules is the same regardless of simulation method. The tricky point is for variables updated by reactions. These inherently require one to know if it is being simulated using ODEs or SSA.

So, I guess my compromise would be that rateOf is undefined for species updated by reactions for stochastic simulations, but it is still defined for species updated by rateRules.

Original comment by: ccmyers

[sbmlsecretary]

I'm in the same position as Brett. I dont know enough about stochastic simulators to have an informed opinion. Maybe this is a question for sbml discuss.

Original comment by: sarahkeating

[sbmlsecretary]

Considering the comments on sbml-discuss Lucian's text is good to go.

Original comment by: bgoli

[sbmlsecretary]

For reference, the discussion in question is at

https://groups.google.com/forum/#!topic/sbml-discuss/yP9XzUV4bNs

The paragraph in question has been in SVN (so people can see it in context), and I'm going to declare that the above discussion now has Brett, Andreas, and Dagmar voting in favor of it. If Nicolas or Sarah would like to propose further changes or would like to vote against the change in general, speak now--I'll close the issue in a week or so otherwise, and add this to the list of design changes for L3v2.

Original comment by: luciansmith

[sbmlsecretary]

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

Original comment by: luciansmith

[sbmlsecretary]

Hearing no objections, I'm closing this issue as 'pending'. The change is now part of the L3v2 SVN, and will be released with that specification. It has been added to the list of 'design changes' for L3v2: http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification

Original comment by: luciansmith

[sbmlsecretary]

• status: pending --> closed

Original comment by: luciansmith

[sbmlsecretary]

With the release of L3v2, this issue is now resolved.

Original comment by: luciansmith