SedML defines UniformTimeCourse `outputStartTime` and `outputEndTime` as *relative* to `initalTime`, but this is not followed in practice

[CodeByDrescher]

In practice and current community implementation, UTC simulations may define an initialTime that represents when the simulator should initialize the start of simulation to be, and is useful for the sake of defining outputStartTime and outputEndTime in simulation output.

In practice across many simulators at the moment, this is done by defining an absolute initial time, and then defining output start and end time to fall after the initial time, where the corresponding output would be desired. For example, if we want to initalize a simulation to start at 5 seconds, simulate for one second, then collect data for 4 seconds, most simulators expect the following values to be set (and many sedml are defined this way accordingly):

• initalTime: 5
• outputStartTime: 6
• outputEndTime: 10

However, the SedML L1V5 defines both outputStartTime and outputEndTime as being relative to initialTime, not with respect to t=0. Thus, if the specification was "properly" implemented, the following would be the correct values:

• initalTime: 5
• outputStartTime: 1
• outputEndTime: 5

[luciansmith]

Checking with @agarny: do you also interpret this the way others do, or do you follow the spec?

[agarny]

Legacy OpenCOR and the current version of libOpenCOR ignores initialTime and only works with outputStartTime and outputEndTime, meaning that initialTime = outputStartTime and is usually equal to zero. Now, if libOpenCOR ever makes use of initialTime then it will follow the spec, obviously. 🙂

[matthiaskoenig]

Which tools do this incorrectly?
This seems like a tool implementation issue, not a specification issue. Or is there some clarification needed in the spec?

[luciansmith]

Every tool does this the same: tellurium, Copasi, and all of the SED-ML wrappers in biosimulations interpret the outputStartTime as an absolute value of 'what time point to start collecting values' and not 'what distance from the start time to start collecting values'.

I personally think the paragraph in question is ambiguous. Here it is in full:

"Sometimes a researcher is not interested in simulation results at the start of the simulation, i.e., the initial
time. The UniformTimeCourse class uses the attribute outputStartTime of type double, and describes
the time (relative to the intialTime) that output is to be collected. To be valid the outputStartTime
cannot be before initialTime."

So on one hand, it says "relative", but on the other, it says it "cannot be before initialTime", which would make no sense if it was relative: in that case you'd say it "cannot be negative". The only sense in which "cannot be before" makes sense is if you have something like:

initialTime="10"  outputStartTime="5"

So in my opinion, we just need to reword the spec to remove the word 'relative'. That word was introduced in L1v3. Here's what L1v2 says:

"Sometimes a researcher is not interested in simulation results at the start of the simulation (i.e. the initial
time). To accommodate this in SED-ML the uniformTimeCourse class uses the attribute outputStartTime
of type double. To be valid the outputStartTime cannot be before initialTime."

It seems to me that it was reworded by someone to say 'relative' in an attempt to clarify what people were doing, and instead confused the issue.

...and in fact, looking at git blame, that person was me! I can't precisely recall what I was thinking in September of 2017, but my commit message was "Small updates to clarify initial, start, and end times.", which means that I wasn't trying to change anything, just describe what we were doing. Since nothing changed, nobody noticed that it was badly worded until Logan finally came across it.

[matthiaskoenig]

Perfect. Thanks for looking into this.
I also had the feeling that it is pretty clear what was meant by the attributes, it was just not formulated clearly.

I suggest to just fix the formulation (i.e. remove relative)