Hmm, I dunno. I wouldn't want to do this unilaterally, but would rather poll the community on this one. It seems to me that at this point, people have worked out how to ignore it if they like, and many have indeed implemented it successfully. I would rather go back in time and remove it than remove it now, I think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lucian wrote "and many have indeed implemented it successfully." Who for instance, and how did they implement it? How does it affect the simulation results? It seems almost a simulation issue to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In order to answer the question of who has implemented 'fast', I looked at the results of the SBML Software Survey. The following simulators had a checkmark in the box for indicating support for "fast reactions": SBMLsimulator, iBioSim, JSim, JigCell and ProMoT. In addition, I believe LibSBMLSim (from Funahashi's group) must implement support for 'fast' because it passes all the SBML test suite cases.
However, given the level of debate we're having, it seems to me the right thing is to bring up this question on sbml-discuss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the theory that all issues for which we don't have consensus should be set 'open', I'm re-setting this 'open'. At the very least, we would need to work out with the community what 'depreciating the fast flag' would look like.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see fast deprecated through a process of L3V2 deprecation and subsequent removal (after an appropriate community vote on whether it should stay or not).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many systems are composed of reactions occurring at different time scales. The fast flag is an ideal way to identify them and is ideal for implementing such techniques like operator splitting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I strongly agree with Andy Somogyi. In actuality, the ability to specify the speed of reactions withing a model is important, even if most simulators do not (currently) take advantage of this feature. As the number and size of models increase, this kind of feature may become extremely relevant. Deprecating 'fast' seems antinomic with the 'Hierarchical Model Composition' package which allows hierarchically combining models, as the models that are combined may very well behave at different time scales. Having a way to specify reaction speed could prove to be a critical asset in optimizing calculations and decreasing simulation time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMHO, hierarchical models is precisely why we should not rely on such an attribute. What is fast in a context might not be in another. The only way to choose whether to simulate kinetics or assume equilibrium is to know and compare the real velocities. As you say " the ability to specify the speed of reactions withing a model is important". The "fast" attribute is exactly the opposite. It means "ignore the speed of reactions. Assume they are so fast they do not affect the system".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. The fast flag is only meaningful for simulation if you also have kinetic information. If you have kinetic information, then the software can determine which reactions are fast and optimize simulation accordingly. We do this type of automated abstraction routinely and is described in detail in my textbook. This approach is much more efficient and accurate than to rely upon the modeler to know when it is appropriate to label a reaction as fast which as Nicolas correctly points out could change in a new context.
Chris
Last edit: Lucian Smith 2014-05-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nicolas, Chris: I do agree with you that the 'fast' attribute is definitely qualitative at best. If there are ways to extract this piece of information from the kinetic model equation, then the solver can take appropriate steps to optimize calculations. Thank you Chris for pointing out useful material.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As 3/5 editors have voted in favor of this change, I would change the status of this issue to 'accepted' except that I also have now added a section in SVN, so I'm just changing it to 'closed'. There's a new validation warning and this added text:
"Due to a number of factors, including the slow uptake of support for Reactions with a 'fast' flag of 'true', confusion about how exactly to implement said support, and the advent of new modeling techniques which allow more nuanced approaches to reactions that occur at different timescales (particularly for hierarchical and multi-scale modeling), the 'fast' flag is now considered deprecated for SBML Level 3. The 'fast' flag will be removed in future versions of SBML, and the speed of any Reaction will be solely determined by its KineticLaw. It is now considered best practice to only produce models with a 'fast' flag of 'false'. To achieve the same or similar effects as setting 'fast' to 'true', one should instead either set the KineticLaw to a value in the desired timescale, or achieve an instantaneous effect with an AssignmentRule or AlgebraicRule."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am accepting this issue as valid.
I would indeed like to see this one deprecated.
I am accepting this issue as valid.
Hmm, I dunno. I wouldn't want to do this unilaterally, but would rather poll the community on this one. It seems to me that at this point, people have worked out how to ignore it if they like, and many have indeed implemented it successfully. I would rather go back in time and remove it than remove it now, I think.
I agree with Lucian. I think this is one we can propose but need to look at the response to that.
I am accepting this issue as valid.
I am accepting this issue as valid.
Lucian wrote "and many have indeed implemented it successfully." Who for instance, and how did they implement it? How does it affect the simulation results? It seems almost a simulation issue to me.
In order to answer the question of who has implemented 'fast', I looked at the results of the SBML Software Survey. The following simulators had a checkmark in the box for indicating support for "fast reactions": SBMLsimulator, iBioSim, JSim, JigCell and ProMoT. In addition, I believe LibSBMLSim (from Funahashi's group) must implement support for 'fast' because it passes all the SBML test suite cases.
However, given the level of debate we're having, it seems to me the right thing is to bring up this question on sbml-discuss.
On the theory that all issues for which we don't have consensus should be set 'open', I'm re-setting this 'open'. At the very least, we would need to work out with the community what 'depreciating the fast flag' would look like.
At the SBML Editors' meeting in Paris during COMBINE 2013, we decided we should poll the community. The next step is to do the poll.
I would like to see fast deprecated through a process of L3V2 deprecation and subsequent removal (after an appropriate community vote on whether it should stay or not).
I forgot to indicate:
I accept this issue as valid.
I accept this issue as valid.
I am accepting this issue as valid. And agree with Brett's proposed solution (comment on 2014-03-14).
I accept this issue as valid and that it should be done.
Many systems are composed of reactions occurring at different time scales. The fast flag is an ideal way to identify them and is ideal for implementing such techniques like operator splitting.
I strongly agree with Andy Somogyi. In actuality, the ability to specify the speed of reactions withing a model is important, even if most simulators do not (currently) take advantage of this feature. As the number and size of models increase, this kind of feature may become extremely relevant. Deprecating 'fast' seems antinomic with the 'Hierarchical Model Composition' package which allows hierarchically combining models, as the models that are combined may very well behave at different time scales. Having a way to specify reaction speed could prove to be a critical asset in optimizing calculations and decreasing simulation time.
IMHO, hierarchical models is precisely why we should not rely on such an attribute. What is fast in a context might not be in another. The only way to choose whether to simulate kinetics or assume equilibrium is to know and compare the real velocities. As you say " the ability to specify the speed of reactions withing a model is important". The "fast" attribute is exactly the opposite. It means "ignore the speed of reactions. Assume they are so fast they do not affect the system".
I agree. The fast flag is only meaningful for simulation if you also have kinetic information. If you have kinetic information, then the software can determine which reactions are fast and optimize simulation accordingly. We do this type of automated abstraction routinely and is described in detail in my textbook. This approach is much more efficient and accurate than to rely upon the modeler to know when it is appropriate to label a reaction as fast which as Nicolas correctly points out could change in a new context.
Chris
Last edit: Lucian Smith 2014-05-28
Nicolas, Chris: I do agree with you that the 'fast' attribute is definitely qualitative at best. If there are ways to extract this piece of information from the kinetic model equation, then the solver can take appropriate steps to optimize calculations. Thank you Chris for pointing out useful material.
As 3/5 editors have voted in favor of this change, I would change the status of this issue to 'accepted' except that I also have now added a section in SVN, so I'm just changing it to 'closed'. There's a new validation warning and this added text:
"Due to a number of factors, including the slow uptake of support for Reactions with a 'fast' flag of 'true', confusion about how exactly to implement said support, and the advent of new modeling techniques which allow more nuanced approaches to reactions that occur at different timescales (particularly for hierarchical and multi-scale modeling), the 'fast' flag is now considered deprecated for SBML Level 3. The 'fast' flag will be removed in future versions of SBML, and the speed of any Reaction will be solely determined by its KineticLaw. It is now considered best practice to only produce models with a 'fast' flag of 'false'. To achieve the same or similar effects as setting 'fast' to 'true', one should instead either set the KineticLaw to a value in the desired timescale, or achieve an instantaneous effect with an AssignmentRule or AlgebraicRule."