Clarify steady state #635
Clarify steady state #635
Conversation
doc/v2/documentation_data_format.rst
Outdated
| condition will be simulated until a steady state is reached. | ||
| condition will be simulated until a steady state is reached. The system is | ||
| considered to be at steady state once the time derivative of all | ||
| differential entities is almost zero, even if there are discontinuities in |
There was a problem hiding this comment.
Say that this is up to the individual tools to implement what „almost zero“ is?
An attempt to clarify what we consider steady state in the context of PEtab.
| condition will be simulated until a steady state is reached. The system is | ||
| considered to be at steady state once the time derivative of all | ||
| differential entities is almost zero (where "almost zero" is to be defined by | ||
| the simulator or user), even if there are discontinuities in | ||
| the model (e.g., due to events) that may change the model state | ||
| at a later time point. |
There was a problem hiding this comment.
| condition will be simulated until a steady state is reached. The system is | |
| considered to be at steady state once the time derivative of all | |
| differential entities is almost zero (where "almost zero" is to be defined by | |
| the simulator or user), even if there are discontinuities in | |
| the model (e.g., due to events) that may change the model state | |
| at a later time point. | |
| condition will be simulated until a steady state is reached. In the most | |
| general case in PEtab, the mathematical model is an initial value problem | |
| with a system of explicit differential-algebraic equations. | |
| A steady-state occurs when the differential state variables become | |
| constant then stay constant, given the algebraic constraints and initial | |
| condition. In the absence of analytical steady states, numerically | |
| determining whether a steady state has been reached is difficult and | |
| is both method- and problem-specific; hence, this is left to the simulator | |
| and user. |
I don't think it's enough to write "once the time derivative [...] is almost zero", since this might contradict the user's understanding of what steady state means for their particular model.
There was a problem hiding this comment.
Hm, my main intention was to clarify how events interact with steady states. It feels like this change makes it as unclear as it was before.
when the differential state variables become
constant then stay constant, given the algebraic constraints and initial
condition
Does that mean that we only reach a steady state once we can be sure that no event would ever occur that could change the state? Or does it mean that events should be ignored? If so, it contradicts with that we want events to handled during steady state simulations.
There was a problem hiding this comment.
Yes, there can be no later change in the state, due to an event or otherwise (e.g. extremely slow dynamics). The simulator/user needs to decide for themselves whether they are sufficiently satisfied that they have found the steady state. If someone comes along later and finds that the state actually changes at a later time point, then the first user/simulator is incorrect. We should not write a definition that claims the first user is actually correct?
There was a problem hiding this comment.
I don't see a contradiction since we are still requiring that the simulator/user decides whether to ignore potential future events or not. But guiding this decision is out-of-scope of PEtab IMO
There was a problem hiding this comment.
I don't think we can do that and at the same time say we promote reproducible simulations. If we really want that I would prefer to somehow impose a minimum simulation time before a steady state can be reached.
We still have to test this in some meaningful way in the testsuite.
There was a problem hiding this comment.
After further discussion with @dilpath: the steady state definition should probably also include assignment rule targets, and for t=inf measurements, observables.
There was a problem hiding this comment.
Thinking about the whole issue again, I agree with Dilan's initial point. We should not prevent tools from doing the right thing. Formally, the steady-state condition would be d x / d t = 0 and no time-dependent events for any t > t c u r , which we should state here. If a tool ignores the latter condition, there is a chance it won't find the right steady state and we probably shouldn't justify that.
I think we should avoid attempting to define what the right steady-state is.
Let's say we have a model where x follows logistic growth and there is an event with trigger alpha*t-x that changes the carrying capacity. This event clearly changes steadystate, but it only triggers for some specific values for growth rate/alpha. In this simple example, you might get lucky and precompute whether an event is going to trigger or not, but that essentially will require computing the explicit solution which will not be available in general.
Asking tools to figure out whether there is going to be another event is asking something impossible, which we should not do.
There was a problem hiding this comment.
Overall, if we want reproducibillity, assuming we define steady-state as dx/d t=0, then saying the first point that fulfill dx/dt=0 for t>tmin should be sufficient? Maybe then in the spec, we can highlight that this might imply triggering of events during steady-state simulations (and if the user does not want events to trigger during steady-state simulations, there are always ways to code events such they cannot be triggered, that is for example how Brannmark benchmark model handles it currently)?
There was a problem hiding this comment.
Asking tools to figure out whether there is going to be another event is asking something impossible, which we should not do.
I see that point. However, I wouldn't want to say that some tool that is better at doing that should stop doing that.
How about we don't change the definition of a steady state, but just say that tools may stop at dx/dt=0, and that it's on the modeler to avoid any situations where this could cause problems?
It may not be perfect in terms of reproducibility, but that problem starts long before (unspecified integration tolerances, steady state tolerances, ...).
There was a problem hiding this comment.
Asking tools to figure out whether there is going to be another event is asking something impossible, which we should not do.
I see that point. However, I wouldn't want to say that some tool that is better at doing that should stop doing that.
How about we don't change the definition of a steady state, but just say that tools may stop at dx/dt=0, and that it's on the modeler to avoid any situations where this could cause problems? It may not be perfect in terms of reproducibility, but that problem starts long before (unspecified integration tolerances, steady state tolerances, ...).
fine with me.
| measurements (the same definition of steady state as in the | ||
| :ref:`v2_experiments_table` applies here). |
There was a problem hiding this comment.
| measurements (the same definition of steady state as in the | |
| :ref:`v2_experiments_table` applies here). | |
| measurements (the same definition of steady state as in the | |
| :ref:`v2_experiments_table` applies here, with the additional | |
| sanity check that the steady state occurs during the final | |
| experiment period). |
An attempt to clarify what we consider steady state in the context of PEtab.