Add 'timeInterval' attribute to UniformTimeCourse

[luciansmith]

From Alan Garny: Add a new 'timeInterval' attribute to UniformTimeCourse that would optionally replace (for the user) the 'numberOfSteps' attribute.

These two uniform time course elements would have the same meaning:

<uniformTimeCourse id="simulation1" initialTime="0" outputStartTime="0" outputEndTime="380" numberOfSteps="380">

<uniformTimeCourse id="simulation1" initialTime="0" outputStartTime="0" outputEndTime="380" timeInterval="1">

Any discrepancy between the interval and the start/end points is made up in the final interval. Hence:

<uniformTimeCourse id="simulation1" initialTime="0" outputStartTime="0" outputEndTime="1" timeInterval="0.3">

would result in a plot with the time series:

0, 0.3, 0.6, 0.9, 1.0

[luciansmith]

As discussed at HARMONY 2025, the editors present all voted to adopt this change (@hsauro, @matthiaskoenig, @nickerso, @eagmon). @WeiweiAi: if you have an opinion, it would be welcome!

[luciansmith]

As I was writing this up, I realized something: a regular grid can also be defined with 'timeInterval' and 'numberOfSteps', without an 'outputEndTime' attribute. Should this be also allowed? There would be three options:

1. start, end, numberOfSteps
2. start, end, timeInterval
3. start, timeInterval, numberOfSteps

[agarny]

Hmm... indeed! So, yes, I think it would only be right to allow it.

[nickerso]

actually 4 options, right? end, timeInterval, numberOfSteps also defines a regular grid.

[agarny]

actually 4 options, right? end, timeInterval, numberOfSteps also defines a regular grid.

In that case, I would then expect timeInterval to be negative, no? Not sure that's something we want?

[luciansmith]

I suppose you could indeed back-calculate the start time from the end, interval, points. I am going to propose that we don't explicitly support that, though ;-)

[nickerso]

end = start + numberOfSteps * timeInterval is equivalent to start = end - numberOfSteps * timeInterval - so why generalise and then enforce arbitrary restrictions?

I'd actually suggest not generalising (to avoid this kind of discussion) and restricting to only option 1 or 2.

[luciansmith]

Here's what I have so far:

[agarny]

• One too many commas in `... would produce time points at 0, 3, 6, 9,, and 10."
• Do we really need the tolerance paragraph? As you said in your last paragraph, I would indeed expect people to use outputStartTime + n * timeInterval. To my knowledge, that's the most accurate numerical way to do this.
• Regarding numberOfSteps and outputEndTime, either drop it or indeed have it for both cases (as mentioned by @nickerso in Add 'timeInterval' attribute to UniformTimeCourse #223 (comment)).

[luciansmith]

We really need the tolerance paragraph. Otherwise different interpreters will produce different outputs.

[luciansmith]

The only generalization is that we allow exactly two of the three attributes interval, steps, and end.

Technically you could do all three if you dropped start, but literally nobody does this. But people do use the other three combinations. (Though if someone does, I'd be happy to put it in?)

If I was going to drop something, I'd drop the start/interval/end, just because it requires so many caveats. But that was the one you wanted in the first place!

(Alternatively, we could require that end = start + n*interval, but you also wanted Not That in the initial ask, so presumably people actually do want [0, 3, 6, 9, 10]-style time points.)