Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#219 'fast' should be deprecated

closed
nobody
5
2014-05-28
2012-06-20
Michael Hucka
No

The 'fast' flag is something that many people would like to see removed. If we are going to do it, we should deprecate it for L3v2.

Discussion

  • Chris Myers
    Chris Myers
    2012-06-20

    I am accepting this issue as valid.

     
  • Chris Myers
    Chris Myers
    2012-06-20

    I would indeed like to see this one deprecated.

     
  • Lucian Smith
    Lucian Smith
    2012-06-20

    I am accepting this issue as valid.

     
  • Lucian Smith
    Lucian Smith
    2012-06-20

    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.

     
  • Sarah Keating
    Sarah Keating
    2012-06-20

    I agree with Lucian. I think this is one we can propose but need to look at the response to that.

     
  • Sarah Keating
    Sarah Keating
    2012-06-20

    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.

     
  • Michael Hucka
    Michael Hucka
    2012-06-20

    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.

     
  • Michael Hucka
    Michael Hucka
    2013-09-14

    • status: open --> pending
     
  • Lucian Smith
    Lucian Smith
    2013-09-16

    • status: pending --> open
     
  • Lucian Smith
    Lucian Smith
    2013-09-16

    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.

     
  • Michael Hucka
    Michael Hucka
    2014-01-20

    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.

     
  • Brett Olivier
    Brett Olivier
    2014-03-14

    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).

     
  • Michael Hucka
    Michael Hucka
    2014-04-04

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

     
  • Brett Olivier
    Brett Olivier
    2014-04-07

    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).

     
  • Frank Bergmann
    Frank Bergmann
    2014-04-07

    I accept this issue as valid and that it should be done.

     
  • Andy Somogyi
    Andy Somogyi
    2014-04-23

    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".

       
      • Chris Myers
        Chris Myers
        2014-04-29

        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.

     
  • Lucian Smith
    Lucian Smith
    2014-05-28

    • status: open --> closed
    • Group: Reported-Proposed --> Accept-conformance-implications
     
  • Lucian Smith
    Lucian Smith
    2014-05-28

    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."