You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The previous optimizations in LLVMExecutableModel::getReactionRates() attempt to not re-calculate reaction rates when they are updated. However, they fail to account for assignmentRules of boundary variables and would not re-calculate when in fact some variables have changed (see #610). Additionally the bug was present in reaction rates with only time as a variable. Therefore these optimizations are turned off for now (see commented out section in getReactionRates()).
A potential future optimization that is more robust, is to keep track if each variable is constant, and only re-calculate if a reaction has non-constant variables. Additionally, since a reaction rate may depend on another reaction, a table may be needed to keep track which reaction rates have been deemed constant. This should only be done once before each simulation.
The text was updated successfully, but these errors were encountered:
The previous optimizations in LLVMExecutableModel::getReactionRates() attempt to not re-calculate reaction rates when they are updated. However, they fail to account for assignmentRules of boundary variables and would not re-calculate when in fact some variables have changed (see #610). Additionally the bug was present in reaction rates with only time as a variable. Therefore these optimizations are turned off for now (see commented out section in getReactionRates()).
A potential future optimization that is more robust, is to keep track if each variable is constant, and only re-calculate if a reaction has non-constant variables. Additionally, since a reaction rate may depend on another reaction, a table may be needed to keep track which reaction rates have been deemed constant. This should only be done once before each simulation.
The text was updated successfully, but these errors were encountered: