3.2 OpenMI 2.0 architecture

3.2 OpenMI 2.0 architecture

The first full architecture for the OpenMI version 2 was completed at the meeting. We call this version the Trento version. There are still details that can and will be refined and potential pitfalls ahead. However, we think the Trento version will be close to fulfilling the needs for OpenMI version 2. The Trento version (the OpenMI.Standard interfaces) will remain unchanged until we have a full implementation of the SDK and the configuration editor and we have tested how it works for the simple test models. More details about the development plan are found below, in section 3.3. The Trento version is now committed to the trunk on source forge. Unit tests for the reduced version of the SDK are running.

The Trento version standard interfaces are shown in the figures below (clink on the images to enlarge).

Main concepts

As in version 1.4, exchange items play a significant role. A LinkableComponent has a list of input items and output items. Input items describe what can be accepted as input and output items describe what can be provided as output - same as for version 1.4. However, for version 2 exchange items also contain the actual values. Values are represented by a property of type IList. This list can contain any object as opposed to version 1.4 where the values always were either an array of doubles, or an array of vectors (i.e. value's x/y/z-components). For input items this list is of type Set, whereas the list in output items is of type Get. Allowing to set values is a major change as compared to version 1.4 and is introduced mainly to make it easier to work with component type 7 described in section 3.1. Values in output and input items are the actual values - no spatial, temporal or unit conversions. Getting values will not trigger any calculations.
The values in the list corresponds to elements in the elementSet and the times in the times property of the temporal information on the exchange item, gathered in the ITemporal interface. The order is first elements, then times. Getting values does not trigger any calculations.
If a component needs to get values not already available in the times property, or if the IsAvailable property of the output item is false, the component can invoke the Update method in the ILinkableComponent interface, which typically for models will make these progress with on time step.

In version 1.4 a GetValues call requested values to be represented at time, locations, and the unit defined by the accepting component. In version 2 this is achieved by requesting a decorator (IDecorator inherited from the IOutputItem). The decorator is obtained from the LinkableComponent by invoking the GetDecorator method. A decorator is an outputItem adapted to the inputItem which is passed as argument in the GetDecorator method. For decorators an argument property makes it possible to define further details about how the data is provided - e.g. interpolation methods.

Events

Version 1.4 had its own event system. For version 2 the standard .Net mechanism is used. A similar system is available in Java and will be used.

Time

We had a long discussion about changing the modified Julian time to the .Net time (e.g. DateTime). Especially, the definition of time span was difficult to agree upon. Should a time span be a start time and a period or should it be a start time and an end time. Anyway, since the definition of time does not influence the general concepts of version 2, it was decided for this iteration to keep the version 1.4 definition of time, and take this discussion again when we have a clear picture of how well the main concepts work.

Dispose

The Dispose method was removed from the LinkableComponent, since there is no need for both a finish and a dispose method.

Update

The Update method returns true if a component can continue to update or false if it is finished. Running a full simulation can be achieved by e.g. (while(c.Update())

Validate

Validate will be reviewed once we have implemented everything else, as if then it appears redundant we can quickly remove it, and if not, we will only know how it should now look haviing done the implementation work first.

Quantity and Quality

In version 1.4 values were defined by IQuantity. In version 2 this is extended to two ways of defining values. Either the well known quantity or a new type IQuality. The Quality interface will be used for categorized data. E.g. High, medium, low.

Persistent state

An optional interface IPersistentState is introduced in version 2. When components implement this interface, states can be saved and restored e.g. to and from disk.

Spatial reference

The ElementSet now has a string that defines the spatial reference. This string follows the OGC standard WKT (well know text) for spatial reference.

IArgument issues

Since the IArgument interface is used to define special behavior of the decorator a more sophisticated data type should be used. E.g. arguments can be used to select interpolation methods and and to set various parameters. We have investigated using the .Net type IDictionary. This will be further investigated and added to the standard in iteration 2 or 3.