See also: OATC Wiki Home

Date: June 25, 2010
Time: 10:00 - 11:30 am
Venue: Skype Conference Call
Topic: Extendable version of OpenMI 2 (continued)

Table of contents

Participants

Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don, Deltares (gennadii.donchyts@deltares.nl)
Jesper Grooss, DHI (jgr@dhigroup.com)

1. Progress towards OpenMI 2 Beta release

1.1. Source code updates

1.2. Documentation updates

2. Ongoing discussion topics

2.1. Note about OpenMI 2 compliancy

(Peter) To be decided: which compliancy is more appropriate?

(Rob) I prefer the second option. However besides stating when something is compliant, I think we should also make it more clear what this means in practice for the average modeler / user.

2.1.1. Slightly changed from 1.4 compliancy

The IBaseLinkableComponent is the key interface in the OpenMI standard version 2. Any OpenMI compliant component must implement IBaseLinkableComponent.
OpenMI-compliance definition:

1. An OpenMI-compliant component must implement the IBaseLinkableComponent interface according to specifications provided as comments in the OpenMI.Standard2 interface source code. *
2. An OpenMI-compliant component must, when compiled, reference the OpenMI.Standard2.dll, which is released and compiled by the OpenMI Association.
3. An OpenMI-compliant component must be associated with an XML file, which complies to (can be validated with) the BaseLinkableComponent.xsd schema (same information a 4. - leave it out?)
4. An OpenMI-compliant component must be associated with an XML file, which complies to (can be validated with) the OpenMICompliancyInfo.xsd schema. This file must be submitted to the OpenMI Association.
5. The OpenMI Association provides two additional interfaces that OpenMI-compliant components may or may not implement: the IManageState interface and the IByteStateConverter interface. However, if these interfaces are implemented, each method and property must be implemented according to the comments given in the OpenMI.Standard2 interface source code.
6. The OpenMI Association's downloadable standard zip file provides the only recognized version of source files, XML schemas and assembly files.

* at 1. The OpenMI Association provides extensions to the standard with more specific interfaces, e.g. for time and space dependent components. Although these extensions are part of the standard they are formally not required for compliancy. But the OpenMI Association recommends to implement the appropriate extension for easier data exchange with other OpenMI compliant components.
This means a change in the implementation of the classical time and space dependent component, which had in 1.x  just to implement the basic ILinkableComponent. For OpenMI 2 compliancy this component would have to implement the basic and the time and space specific extension interfaces.

2.1.2. Two level compliancy

The compliancy with the OpenMI 2 standard is split into two levels. The OpenMI compliancy on the first level refers to basic interfaces whereas the OpenMI extension-compliancy includes additional interfaces, e.g. for time and space dependent components.

The IBaseLinkableComponent is the key interface in the OpenMI standard version 2.

OpenMI-compliance definition:

1. An OpenMI-compliant component must implement the IBaseLinkableComponent interface according to the specifications provided as comments in the OpenMI.Standard2 interface source code.
2. An OpenMI extension-compliant component must implement the IBaseLinkableComponent interface and at least one of the extension interfaces according to the specifications provided as comments in the OpenMI.Standard2 interface source code. *
3. An OpenMI-compliant as well as an OpenMI extension-compliant component must, when compiled, reference the OpenMI.Standard2.dll, which is released and compiled by the OpenMI Association.
4. An OpenMI-compliant as well as an OpenMI extension-compliant component must be associated with an XML file, which complies to (can be validated with) the OpenMICompliancyInfo.xsd schema. This file must be submitted to the OpenMI Association.
5. The OpenMI Association provides two additional interfaces that OpenMI-compliant components may or may not implement: the IManageState interface and the IByteStateConverter interface. However, if these interfaces are implemented, each method and property must be implemented according to the comments given in the OpenMI.Standard2 interface source code.
6. The OpenMI Association's downloadable standard zip file provides the only recognized version of source files, XML schemas and assembly files.

* at 2.: This leads to a main difference between OpenMI 1.x and OpenMI 2. In order to become 1.x compliant the classical time and space dependent component just had to implement the basic ILinkableComponent. This component would have to implement the basic and the time and space specific extension interfaces for becoming OpenMI 2 compliant.

2.1.3. What do these compliancy definitions mean for the user?

Linking OpenMI 2 compliant components has become much more flexible than it used to be with OpenMI 1.x. Components with different concepts can exchange their data. A component with a date and time definition can for example provide a consumer component, defining its simulation time by an index, with data. The provider should contain an AdaptedOutput converter using both definitions and thus being able to convert the time to the index value. This requires more user knowledge about both time definitions enabling him to check the plausibility of the results. This price is paid for the higher flexibility, not due to the OpenMI but to the complexity of the task.
If both LinkableComponents implement the same OpenMI extension interface, their provider consumer relationship will remain as straight forward as with OpenMI 1.x. The conversions in AdaptedOutput are easier to use and to check.
One should remember that compliancy does not mean a total plug and play connection. The OpenMI provides the community with an interface standard and tools for convenient data exchange. But the user has the responsibility for selecting the appropriate quantities and the locations where they are defined, since OpenMI 2 has remained a slim standard. It offers the approved methods for efficient data exchange and additional extensions for a wider spectrum of components.

2.2. How to define the extension interfaces

(Rob) Still considering the two approaches: using a hierarchy (i.e. ITimeSpaceLinkableComponent extends IBaseLinkableComponent, MyComponent implements ITimeSpaceLinkableComponent) or composition (i.e. MyComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension). Should consider the effect when adding a linkable component interface for the loop method(s) or for the FRAMES dictionary support. Also see how OGC spatial element sets can be added as an extension and how this effects the interfaces.

Alternative 1 (interface hierarchy):

IBaseLinkableComponent { base methods };
ITimeSpaceLinkableComponent extends IBaseLinkableComponent { time-space methods };
IParallelTimeSpaceLinkableComponent extends ITimeSpaceLinkableComponent { loop methods };

IDictionaryLinkableComponent extends IBaseLinkableComponent { dictionary methods };
IParallelDictionaryLinkableComponent extends IDictionaryLinkableComponent { loop methods };

MyParallelTimeSpaceComponent implements IParallelTimeSpaceLinkableComponent {};
MyParallelDictionaryComponent implements IParallelDictionaryLinkableComponent {};

Alternative 2 (uncoupled interfaces):

ILinkableComponent { base methods };
ILinkableComponentTimeSpaceExtension { time-space methods };
ILinkableComponentParallelExtension { loop methods };
ILinkableComponentDictionaryExtension { dictionary methods };

MyParallelTimeSpaceComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension, ILinkableComponentParallelExtension {};
MyParallelDictionaryComponent implements ILinkableComponent, ILinkableComponentDictionaryExtension, ILinkableComponentParallelExtension {};

3. New discussion topics

3.1. How to package and distribute extensions

(Rob) When an extension is approved by OATC will it be included into the Standard library (dll or jar), or will each extension be distributed in its own library?