See also: OATC Wiki Home

Date: July 1, 2010
Time: 09:00 - 10: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)
~jgr@dhigroup.com, 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

(Peter) The current specifications define the ILinkableComponent, which is still time (Modified Julian Date) and space dependent.
Suggestion: Until 9. July mainly specify the IBaseLinkableComponent and a small general explanation of the Time+Space extension. The full Time+Space specification should follow after the sdk has been updated and tested.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.
To be decided .

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 compliancy with the flexibility of OpenMI 2 standard is split into two levelsversion 2 can be recognized in the compliancy definition. The OpenMI compliancy on the first level refers to a set of basic interfaces whereas the OpenMI extension-compliancy includes additional as well as to optional extension interfaces, e.g. for time and space dependent components. The IBaseLinkableComponent 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 can also comply to one ore more extensions, by implementing the IBaseLinkableComponent interface and at least one of the extension interfaces which it wishes to comply to, 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, optionally with extensions,  ...
  Alternative. 3a ... must, when compiled, reference the OpenMI.Standard2*.dlldlls/jars, which is 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 as well as an OpenMI extensioncomponent 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.
5 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.
6 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 basic ILinkableComponent interface. This component now would have to implement the basic interfaces and the time and space specific extension interfaces for becoming OpenMI 2 compliant.

Decision : We choose for the second description, including the rephasing of Jesper

2.1.

...

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

...

(Peter)
"Linking OpenMI 2 compliant components has become much more flexible than it used to be with OpenMI 1.x. Components with different concepts or in OpenMI language extensions can exchange their data. A component with the classical Modified Julian Day time definition can for example provide a consumer component, defining its simulation time by an index, with data. The provider would implement the time and space extension whereas the consumer could implement an extension for index-related dictionaries. The provider should contain an AdaptedOutput converter using both time definitions and thus being able to convert the time to the index value. More knowledge about the underlying extensions is required from the user in order to select the appropriate items and to check the plausibility of the results. This is the price being paid for higher flexibility, less 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 will be easier to use.

When writing this documentation in Summer 2010, only the base interfaces and an extension for the classical time and space dependent components are available. Future extensions could support parallel computing, compliancy with the standards of the Open Geospatial Consortium OGC and much more.

...

(Adrian)
"Potential users of an OpenMI compliant component should understand the following point

...

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."

Decision : we will move 4. to the assumptions underlying the OpenMI architecture.

2.1.4. What does the compliancy definition mean for an application developer?

todo, after 2.2. has been decided

3. New discussion topics

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?

...

(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

...

(Jesper) It was discussed in the last meeting to add extra events to the TimeSpaceExchange item to keep track of when the timeset and elementset changed. I would suggest to put these directly on the ITimeSet and ISpatialAxis/IElementSet instead. Especially, for the ISpatialAxis/IElementSet it could also be nice with a property bool IsDynamic, to indicate wether the ISpatialAxis/IElementSet can change at all.

...

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.

3.4. Should an ITimeSpaceLinkableComponent override some of the IBaseLinkableComponent methods:

(Jesper) Currently an ITimeSpaceLinkableComponent provides its inputs and outputs as IBaseInput and IBaseOutput. Are these always transferable to ITimeSpaceInput and ITimeSpaceOutput, or could there be cases where other types of inputs and outputs are suitable? Would we even allow that? It could be considered to add methods to the ITimeSpaceLinkableComponent like:

public interface ITimeSpaceComponent : IBaseLinkableComponent
{
  new IList<ITimeSpaceInput> InputItems { get; }
  new IList<ITimeSpaceOutput> OutputItems { get; }
}

That would require all inputs and outputs to be of type ITimeSpaceInput and ITimeSpaceOutput. I guess that would make it difficult to make an ITimeSpaceDictionaryComponent, combining the TimeSpace and the Dictionary extension, since they would each require a different type of their inputs and outputs lists.

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.

maybe later -> a candidate for the wishlist

3. New discussion topics

...