| Wiki Markup |
|---|
{scrollbar} |
See also: OATC Wiki Home
Date: November 3-5, 2008
Venue: Deltares, Rotterdamseweg 185, Delft, The Netherlands
Participants:
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)
Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)
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
Agenda
1. Minutes from previous OATC meeting
Minutes:
The minutes from the last OATC meeting were accepted
2. Maintenance and support
2.1 Reported bugs
(GOTO bug list on SourceForge)
Minutes:
No changes
2.2 Help issues
(GOTO help issues on SourceForge)
Minutes:
No changes, seems we are doing well with respect to providing answers to questions. It was notified that now also people outside the OATC group are providing answers, which is highly appreciated.
2.3 Discussion issues
(GOTO discussion issues on SourceForge)
Minutes:
No changes
3. OpenMI 2.0 Issues
3.1 Use cases
Minutes:
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
3.2.1 Current status
The OpenMI Standard interfaces before the meeting are shown in the figure below. The implementation is located in the trunk on source forge.
3.2.2 Events
At the last meeting we discussed if we adapt the way events are used in C# rather that using our own implementation.
See page : Use standard events instead of many interfaces like IListener, IPublisher
Minutes:
Gena presented his ideas and it was decided that Gena will add events and event args in the standard,
add unit test for LinkableComponentt in backbone demonstrating the events, add log4net and show how to use it in the backbone.
3.2.3 Configuration interfaces
Minutes: ToDo
3.2.4 IQuality and IQuantity
see also: Rename IValueDefinition to IMeasurable
Minutes:
We decided not to rename the IValuesDefinition interface. We will review all interface names when we have the final draft version of the standard 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.
* 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
Minutes:
It was decided to use the C# types for date and time instead of the Modified Julian time. Gena will make the changes to the version 2 standard and SDK. There is still a question about whether we also should include time zones. We will look into this at the next OATC meeting.
3.2.7 IArgument
Comment by Jan: I think we need a more powerful argument interface. Such interface should facility different types such as doubles, strings, bool, and selection types. By selection types I think about situations where the user will select on or multiple options from a predefined list. At our last meeting the IDictionary interface was mentioned, but I have doubts that it will provide the functionality needed. Then I came to think about the functionality provided by XML schema files. E.g. for our OpenMICompliancy schema file a pretty complex data structure is well defined. However, I would prefer not to include schema files into the nice clean interfaces based standard, so maybe we can find a interface based solution that has the same functionality as a schema.
Minutes:
We investigated improving the IArgument interface. Gena will make a suggestion for the next OATC meeting.
3.2.8 Using Object to pass the values
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:
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:
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 is 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:
We agreed to add an interface for persistent state management. Stef will implement the interface
3.2.11 ILinkableComponent instantiation
Comment by Peter: The OMI file is a pragmatic method to instantiate a component. A Factory pattern should be considerd for the Standard, where the default implementation of the SDK is based on the OMI file.
Minutes:
We could not reach an agreement about using a factory pattern instead of the OMI file that is currently used in OpenIM 1.4. Stef and Peter will write at documents that i more details explains how the factory pattern will could work and some examples of situation where using the factory pattern is beneficial to the end users (those that create compositions). We will discuss the factory pattern again at the next OATC meeting.
3.3 Development and release road map
Version 2 development plan:
September 11th 2008 - November 2nd 2008
Finish the configuration architecture (the decorator pattern)and update SDK and GUI.
November 3 - November 5 2008.
OATC meeting in The Netherlands: special focus on return types and geometry (ElementSet)
November 6th 2008 - January 12th 2009
Implementation of new geometry interfaces and return types. Update SDK and GUI
January 13th - January 15th 2009
OATC meeting in UK. Final decision for the version 2 standard interfaces. This also implies deciding which requested feature that will not be include in version 2.
January 16th - March 9th 2009
Complete implementation and unit testing of the version 2 standard, SDK and GUI
March 10 - March 12 2009
OATC meetings, Denmark. OpenMI 2 standard, SDK and GUI beta release
March 13 - April 20, 2009
Migrate and test selected commercial models and components for version 2
April 21 - April 23
OATC Meeting i The Netherlands. Evaluate real models test and further refinements for version 2
April 24 - June 09 2009:
Continues real models testing, write documentation.
June 10 - June 12 2009
OATC meeting in Denmark. Final evaluation, submission of the version 2 to the OpenMI Association Executive Committee for acceptance
June 13 - October 13 2009
The standard is reviewed by external reviewers
October 14 - December 19, 2009
Adjustments based on comments from the reviewers. Finalization of the OpenMI 2 release.
December 20th 2009
OpenMI 2 standard, SDK and GUI release.
Minutes:
There were no changes to the development roadmap. We are still on track..
3. OpenMI Java and OpenMI .net synchronization
Minutes:
No new issues here.
4. OATC Procedures
4.1 Proposal for procedures for OpenMI Standard releases
see: Proposed procedure for OpenMI Standard releases
Minutes:
This procedure will be discussed at the next OAEC meeting, no new comments from the OATC
4.2 Proposed procedure for evaluation of OpenMI compliance
see Proposed procedure for evaluation of OpenMI compliance.
Minutes:
The OpenMI compliantcy acceptance procedure will be discussed at the next OAEC meeting. In case this procedure is accepted by the OAEC, the OATC will recommned that Stef becomes the OpenMI Compliancy acceptance manager. Stef will review the proposed procedure and make changes or add comments to the wiki page where it is described.
4.2 Review and update the OATC procedures
What is the status with respect to procedures other that the standard release procedure (point 4.1)
Minutes:
No changes to existing procedures.
5. www.OpenMI.org and wiki.OpenMI.org
5.2 Could we simply use a wiki for the official OpenMI web site
A proposal to the OAEC is ready in a draft version: see OpenMI Association website proposal_MB.doc
Minutes:
We will await the OAEC decision.
6. Miscellaneous issues
6.3 Submitted OpenMI compliance XML's
Since last meeting some XML has been submitted. See TUDamstat.zip
The currently accepted components are listed here : M.4.2 Compliant software
6.4 Demo of HRW SDK and Pipistrelle
Adrian will demonstrate the work done by Walling Software.
Minutes:
The OATC appreciates that HRW provides nice alternatives to the SDK and GUI provided by OATC.
7. Tasks and unresolved issues
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 .
h.4 The 1.4.1 SDK and GUI release
*Minutes:
Jan will check the reported bugs, and fix the bugs assigned to him. Then report back to Adrian, who will create a beta 1.4.1 beta version (around December 5th). The target is to release before end of 2008.