Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
scrollbar

Introduction

I have looked carefully at the current OpenMI development version 2 (the chained approach). I believe that it works, but somehow I also find it a bit too complicated. The whole idea of creating a chain of data operations may provide possibilities, but I have a hard time finding examples where this is really needed.

...

The way time is represented in the 1.4 standard has for a long time been bothering me. If you want to make a very simple component that does not care about time, you still have to implement TimeHorizon, GetEarliestInputTime, and the GetValues method will have a time argument. Examples of such non time components could be a GIS geo-references soil conductivity or soil type (when we get the quality data type included). It could also be a very simple component that provides a single value e.g. if you want to make a component for setting the roughness coefficient from outside via OpenMI.

I have changed the interfaces as shown on the figure below:

  • I made a new interface called IIdentifier. This has nothing to do with the time issues and I should probably not have made this change since it can confuse the issue. Anyway the IIdentifier is simply used to group the caption, ID and description that we have in some of our interfaces.
  • A new interface called ITemporal (could not at the moment come up with at better name (sad)) has been added. The idea is that if time is relevant for an exchange item (input or output) then such exchange items may implement this interface in addition to IInputExchangeItem or IOutputExchangeItem.
  • The TimeHorizon property is moved from the ILinkableComponet to the ITemporal interface, so a time horizon relates to at specific exchange item rather than the whole linkable component.
  • The property exchangeTime should be regarded exactly as

...

  • the elementSet in the exchangeItem. So, the elemetSet defines the locations for where data can be provided or accepted and likewise does the exchangeTime define when data is available or expected. This also means that the GetValues method in the IBridge interface does not need at time

...

  • argument. The bridge will convert data from being represented on the output elementset and the output exchange time to be presented on the input elementset at the input exchange time. (I do like symmetry (smile))
  • The AlwaysForwardInTime property is used to tell the other component that the exchange time will never be moved backwards thus allowing the delivering component to clear it's buffer.