...
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)
~don (Gena), Deltares (gennadii.donchyts@deltares.nl)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
~onnoroos, Alterra (Onno.Roosenschoon@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl) Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Apologies:
Rob Knapen, Alterra (Rob.Knapen@wur.nl)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)
Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Documents:
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org
...
1. Minutes from previous OATC meeting
Minutes: ToDo
The minutes from the last OATC meeting was accepted
2. Maintenance and support
...
(GOTO bug list on SourceForge)
Minutes: ToDo
No changes
2.2 Help issues
(GOTO help issues on SourceForge)
Minutes: ToDo
No changes, seems we are doing well with respect to providing answers to questions. It was notified that also people outside the OATC group are providing answers, which is highly appreciated.
2.3 Discussion issues
(GOTO discussion issues on SourceForge)
Minutes: ToDo
No changes
3. OpenMI 2.0 Issues
3.1 Use cases
Minutes: ToDo
The use cases were not consulted at this meeting. We will make a detailed review of the use cases at the next meeting, when the draft OpeNMI 2.0 architecture is in place in order to check if we covered the functionality defined by these use cases.
3.2 OpenMI 2.0 architecture
...
see also: Rename IValueDefinition to IMeasurable
Minutes: ToDo
We decided not to rename the IValuesDefinition interface. Review all interface names when we have the final draft version of the architecture ready.
3.2.5 Spatial issues
see: Changes to spatial classes related to interoperability with OpenGIS
Minutes: ToDo
* We discussed if topology information is needed in the IElementSet. We decided that if someone has a use case show it is needed, he should present this. Otherwise we will not include topology in the standard. Actually, there is one use case, which is the case of coupling a river flow model and a water solute transport model. In such case the solute transport model will adapt the grid of the river models and therefor also need the topology. However, we do not find this case important enough to make the changes to the standard.
* The changes suggested see(Spatial Issues), were accepted, except for the ICoordinate - wee will keep the GetXValues(elementIndex, VertedIndex) and so on....
* We will define a new interface called IRegularGrid which extends the IElementSet interface. This interface will have the following properties: X0, Y0, dx ,dy, nx, ny, and angle.
3.2.6 ITime
...
Unfortunately Rob cannot participate in the meeting. However, Rob had provided two documents; DynamicObjectModel.pdf and Seamless OpenMI Layer.doc, which are relevant for our discussions.
Minutes: ToDo
It was decided to use a list of objects as return type. Stef will update the standard interfaces accordingly.
3.2.9 IInputExchangeItem
Comment by Peter: In the design as presented before the meeting, the IInputExchangeItem has a Values-set property. I wonder if this is wise from a communication perspective. to outsiders. We want to pull-mechanism to remain the main focus of OpenMI components, such that they can easily be used in a service-oriented architecture. When introducing SetValues at the root level of an IInputExchangeItem, it is much more difficult to explain that we prefer usage of the pull-mechanism, but that some advanced applications may need this put mechanism. I would therefore recommend to move the Values-set property to a separate (derived) interface called IAdvancedinputExchangeItem. This makes explanation much easier, while we introduce less risk with components not being able to handle a set-value.
.
Minutes: ToDo
For the time being we will not make an advanced interface for setting values. Once we have the draft standard architecture completed and start documentation we will decide what to do. The main issue to to find out what is easiest to explain, since it with respect to functionality will be more or less the same.
3.2.10 State management
Comment by Peter: Finally, it becomes time for a persistent state. However, it might be wise to evaluate the experiences with the current state mechanism.
Minutes: ToDo
We agreed to a an interface for persistent state management. Stef will implement the interface
3.2.11 ILinkableComponent instantiation
...
All tasks are handled by sourceForge. GOTO: OpenMI Tasks on source forge
...
8. Any other business
h.4 Suggestion for changing the location for the next OATC meeting
*Minutes:
It was suggested to have the next OATC meeting (January 13-15 2009) in Trento, Italy. Andrea will check if Univertity of Trento will host the meetings and report back to Jan within a couple of weeks. If we decide to move the location of the next meeting, all already planned meetings will shifted accordingly .