See also: OATC Wiki Home

Date: 07. October 2010
Time: 14:00 - 15:30 CEST
Venue: Skype Conference Call
Topic: From OpenMI 2.0 Beta to OpenMI 2.0

Table of contents

Participants

Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Jesper Grooss, DHI (jgr@dhigroup.com)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)

Apologies:
-

1. Roadmap to OpenMI 2.0 as suggested by Standa

1.1. TimeLine

Suggested timeline

  • Oktober/November: Release
  • Spring 2011: GUI and SDK (Pipistrelle and Fluid Earth)
  • skype meeting on sdk issues every first and third Thursday of a month (thumbs up)

1.2. Standard

have a look - if we found some possible problems in standard itself. (hopefully not)

1.3. Documentation

Updating of the Documentation

document

comment

task for

status

What's new in OpenMI 2.0

 

-

-

OpenMI 'in a nutshell

 

-

-

Scope document

 

-

-

OpenMI Standard2 interface specification

 

-

-

OpenMI Standard2 Reference manual

when source code will be stabilized

SV

-

"Migrating models

 

-

-

maybe change the names for OpenMI Standard2 interface specification and OpenMI Standard2 Reference manual

Add text from "Explanation of OpenMI Standard Extensions"" to some other document - or change its format to follow style of the other documents

Peter: I would integrate the explanations into the interface specifications as the central document.

1.4. How to

page

comment

task for

status

How to download the most recent source code

no changes???

Peter*

-

How to get started with OpenMI 2.x and Java

no changes???

no changes,
Peter

-

How to link models with different grids (spatial mapping)

small changes

Peter*

-

How to turn an ASCII file reader into a Linkable Component 2.0

source code for latest version exist. Changes reflecting Time extensions
need to be done in Howto page

-

-

Upgrading from 1.4 using the upwards compatible wrapper

Did it work now? Will be included to the official release?
– or put it to the pages later?

-

-

How to upgrade from version 1.4 IEngine

Did it work now? Will be included to the official release?
– or put it to the pages later?

-

-

* only if starting at 12. November is ok

1.5. GUI

We will not release the GUI.

1.6. SDK

We will leave SDK like it is just now. New documentation will not be created.

There are memory problems with large element sets.

2. Issues raised in Rob's mail from 23.09.2010

2.1. Final agreement on the extensions

- not clear if OAEC agrees with it or not.

- proper definition of how to use them and what it means for OpenMI-compliancy. Also when mixing OpenMI endorsed and 3rd party extensions.

Meeting 32 discussion

2.2. Request of US EPA

- how dimensionless data fits into OpenMI without loosing the unit information (measures).

(Jesper)
The issue is that there is a difference between kg/kg and m^3/m^3? To solve the issue for dimensionless quantities, we could add a flag on the unit, saying it is dimensionless, i.e. to give a m/m unit, you would set an m unit and set the dimensionless flag. But should it also be possible to support units like m^3/s/m (used in sewer models, discharge into the system per length unit of sewer)? I think not. If so, I guess we would need two times the base-unit exponent array.

From an OpenMI processing/adaptor point of view, the dimensionless unit is of little use (as I see it, unless I am missing something). It is not possible to do any automatic conversions from kg/kg to m^3/m^3 anyway. It can have some use in validation, in order to check that you are linking items that have the same non-dimensionality. Otherwise the dimensionless information could also just be provided as information in the description of the quantity, and then leaving the standard as it is now.

A flag indicating dimensionlessness could be added to the dictionary extensions (thumbs up)

2.3. Mixing time-dependent and time-independent components

- Clarify what should happen when time-dependent and time-independent model components are mixed in a model chain.

- Is there enough "contextual" information available for processing?

3. Remaining issues from meeting no 33, top 2

Issue

Description

status

decision

OpenMI XSD files

The component and compliancy XSD files still are based on 1.4. Must be extended.

Done by: Rob

Ok (TimeSpace compliancy issued postponed)

TimeSpace compliancy in XSD file

Decide if TimeSpace compliancy needs to be included in the OpenMICompliancyInfo.xsd file and if so how to do it.

Postponed

Mark as deprecated in Beta1

Move interfaces to TimeSpace extension

ISpatialDefinition, IElementSet, ITime, ITimeSet could be moved from the base to the TimeSpace extension

Postponed

Leave as is for Beta1

Update copyright notice

Add year 2010 to the OpenMI copyright header in all source files

Java updates done: Rob.
C# updates done: Stef
(Standard2 only, SDK to be done)

Update headers

Distribution package

Distribute base and timespace extension in a single package or as two?

Postponed

Keep as 1 package for Beta1

Merge IValueDefinition and IDictionaryItem

IValueDefinition (with related classes) and IDictionaryItem bought describe data semantics and could be unified; Peter Gijsbers' mail

<status: open>

(question)

<new issue>

<description>

<status: open>

(question)

Transcript of discussions (meeting no 33) on the above topics and a few other subjects:

  • Compliancy XSD: Remaining issue: Do we want to include TimeSpace specific exchange item information in the compliancy XSD? If so, what should be included and how?
  • Release of the 2.0 Beta: Also notify people who participate in the review process about the new version and changes made according to their input.

4. Next Meeting