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)
Jesper Grooss, DHI (jgr@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)

Apologies:
Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)

1. Progress towards OpenMI 2 Beta release

1.1. Source code update status - C#

Source code comments in the standard.

Stef has read through and updated all the source code comments in the standard

Spatial classes in the SDK

Jesper has added a number of spatial classes to the spatial part of the SDK. Currently has been added the interfaces and classes:

IMultiPoint            | MultiPoint
ILineString            | LineString
ISpatial2DGrid         | Spatial2DCurveLinearGrid
ISpatial2DRegularGrid  | Spatial2DRegularGrid
ISpatialMesh           | SpatialMesh

All interfaces extend from the new ISpatialDefinition.

Together with each interface there is a wrapper class that presents the class as an IElementSet.

These can serve two purposes:

Make clear how use IElementSet to work with OGC formats - the review issue. This is exactly what the wrapper classes do.
Suggestions to/draft of a spatial extension to the standard.

Currently only these interfaces/classes have been added, since that was the most obvious ones. But more of the OGC feature classes should probably also be included.

1.2. Source code update status - Java

(Rob) No updates have been made since about two weeks, due to lack of time. Current source code is out-of-sync with C# version and needs to be updated. Looking for a volunteer to do this since I will be attending the iEMSs in Ottawa and not have time until mid July.

todo: Stef will take care about the Java documentation before the iEMSs conference on the 5th July.

1.3. Documentation updates

(Stef) Maybe keep the documentation more or less as is, and only clearly describe the 'base' - 'timespace' leveling.

1.4. Observations during working with the new standard

(Jesper) I am currently working on porting the DHI OpenMI components to 2.0. The following observations was made:

1) Processor architecture (MSIL/x86/AMD64/IA64) in OMI file and configuration editor
The current configuration editor is build with the AnyCPU (MSIL) set. This means on a 64 bit machine it will by default run as 64 bit, and on a 32 bit machine it will run as 32 bit.

Some models does work only in 64 bit or 32 bit mode. If the configuration editor tries to load a linkable component of another processor architecture, it fails with an ugly exception (either "can not find file" - it is there, but it is the wrong architecture, or "bad image format" - some underlying unmanaged dll is using the wrong architecture).

If the processor architecture is included in the OMI file, it will make component providers aware of the issue and address it, and it will let the configuration editor give a nice error message when loading a model with the wrong architecture.

Probably also the configuration editor should be build in a 32 bit and 64 bit version.

todo:

- An attribute, something like "Processor_Architecture" should be added to XML file ( Windows, Linux, 32bit, 64bit, ...)

- A pure 32bit and a pure 64bit version will be generated.

to discuss in the future:

- A manifest of file dependancies should be added.

2) An input item can only take one output (one provider).

For some inputs it makes perfectly sense that there can only be one provider, as e.g. a water level input. For other inputs it is ok to have more than one output, as e.g. a discharge input into a 2D model - if two or more outputs are to discharge, their contributions are added.

Consider a simple example with one ground water model and two river models each wanting to discharge (leakage) into the ground water model. This is not really supported (and was either not in 1.4).

A work-around is to make an intermediate component with one output and two inputs, that merges the two outputs to one output. This intermediate component has to "transfer" the element set from the original input to its own two inputs, which it can only do after configuration. Hence the two outputs may not be able to connect to the intermediate component, since the element sets on that side of the intermediate component is not defined and does not match.

Alternatively, an input could be updated to handle a number of outputs, and not only one.

Also in this context, the IAdaptedInput would come in handy.

- maybe later

1) ITimeSpaceValueSet.PreferedOrderIsElements property
(Jesper) This does complicate quite some things. It is not fully supported in the SDK. As we have now moved the property into a "TimeSpace" extension, I would vote for removing it again, assuming Values2D is ordered with time first.

This type of component related flag, indicating the order of time and elements, is not needed.

2. Ongoing discussion topics

2.1. Note about OpenMI 2 compliancy

2.1.1. Formal compliancy definition

The flexibility of OpenMI version 2 can be recognized in the compliancy definition. The compliancy refers to a set of basic interfaces as well as to optional extension interfaces, e.g. for time and space dependent components. The IBaseLinkableComponent is the key interface.

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 compliant component can also comply to one ore more extensions, by implementing the IBaseLinkableComponent interface and the extension interfaces which it wishes to comply to, according to the specifications provided as comments in the OpenMI.Standard2 source code.
3. An OpenMI-compliant component, optionally with extensions, ...
Alternative. 3a ... must, when compiled, reference the OpenMI.Standard2*.dlls/jars, which are released and compiled by the OpenMI Association.
Alternative. 3b ... must reference the OpenMI.Standard2 namespace, which is released by the OpenMI Association.
4. An OpenMI-compliant component must be associated with an XML file, the so called
OMI file, which complies to (can be validated with) the LinkableComponent.xsd schema.
5. 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.
6. 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.
7. 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 ILinkableComponent interface. This component now would have to implement the basic interfaces and the time and space specific extension for becoming OpenMI 2 compliant.

2.1.2. What does the compliancy definition mean for the user?

Potential users of an OpenMI compliant component should understand the following point

"Being compliant is no guarantee that it can be usefully linked to another OpenMI compliant component. It is a necessary but not sufficient condition."

To be usable the user must also consider the following factors

1. Do both components target the same system infrastructure. Currently Java and .Net components cannot be mixed within the same composition.

2. Do both components implement the same OpenMI version. Development is under way to allow 1.4 components to be loaded alongside version 2 components within version 2 of the configuration editor; however, currently this is not possible. Even when possible, there will still be restrictions as version 2 of the standard exposes new (additional) data exchange concepts which are incompatible with version 1.4

3. Do both components provide and consume all the required data interactions for the underlying physics for the two models interaction. Breaking the underlying physics will cause instabilities (at best) or wrong answers (at worst). The underlying issue here is that OpenMI provides the means to couple models together, but cannot make judgements on the advisability of doing so. The responsibility for this lies with the user; it is expected that they should have competence in the use and application of both models.

done: 4. was moved to the assumptions underlying the OpenMI architecture.

4. Are all required output adapters implementations compatible. Version 2 allows for adapters tailored for specific applications and hence some combinations could be invalid. Whilst it can be reasonably expected that adapter implementations from the same software source (SDK) should either be compatible or create sensible runtime warnings if not (if developed well). This is unlikely to be the case when mixing adapters from different software sources. Hence, when using output adapters care should be taken to understand their implementation details."

todo: add the points to the list of compliant models on the OpenMI website.

2.2. 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?

(Peter) To keep it in the standard library will make the check on compliancy easier, s. 2.1.2. saying compliant models have to reference OpenMI2.Standard.dll/jar. One argument pro an own library is that new extensions can be more frequently updated than the standard. Anyway, I guess the OAEC has to decide formally about new extensions as it did about compliancy of models in the past.

(Jesper) I believe (at least for C#, I am not sure with java) when we first have released the OpenMI2.Standard.dll, then there are issues in case this dll is updated to include e.g. a dictionary extension: Two different OpenMI2.Standard.dll files having the same version number, but different content. It would be much more safe to release an OpenMI2.Standard.DictionaryExtension.dll, and leaving the original content in the OpenMI.Standard.dll. It may be possible to put it all in a new standard dll, however that requires "intelligent" installers: Assume I am to install a TimeSpace engine and a Dictionary engine, which come with each their version of the OpenMI2.Standard.dll that they want to install and register in the GAC. Depending on the order in which I install the engines, each installer needs to know whether they are to reregister their version of the OpenMI2.Standard.dll in the GAC, to assure that the newest version is the one registered.

2.3. Revisit discussions left out from meeting 29

Documentation Tasks

Document	Update?	update author	author deadline	reviewer	deadline
What's new in OpenMI 2.0	yes	Stef, Peter	5. July	who	9. July
OpenMI 'in a nutshell	yes	Adrian, Rob	5. July	who	9.July
Scope document	y/n	who	-	who	-
The OpenMI Standard2 interface specification	yes	Stef, Peter	7. July	who	9. July
Migrating models	yes	Jesper	-	who	-

Standa made a Word *.doc out of the reviewers' feedback. The suggestions that have been integrated in OpenMI 2 will be indicated. The new document will be put on the wiki / www.openmi.org in order to display that the feedback was indeed valuable.

2.4. Revisit discussions left out from meeting 28

There is a number of discussions there, that has not yet been decided on.

Remove GetHashCode() and Equals() overrides in Backbone package

Similarly, the DescribeSameAs functions are a bit unclear: When does a quantity describe the same as another, which properties should match: description, unit (with description, caption, dimension and conversion factor) or dimension.

Suggestion to make utility functions in the SDK that can do the comparison on the required level and remove the DescribeSameAs methods.

Alternatively, the DescribeSameAs should be precisely documented.

Make IAdaptedOutput implement IInput

maybe later -> a candidate for the wishlist

Generic versions of exchange items and valueset

Cons: It adds complexity to the standard (A standard developer may not have/do not want to bother about this level of skills), and it is specific to java and .net.

pros: It adds more type safety to the code, and also some performance.