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
Currently, whenever the rateOf is defined inside the delay tag for any of the SBML model then it does not take that delay into account and just provides the rateOf values as the time proceeds.
Issue found while simulating the model 1400, 1401 from SBML Test Suite.
Screenshot of simulation result for the model 1400:
Here, for the parameter with id P1, the assignment rule is defined to have a delay of 1 in calculating the rateOf while for the parameter with id P0; its only calculating rateOf with time. But the results show that P0 and P1 are just having the same values all the time, which means the delay is not considered here.
The text was updated successfully, but these errors were encountered:
This occurs as currently whenever the rateOf function is called it just gets the value from the changeRate array at that time, instead, there should be something like if I can make an ASTNodeValue object of that value from changeRate array as a REAL nodeType and just run compileDouble method by passing time and delay then everything should run fine, i.e., delays will be considered.
@draeger, @matthiaskoenig
What do you think about it? And if yes, can I convert a double value (a value from changeRate array) to an ASTNodeValue instance?
Currently, whenever the rateOf is defined inside the delay tag for any of the SBML model then it does not take that delay into account and just provides the rateOf values as the time proceeds.
Issue found while simulating the model 1400, 1401 from SBML Test Suite.
Screenshot of simulation result for the model 1400:
Here, for the parameter with id
P1
, the assignment rule is defined to have a delay of 1 in calculating the rateOf while for the parameter with idP0
; its only calculating rateOf with time. But the results show that P0 and P1 are just having the same values all the time, which means the delay is not considered here.The text was updated successfully, but these errors were encountered: