Limitations of time representation in OpenMI

by W. de Winter (wim.dewinter@wur.nl)
Alterra, Wageningen UR

problem

At present, time is passed between the various models that cooperate within the OpenMI-framework stored in variables of a type, that represent an absolute position or span within a fixed-offset time. That is, every time can be related to a definite moment in the calendar of the planet Earth1.
So far, only one of the models that we have made OpenMI-compliant internally worked this way. Normally they internally use continuous time representations expressed in days or years (or a combination) from an arbitrary zero point. At the point of interfacing with the OpenMI-system, the time is encoded and decoded into dates that have no meaning within the models, in which the zero point only can be fixed by verbal agreement among the modelers ("let's say our models all start at January 1, 2000"). Leap years, and sometimes even years of 365-days, pose a problem. Moreover, I now have programmed the date conversion in a variety of programming languages, a chore repeated every time over again, though it is easy to see that another programmer might have done the same in a different way that could possibly lead to slightly different results, even unintentionally.

solution(s)

Therefore, my proposal would be that every model could continue to operate its own time base. This requires the components to reconcile possibly different time representations upon linking with another component. Date-time brokering then needs a mechanism similar to dimension and unit brokering between exchange items. Decorating the exchange items would offer a suitable mechanism.
Following this path a small step further could even greatly enhance the genericness of OpenMI: now the framework is time-oriented, that is, supportive of models that integrate variables dynamically through time. If "time" would be promoted to an abstract quantity, integrative systems over distance, density, or whatever, would be possible to develop too. Personally I do not feel the need for partial integration over multiple bases, but that might be worth another consideration. For our models time should be possible to express as:
• day number starting at 0
• year number starting at 0
• combination of year and day numbers
• second number starting at 0
• years (when applicable) of fixed length of 365 days
• years (when applicable) of fixed length of 360 days
1Although specific knowledge fails me in that field, I do have the feeling that the administrative date-time representation used in our operating systems would fall short of usability in astronomical applications