See also: OATC Wiki Home

Date: January 13-15, 2009
Venue: University of Trento and Riccardo Rigon, Italy (Location and hotel information for OATC meeting no 21)
Participants:

Jan Gregersen, DHI / LicTek (gregersen@lictek.dk) (chairman of the meeting)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)
Silvia Franceschi, Universita` di Trento, (silvia.franceshi@hydrologis.eu)

Apologies:

Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)
Rob Knapen, Alterra (Rob.Knapen@wur.nl)
Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Lars Ekebjærg, DHI, (lce@dhigroup.com)

Documents:

http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org

Table of contents

Minutes

1. Minutes from previous OATC meeting

There were no comments to the minutes from last meeting

2. Maintenance and support

2.1 Reported bugs

(GOTO bug list on SourceForge)

There are two active bugs relating to OpenMI version 1.4. Adrian will take care that these are solved before the 1.4.1 release:
1) Unit conversion does not handle missing values
2) GUI 1.4.1 beta issues

2.2 Help issues

(GOTO help issues on SourceForge).

Questions asked on the help forum are quickly answered. So no further actions needed

2.3 Discussion issues

(GOTO discussion issues on SourceForge)

no comments

3. OpenMI 2.0 Issues

3.1 Use cases

We have already created a number of use cases (GOTO use cases). However, these do not seem to be practically useful for the version 2 development at this stage. In order to simplify things a bit we looked at different categories of components that should be equally supported by version 2.

Domain analysis:

Types of components:

  1. A constant value provider(e.g. the value 7.1)

  2. 0D component (typically a time series or a collection of time series.
    Such component may or may not have any spatial location.

  3. GIStype of components. (no time)
    Such components may or may not have time, simply location (e.g. a polygons and associated values.

  4. Analytic function (f(x,y,z,t))
    Components based on analytic functions may have both time and space or only one of these. However, what makes such component special in relation to OpenMI is that data is not beforehand represented on any discrete geometry (e.g. grid) or at any specific timestamps or time spans.

  5. Data base or other simple data providers
    These are different from models because you will have access to all data at any time, as compared to models where you may not be able request data earlier that the current time step time.

  6. Model The time-stepping type of models (has states and problems going back in time)

  7. Optimizer and scenario managers types of components.

When Open version 1.* was developed focus was on linking models (type 6 above). All remaining types can be made compliant to OpenMI 1.* , but you need various workarounds to make it work. It is the intention with version 2 to solve this, so that each of the examples above are supported in a straightforward way.

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

Fig 3.2.1 Overview

Fig 3.2.1 LinkableComponent

Fig 3.2.3 Exchange Items

 

Fig 3.2.4 Quantity and Quality

Fig 3.2.5 Time

 

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.

3.3 Development and release road map

The development plan outlined in the minutes of the OpenMI Association Technical Committee meeting no 19 section 3.3 was made more detailed (see below). All deadlines defined in the plan from meeting 19 are unchanged in the new plan.

The plan has taken into account the periods where people responsible for the various tasks have time set aside to do these tasks.

It if foreseen that we during implementation will have to make some adjustments to the standard. In such cases suggestions to changes will be published on the wiki and we will decide for the standard change either by e-mail or preferably through Skype web conferences. No individuals are allowed to make change to the standard until there is a OATC decision to do so.

Development plan
Iteration 1 : SDK and testing the main concepts

Starts: After the Trento OATC meeting (January 16th 2009)
Ends: Before the Wallingford OATC meeting (March 9th 2009)
Tasks:

  • Implement OATC.OpenMI.Sdk.Backbone
    Implement OATC.OpenMI.Sdk.Backbone.UnitTest
    Deadline: January 28th 2009
    Responsible: Stef
  • Implement OpenMI.Standard Java interfaces
    Deadline: January 28th 2009
    Responsible: Stef
  • Implement Oatc.OpenMI.Sdk.Buffer
    Implement OATC.OpenMI.Sdk.Buffer.UnitTest
    Deadline: February 3rd 2009
    Responsible: Stef
  • Implement Oatc.OpenMI.Sdk.Spatial
    Implement OATC.OpenMI.Sdk.Spatial.UnitTest
    Deadline: February 12th 2009
    Responsible: Jan
  • Implement OATC.OpenMI.Sdk.Wrapper
    Implement OATC.OpenMI.Sdk.Wrapper.UnitTest
    Deadline: February 12th 2009
    Responsible: Jan
  • Test against the 7 component types (see section 3.1)
    Simple unit test, that will be published on the wiki.
    Deadline: March 1st 2009
    Responsible: Gena
Iteration 2: Configuration editor and further refinements

Starts: After the Wallingford OATC meeting (March 13th 2009)
Ends: Before the DHI OATC meeting (April 21st 2009).
Tasks:

  • Implement OATC.OpenMI.GUI.Controls
    Implement OATC.OpenMI.GUI.ConfigurationEditor
    Implement OATC.OpenMI.GUI.Core
    Deadline: April 21st 2009
    Responsible: Adrian
  • Documentation
    In-source comment in the OpenMI.Standard
    Document explaining the main concepts including sequence diagrams
    Deadline: April 21st 2009
    Responsible: To be decided on the Wallingford OATC meeting
  • Target: To get everything to a state where we can start working with real components.
Iteration 3: Migration of commercial models and documentation

Starts: After the DHI AOTC meeting (April 24th 2009)
Ends: Before the Delft OATC meeting (June 9th 2009)
Tasks:

  • Migration of Mike 11 and Mike She
    Deadline: June 9th 2009
    Responsible: Jan
  • Migration of HydroWorks RS and CS
    Deadline: June 9th 2009
    Responsible: Adrian
  • Documentation, migration of the HowTo wiki pages to version 2
    Deadline: June 9th 2009
    responsible: To be decided on the DHI OATC meeting

*Target: To test usability and performance of version 2 for real models.

Iteration 4 : External review and further migration of models

Starts: June 12th 2009-01-21
Ends: October 13th 2009
Tasks:

  • Migration of Delft3D and Sobek
    Deadline October 13th 2009
    Responsible: Stef
  • Assist external reviewers
Iteration 5: Adjustments according to comments from reviewers

Starts: October 14th 2009
Ends: December 19th 2009
Tasks

  • Update the standard, SDK, GUI, and documentation according the comments provided by the reviewers and the OAEC
    Deadline December 19th
    Responsible: OATC
  • Submit the standard release to the OAEC
    Deadline: December 20th 2009
    Responsible: OATC

4. OpenMI Java and OpenMI .net synchronization

The OpenMI 1.4 standard is released both for .net and Java. However, with respect to the supporting tools, documentation and application there are differences:

  • Documentation
    All available documents (e.g. the document A to E series) and the wiki getting started pages are written with the C# implementation in mind. Consequently, all UML's and code examples are targeting the C# implementation. The principles remain the same for the Java and the .Net implementation so the provided documentation can be used both for Java and C# developers, but with some inconveniences for the Java developers.
  • GUI configuration editor
    A OpenMI configuration editor is only available for OpenMI .Net compliant components.
  • SDK
    SDK are available both in Java and C#. However, it is not fully clear if everything is the same in the two implementations.
  • Distribution
    The OATC which is an official subcommittee under the OpenMI Association is releasing the C# source code and applications, whereas the Java SDK is provided by Alterra. The C# SDK can be downloaded directly from www.sf.net as a zip file, whereas the Java SDK only can be accessed through SVN on source forge. Rob has written a wiki page, which describes how to get the Java SDK and how to get started with developing OpenMI in Java.

Over the recent years there have been many discussions about to which extend a Java implementation of GUI and SDK should be provided by the OA (or OATC). The meeting concluded that ideally we should support Java and C# equally, which means that the OATC should provide the Java SDK and a Java based configuration editor also. However, since we do not currently have the resources to both develop the OpenMI version 2 and to extend our tasks with respect to Java development, we realize that for version 1.4.* the OATC can only work with the C# versions. We appreciate the work done by Alterra in providing Java implementations.

For version 2 we will try to find resources to support both Java and .Net equally with respect to the Standard, configuration editor, SDK and documentation

5. OATC Procedures

There were not changes to the OATC Procedures. However, there is still a task to review and update these.

6. www.OpenMI.org and wiki.OpenMI.org

6.1 The new wiki

It has been decided by the OAEC to move the contents of the www.openmi.org to a wiki hosted by Deltares. Jaco has already organized the fist steps, which involved setting up the new wiki space and installing various plug-ins. The task in now on Jan to move the content of the current wiki mirror to the new wiki space and subsequently work on the layout.

6.1 The OATC wiki

At the OATC meeting 19 we decided to review and update the how-to-pages on the wiki. The wiki pages were distributed between Adrian, Stef, and Jan. Jan has done his task, but pages assigned to Adrian and Stef still needs to be updated. A new deadline was set for this task: March 10th 2009. (see also source forge OpenMI tasks .

7. Miscellaneous issues

7.1 OpenMI goes Linux

The following lines describe the development status of the linux portation of

  • the OpenMI environment
  • and an OpenMI compliant model.

7.1.1. Porting the OpenMI environment

  • the OpenMI standard v. 1.4.0,  ... done
  • the SDK v 1.4.1,  ... done
  • the commandline v  1.4.1,   ... done
  • configuration editor v 1.4.1 (Mono 2.0 needed), ... under construction

7.1.2. Porting the Fortran Code from Compaq to ifort on Windows

Generation of an ifort gei.win.dll and a main program and running the 31 test cases.    ... done

7.1.3.Porting the ifort Code from Windows to Linux

Linux ifort compilation of the BAW engine gei.xe.dll on a 64bit system.  ... done

7.1.4. Porting GEIWrapper to Linux

Portation of GEIWrapper (the C#-Wrapper around the engine gei.xe.dll) ... done

7.1.5. Porting WLDelftWrapper to Linux

Original strategy: It could be reasonable to port the OpenMI compliant WLDelftWrapper to Linux (Deltares). Alternatively, Deltares could offer a Linux engine and the information how to access it from a Windows WLDelftWrapper.
New: Meanwhile fast multicore pc cpus made a linux WLDelftWrapper less important for the BAW, see 6.1.7.

7.1.6. Test of a composition

  • composition with commandline in batch mode   ... done
  • generation of a composition in configuration editor    ... under construction

7.1.7. Test System

The BAW test system is a linux workstation with one Intel Xeon Dual Core Processor and SLED 10. We use the 64 bit instead of the planned 32 bit mode, since our workstations as well as our hpc cluster work in 64bit mode.

7.1.8 Merging the OpenMI Linux version into the 1.4.1 branch on source forge
Adrian will create a list of thing to do with respect to merging the Linux version of the GUI into the 1.4 branch after the 1.4.1 is released. This list will be mailed to Peter, and Peter will subsequently take care that the Linux version is available on source forge.

Peter will put the Linux How-to-pages on the wiki.

7.2 The OpenMI SDK and configuration editor version 1.4.1 release

Adrian will provide an updated GUI install and the zipped version of the SDK. Any remarks should be provided by January 30th .

Release notes: Everyone send contribution to the release note (look to your own commits to SVN. Send to Adrian also before January 30th.

Adrian will make sure that there is a news item on www.openmi.org which announce the 1.4.1 release.

7.3 Demonstration of Delft Shell and JGrass

Gena and Andrea gave demonstrations of Delft Shell and JGrass, respectively.

8. Tasks and unresolved issues

All tasks are handled by sourceForge. GOTO: OpenMI Tasks on source forge

9. Any other business

9.1 Meeting dates for the next OATC meeting

The next OATC meeting is extended with one day. This will allow us to more time to actual implementation during the meeting. So new date for the meeting is Monday March 9th to Thursday March 12th 2009 (see also OATC Calendar).