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

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

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>
<new issue>	<description>	<status: open>

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.

Table of contents