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.