BMIs and start time of 0.0

[dorchard]

I've been looking into the expected properties of models implementing the BMI interface and looking at what is described in the bmi-tester. I noticed that the tester expects the start time to be 0.0 (https://github.com/csdms/bmi-tester/blob/c4f5c994a13f6fd010ef5ba25fdcaffa893222be/src/bmi_tester/_tests/stage_1/time_test.py#L16-L21) I wondered if that's universal and if so, why is a start time needed? I can imagine that maybe some models might want to start somewhere in real history, perhaps at the beginning of a sensor record or at the start of the industrial revolution or 1970 or something like this. In which case the bmi-tester would not like it! I was wondering if anyone had any more info, thoughts, or knowledge they could share with me (a newbie) (maybe @mdpiper or @mcflugen?)

[hrajagers]

Hi Dominic,

Well spotted! The start time doesn't have to 0.0, but the BMI documentation for get_start_time states: "The start time in BMI is typically defined to be 0.0." In many of our own real world models, we use a reference date which is often equal to the simulation start time and hence the start time itself will often turn out to be equal to 0.0, but that will not always be the case. Even if the model returns 0.0 (or any other value) you will need the result of get_time_units to put that value in proper (historical) context with a reference date. There is more that one could say about time, such as which calendar is being used ... this is especially relevant for historical simulations (before October 1582; gregorian/julian), highly schematized cases (e.g. 360 days/year) or simulations of other planetary bodies (what's a year or even a day?).

[dorchard]

Thanks for this Bert. That makes a lot of sense. Now I wonder about this test in the bmi-tester then: do we really want to be enforcing 0.0 (even if that is the most common value)?

[mcflugen]

@dorchard To solve the problem of a reference date we had discussed a couple of options. One was to add a new BM function (I liked get_start_date because it sounded like "get star date" like Kirk might say). The other was to include the start date in the unit string obtained from get_time_units (e.g. "milliseconds since 1970-01-01T00:00:00").

I don't think we ever had a vote but the consensus seemed to be to go with the second option.

Either way, I think the bmi-tester should be updated to allow for non-zero start times.

[BSchilperoort]

the consensus seemed to be to go with the second option.

In eWaterCycle and the models connected to it, we rely on there being a reference date in the string. This is due to the input data and studies (nearly) always being tied to a specific point in time.

Having this split over separate functions would have been fine, and could be in interesting change for v3.0, but we needed it already.

[dorchard]

Thanks @mcflugen - I could make a PR re non-zero start time (it would basically just remove one line).

I do also wonder whether negative time steps are allowed? i.e., should it be possible to have models that start in the future and work backwards? At the moment it seems that this would probably be rejected by the bmi-tester due to the check that the 'end' is later than the 'start': https://github.com/csdms/bmi-tester/blob/master/src/bmi_tester/_tests/stage_1/time_test.py#L60-L67

[dorchard]

But note there is currently not check that the time step is positive.

[BSchilperoort]

But note there is currently not check that the time step is positive

I thought I have seen a discussion on this at some point in time, but I am not sure where.

I believe models can have negative time steps. This can be the case when you want to try to compute where something came from, such as atmospheric or oceanic tracers (gasses, particles, moisture).

[dorchard]

Following this interesting discussion I made a couple of PRs to the bmi-tester to generalise the current situtation:

• Allow non-zero start bmi-tester#45 simply removes the condition that the start needs to be 0.0
• Allow inverse (negative timestep) or instantaneous (0 timestep) models bmi-tester#49 accounts for the possibility of negative timesteps and also 0.0 timesteps (what I've called here 'instantaneous' models, in which case I think it makes sense for the start and end times to be the same).