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

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