See also: OATC Wiki Home
Date: September 7 - 10, 2009
Venue: Alterra, Gaia building, room C011; Wageningen, The Netherlands
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)
Apologies:
~jnh@dhigroup.com, DHI (jnh@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
Daniele Andreis,Universita` di Trento,(daniele.andreis@gmail.com)
Jan Gregersen, LicTek
Documents:
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org
Table of contents
1. Status of the implementation
GUI:
Under development and is usable for simple compositions, clearly work on this will continue until end of year
Compliancy xsd:
Sugestion = self contained task that review can be by email during december rather than at an OATC meeting
Standard
IIdentifiable
Accepting the need to keep IIdentifiable and IDescriable separate (as discussed at length in last meeting). I still feel uncomfortable with an interface with one method in. I find in the UI I am writing more code for which I feel no constructive benefit from except for making code more obscure to read. I would like to suggest that we replace the interface with a
Id { get; }
attribute on the interfaces that require it. I wont defend this if there is great objection to it, life's too short!
Has been discussed shortly and efficiently: We will leave it the way it is.
ILinkableComponent.Prepare()
This method has been removed from the component. However, the majority feels that it should be in again, meaning that the component can rely on the fact that it will never get a GetValues() call or Values get-access before the Prepare() method has been called.
UserCount
A component should be able to keep track of how many users are interested in an exchange item's output.
Has been discussed shortly and efficiently: We will leave it the way it is.
If a component performs an update, it may neglect all "non consumed" output items. An output item is consumed if its list of consumers contains at least one item, and/or if its list of decorators contains at least one item.
Related to this: do we need void Update(params IOutputItem[] requiredOutputItems), or is void Update() enough? The alternative is that the consuming component(s) register/deregister input items to/from the output items that they want to be updated.
After some discussion we concluded that we need a relevant use case for this. Rob will create one in Java, Stef will port it to C#.
If we decide to keep it in, we should explain in detail how a time progressing component behaves when the optional argument is given indeed.
IArgument.IsReadOnly
Is it really really needed? (Stef thought so, but does not consider it essential anymore).
The property is needed indeed. Given the values of other arguments, an argument may become readonly because it simply may not be changed in that situation.
Now, the initialation of a component will go like this:
- The component instance is created.
- The component exposes its arguments (IlinkableComponent.Arguments).
- The value of an argument can be changed by the user.
- This value change of the argument may lead to different possible values and/or read only flags for other arguments, so the GUI will call IlinkableComponent.Arguments again.
- When the user is happy, the Initialize() call is called, without arguments.
So the result of the discussion is that:
- IlinkableComponent.Initialize(IArgument[] arguments) will be changed to IlinkableComponent.Initialize()
Terminology
- Name space: after some discussion we decided to change the name space to OpenMI.Standard2.
The reason to do this, is to facilitate 1.4 model wrapping - Are we sure that we want to use the name IOutputItemDecorator instead of the well known name IDataOperation?
- We should rename either IOutputItemDecorator.Update() or ILinkableComponent.Update() (or both).
(Note: during the discussion on the latter, it appeared to be unclear if of IOutputItemDecorator.Update() should at its turn call its own decorators. This is the case. Jesper will state it more explicit in the documentation.
SDK
The original packages in the 1.4 SDK are not that explitely identifiable in 2.0. Besides of that, more then one model wrapping utility has been developed (by Adrian and by Stef/Jesper), so we should determine what to put in which package.
Other things that to take care of:
- split time buffering and time interpolation
- distinguish one or more decorator packages, implemenented as a third party factory
Java
Standard
During this week, the Java version of the standard has to be implemented and documented.
Utilities/GUI
We will currently put no effort in addinonal java developments, like the backbone, the GUI etc. Most probaby, there will be no time left in the OpenMI-Life project (ending end of Januari) to put any real effor to java.
However, next to having the standard, we will take to:
- have examples of IQuality/ICategory available in the C# version
- put the already available java utilities, like the Buffer and the ElementMapper, on sourceforge and point out that they are there.
Model migration
Samples
Simple River :
Have reviewed and modified src as Stef requested
GroundWater :
NOTE JESPER, have also started modifying the simple GW model for use in examples/tutorials etc., currently WIP will take you through that at next weeks meeting. You might notice that I have moved these examples into new folder structure to facilitate sharing of common code.This common code might find its way into the SDK in the future, or remain seperate as a seperate example. For us to decide lator.
2. Documentation
Main task for the meeting
Create maximum documents to be send to Stephen for review.
Assign rest of the documents to the individual persons
Documentation of the standard.
What it the status of Stephen's review on the C#-oode for the standard? Standa will send Stephen an e-mail.
What is OpenMI - Tutorials
*1 minute tutorial * // suggestion
Download Bin + install
Run GUI
Load composition
Run Composition
See Messages - progress
Look to the results
Status: To be realized as part of the on line help. Will be done by Adrian.
10 minute tutorial // suggestion
Download source code???
Download documentation (standard) ??
Download / compile + install
Open GUI
Create composition - Run composition
See Messages - progress
Look to the results
Add decorator - run ......
Open Reference manual - see basic schema
Clases
Status diagram
Composition XLS
OnenMI model compliensy
Load complex composition
Review of the Components / decorators, links ... properties
Open source code of the hard coded running of the composition
Status: To be realized as part of the on line help. Will be done by Adrian.
Scope document
need to be divided betwean more peoples / per chapters. Simplified contents of all chapters need to be created during meeting
Whats new in 2.0
Final review of existin document need to be done
GUI
Help document, with 2 turials
Started, using SimpleRiver and SimpleGW models, first draft on schedule for Nov end
OpenMI 2.0 Standard specifications
Standard Reference manual (class library) need to be checked if all comments are in the source code -> generate UML
SDK Developer guide/documentation
SDK Reference manual (class library) comments need to be placed in source code -> generate UML
How to
Various HowTo's will be provided (see the How To).
The table below shows the status of and the persons working on these HowTo's. Possible statuses:
- todo
- to adjust (according to new Standerd/SDK)
- first version
- basic skeleton exists (fill in)
- reviewed
- sent (to Stephen Morris)
- ready
subject |
status |
page-author |
page-reviewer |
---|---|---|---|
How to generate a XML file describing compliancy with OpenMI 2.0 |
todo |
Peter |
Stef |
How to migrate from version 1.4 IEngine |
first version |
Jesper |
Adrian |
How to work with OMI files |
first version |
Peter |
Adrian |
How to link OpenMI components via hardcoded interface calls |
first version (see note 1) |
all |
Standa |
How to turn an Ascii file reader into a Linkable Component |
first version |
Jesper |
Stef |
How to turn a database into a LinkableComponent |
first version |
Jesper |
Stef |
How to link models with different grids (spatial mapping) |
to adjust |
Stef |
Jesper |
How to download the most recent source code |
reviewed |
Peter |
Standa |
How to get started with OpenMI and Java |
skeleton exists |
Peter |
Rob |
How to migrate existing Fortran based models codes |
todo (see note 2) |
Stef |
Adrian |
How to generate a LinkableComponent with a Fortran engine on Linux |
todo (see note 3) |
Peter |
Gena |
How to port the OpenMI from Windows to Linux |
todo |
Peter |
Gena |
Note 1: The unit test compositions serve as a base for this. The various unit test programmers will take care that the HowTo page refers to the right source conde.
Note 2: This is a big task, lot of changes need to be done
Note 3: The OpenMI 2.0 compliant component has not been not been generated on Linux yet. The generation should follow the same rules as the generation of a component being OpenMI 1.4 compliant