Change event language from 't=0' to 't_i'.

[luciansmith]

It turns out that people do simulations where 'time' doesn't start at zero: they might have an SBML model saved where time=2, and want to simulate from time=2 to time=10 or the like.

In this case, the events in the model would semantically be described mostly as they are now, with a slightly modification: we would need to refer to 'the initial time' as 't0', instead of 'when t=0'. (Simulations are also performed with a negative start time, too.)

It might also be worth a short description of what happens when the csymbol 'time' is used in an event trigger (or generally in MathML), but the simulation doesn't start at time=0: if, say, an event trigger is 'time>=3', with an 'initialValue' of 'false', it will trigger after three time units if a simulation is given that starts at zero, after one time unit if given a time start of 2, and immediately at the start of the simulation if given at time start of 3 or greater.

Simulators regularly have non-zero time starts: roadrunner has had a 'start' argument to its 'simulate' function since forever, as have other simulators (as far as I know), and it's been formalized in SED-ML in the 'initialTime' attribute of the 'UniformTimeCourse' class.

None of this would make any difference to the output of an SBML simulation except for the labeling of the 'time' axis, were it not for the inclusion of the 'time' csymbol: that's where potentially odd situations can occur with initial times other than zero.

EDIT: I eventually decided that $t_0$ was not as clear as $t_i$, so I'm using that language in my current proposed text changes.

[luciansmith]

Oh, another thought: we should probably update the language of delays to talk about t0 instead of time=0, too. Basically, there are a lot of technical rules about what was happening to variables before 'the start': we need to indicate that this means 'the state of the model captured in this file', instead of 'the state of the model at time=0'. Imagine a simulation running from t=-2 to t=2: all the reactions and rate rules should apply to the whole simulation: they shouldn't suddenly kick in at t=0, and only initial assignments and rate rules apply in the first half.

[draeger]

While I exactly had that thinking, say 16 years ago when trying to model my first time-course experiment, which started with a delayed simulation time, now I think such a change can cause many problems. SBML is now to be considered very stable. A wealthy software infrastructure has grown around it. It may be true that many simulators already support start times other than t = 0 but others might break. The traditional notion that models need to be encoded in such a way that they start at time zero is often required to adjust the models to fit that requirement. Elevating it might break a lot. It can be beneficial in some cases, but with the complicated event triggering mechanism, variable event priorities, etc., such a change can have many consequences, some of which are not directly apparent. As a result, such a change might also cause a lot of costs for additional implementation time. It is probably much cheaper to adjust the models to start at t = 0.

[luciansmith]

I am certainly sympathetic to that view, but with SED-ML already providing an 'initialTime' attribute (and having done so since its l1v1 in 2011), I feel like it's incumbent on SBML to describe what happens in that situation.

Alternatively, we could request that SED-ML validation marks non-zero 'initialTime' attributes as invalid when referencing an SBML model, or at least for SBML models with csymbol 'time' in them? I dunno.

I created this issue because I was updating roadrunner's implementation of non-zero start times, and realized that the assumptions I was making about what that meant for SBML models was not written down anywhere.

[draeger]

Maybe we need a list of things that will be affected by such a change. In particular, we need an indication how much more complex event handling would become and what the consequences to delayed differential equations this would have. It might also interfere with initial assignments, variable stoichiometries, and potentially other things.

[draeger]

Please don't get me wrong. Allowing arbitrary intitial times certainly makes a modeler's life more convenient. Once we have an overview of that impact, we can better assess if the implementation work is doable and justified for all users of SBML.

[luciansmith]

The impact to any simulator that does not support non-zero initial times would be nil. The models wouldn't change, and their interpretation would be the same.

(I suppose there might be an uptick in SED-ML/SBML simulations that rely on special behavior, which would mean that they'd see a drop-off in the percentage of models they support? I dunno.)

The impact to simulators that do support non-zero initial times would be to clarify what they are supposed to be doing. I don't know if tests for this belong in the SBML Test Suite, but they definitely should go in the SED-ML test suite, once it exists.

This means that the impact to roadrunner and other simulators might be that there is a collective decision that they're doing it wrong, and would then need to implement a change. For example, it's possible that there's a simulator out there that, based on the current SBML specification and asked to simulate starting at -2, simulates to time=0 with only assignment rules, and then turns on reactions and rate rules at t0. Maybe they do things this way so that they can support delay differential equations? Even this seems like a method they use to perform a 'real' simulation that starts at time=0, however, and not a simulation where they're supporting a SED-ML initialTime of -2.

Other than that, simulators that don't currently support non-zero start times could implement support for it for models that don't have the csymbol 'time' by the simple expedient of relabeling the 'time' axis. Everything else would be the same.

For models that do use the csymbol 'time', there are a few things that need to be tracked:

• Some MathML needs to be interpreted as part of the initialization of the model. This would need to be adjusted to use the 'initialTime' value instead of 0.0
• Events that can fire at t0 that have 'time' in their triggers might need to use the new initialTime instead of 0 (I ran into this with roadrunner)
• Events that do fire at t0 and have a delay need to calculate the time at which they fire based on the initialTime instead of 0 (another roadrunner issue).
• Delay differential equations that have 'time' in them might need special casing? I'm not familiar with this as much, but I kind of think that any delay differential equation with the csymbol 'time' would have already had to be handled, regardless of what value 'time' might have.

There may be other issues I haven't though of, but initialization, delays, event delays from t0, and event t0 triggers are the main ones, I believe.

[draeger]

Thanks, @luciansmith, for this detailed analysis! I think we'd certainly need test cases for start times other than zero that include the scenarios in your list.
Which SBML version would change, Level 3 Version 3?
I'd suggest using the symbols $t_0$ and $t_\tau$ for simulation start and end time then.

[luciansmith]

We actually discussed this issue at the SBML Editor's meeting! At that meeting, we decided two things:

1. We should have a new release of SBML L3v2 that clarifies what to do with non-zero start times. (It was argued that the current spec is ambiguous on the issue.) We may want a new release of L2v5 as well?

2. We should add a new 'initialTime' attribute to 'model', so that people can store what the time of a model is supposed to be. This would be part of a new L3v3.

I was personally initially skeptical of #2, but then mostly convinced by the end of the meeting. I have subsequently wavered again, and am once more not quite convinced, but I'm still fine being overruled by a majority. (Also, if there were other things needed for l3v3, that would make me happier than just having this one single thing.) I do think we should run this by sbml-discuss, though.

More to the point, I have now written new replacement text for 3.4.7 'Simulation time'. I also threw in a bit about simulating backwards in time. The first paragraph is unchanged, but the rest is replaced by this (in TeX):

---

In a simulation experiment involving an SBML model, time is controlled externally by the experiment, and not by the model itself. An experiment may involve calculating the steady state of the SBML model (in which case 'time' nominally has no meaning, or is 'infinity'), or it may involve simulating the model for arbitrary time spans. Most commonly, those spans start from zero, so a typical simulation might go from 0 to 10, or 0 to 200. However, other simulations might be set up with a negative start time, with a timecourse of -5 to 100, for example, or with a start time greater than zero, i.e. 100 to 200. In all of these simulations, it must be assumed that the SBML model is set up such that the initial time of the simulation (whether 0, -5, or 100 in our examples) is the time at which the initial assignments are applied, i.e. $t_i$, and that the \token{initialValue} of the \Trigger child of an \Event applies at that time. Care should be taken that a simulation experiment's initial time corresponds with this initial state of the model.

It is not recommended to simulate an SBML model backwards in time, i.e. with an end time $t_f \leq t_i$. In some cases, the mathematics may be tractable, but too many concepts in SBML (events, delays, initial states) rely on the forward progress of time to reliably assure reproducibility across backwards simulations. Depending on the desired outcome, it may be possible to create a new nigh-identical SBML model with negative kinetic laws and rate laws, that may satisfy the modeling requirements of the desired simulation experiment instead.

---

Any comments/suggested edits?

[matthiaskoenig]

Hi all, the text is great. Smaller comment about steady state simulations, i.e., " A simulator may choose to calculate the steady state of the SBML model (in which case 'time' nominally has no meaning, or is 'infinity')". This is not complete clear. It reads as the model never has an initial time (because time has no meaning). but the initial time is crucial to apply the initial assignments, initial conditions and delays. I.e. one can run a steady state simulation and the time at the beginning still has the normal meaning and all the rules for calculating the initial values and simulations apply, even if later on the time has probably no meaning. E.g. calculating a steady state via presimulation in an ODE model. This should be a bit clearer. Perhaps adding a sentence that explicitly states what the values of the csymbol time are. I.e. the model variable csymbol "time" has the value according to the start time of the simulation, i.e. the initial value of the model time is -5 if a simulation runs from -5 to 100. I think being as explicit as possible here is good. Best Matthias

…

On Tue, Apr 16, 2024 at 2:01 AM Lucian Smith ***@***.***> wrote: We actually discussed this issue at the SBML Editor's meeting! At that meeting, we decided two things: 1. We should have a new release of SBML L3v2 that clarifies what to do with non-zero start times. (It was argued that the current spec is ambiguous on the issue.) We may want a new release of L2v5 as well? 2. We should add a new 'initialTime' attribute to 'model', so that people can store what the time of a model is supposed to be. This would be part of a new L3v3. I was personally initially skeptical of #2 <#2>, but then mostly convinced by the end of the meeting. I have subsequently wavered again, and am once more not quite convinced, but I'm still fine being overruled by a majority. (Also, if there were other things needed for l3v3, that would make me happier than just having this one single thing.) I do think we should run this by sbml-discuss, though. More to the point, I have now written new replacement text for 3.4.7 'Simulation time'. I also threw in a bit about simulating backwards in time. The first paragraph is unchanged, but the rest is replaced by this (in TeX): ------------------------------ In SBML, time is controlled externally to the model itself. A simulator may choose to calculate the steady state of the SBML model (in which case 'time' nominally has no meaning, or is 'infinity'), or it may choose to simulate the model for arbitrary time spans. Most commonly, those spans start from zero, so a typical simulation might go from 0 to 10, or 0 to 200. However, other simulations might be set up with a negative start time, with a timecourse of -5 to 100, for example, or with a start time greater than zero, i.e. 100 to 200. In all of these simulations, it must be assumed that the SBML model is set up such that the initial time of the simulation (whether 0, -5, or 100 in our examples) is the time at which the initial assignments are applied, i.e. $t_i$, and that the \token{initialValue} of the \Trigger child of an \Event applies at that time. Care should be taken that a simulation experiment's initial time corresponds with this initial state of the model. It is not recommended to simulate an SBML model backwards in time, i.e. with an end time $t_f \leq t_i$. In some cases, the mathematics may be tractable, but too many concepts in SBML (events, delays, initial states) rely on the forward progress of time to reliably assure reproducibility across backwards simulations. Depending on the desired outcome, it may be possible to create a new nigh-identical SBML model with negative kinetic laws and rate laws, that may satisfy the modeling requirements of the desired simulation experiment instead. ------------------------------ Any comments/suggested edits? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG33OVMM36BQFIBIZY3YK3Y5RS47AVCNFSM5EWMK6RKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVHAYDANRXGQ4Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[luciansmith]

Good point! Here's some revised text:

---

In a simulation experiment involving an SBML model, time is controlled externally by the experiment, and not by the model itself. An experiment involving calculating the steady state of the SBML model, for example, may involve calculating the initial state of the model, then using that to directly calculate the steady state, where 'time' nominally has no meaning, or is 'infinity'.