| scrollbar |
|---|
See also: OATC Wiki Home
Date:
...
November 3-5, 2008
Venue: Deltares, Rotterdamseweg 185, Delft, The Netherlands
...
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 Unknown User (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)
Rob Knapen Unknown User (onnoroos), Alterra (Rob.Knapen@wurOnno.Roosenschoon@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl) ~onnoroos
Apologies:
Rob Knapen, Alterra (OnnoRob.Roosenschoon@wurKnapen@wur.nl)
Peter Gijsbers, Deltares Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Gijsbers@deltaresSchade@BAW.nlDE)
Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Apologies:
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 were 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 now 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
3.2.1 Current status
We need to remind ourselves about the current status for the OpenMI version 2 development - what is implemented and why. See also: OpenMI.Standard ver 1.4 to ver 2 change log
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 backboneMinutes: Stef explained the recent developments and the current status for the OpenMI version 2 standard to the meeting participants.
3.2.
...
3 Configuration interfaces
At the last OATC meetings the focus has been on interfaces that relates to the configuration part of the standard
see also: Jan's ideas for version 2 configuration interfacesMinutes: ToDo
3.2.
...
4 IQuality and IQuantity
One of the change requests we have received for OpenMI Standard version 2 is the ability to handle categorized data. Examples could be "high", "medium", "low" or "grass", "corn", "potatoes".
See use case: Qualitative data support
See UML for proposed OpenMI interfaces
3.2.4 Spatial issues
We will focus on the spatial issues at the next OATC meeting in Delft. However, since Andrea is attending this meeting, it could be wise to start the thinking process now, utilizing his knowledge about GIS and specifically OpenMI GIS.
...
3.3 Development and release road map
Some time ago a prioritized list of issues that should be included in the next release was elaborated (OpenMI version 2 Development plan ). Seems that we already have covered most of the issues plus the quantity/quality issues, which are not listed in the plan. However, we still need a plan with some more strict deadlines.
Since we are dealing with a standard release we must follow the procedure for OpenMI standard releases. So far we do not have such procedure formally accepted by the OAEC. On this agenda (point 4.1) is a proposal for a procedure. So, let's discuss this first and then see how we can fit some dates into this.
...
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.
3. OpenMI Java and OpenMI .net synchronization
The OpenMI standard is released both in a Java and a C# version. This imposes some problems / challenges that we continuously must address:
- The OpenMI standard interfaces.
- Can the proposed changes for the OpenMI 2 release be implemented in both programming languages
- Which one should be developed first and how do we make sure that the implementation are conceptually the same
- The OATC SDK and GUI
For OpenMI 1.4 we have a full implementation of the SDK and GUI in C# but for the Java version the SDK is provided by Alterra and there is no GUI available. How are we going to handle this for version 1.4 and for version 2
- Linking models / components compliant to the Java and C# version, respectively
When running OpenMI linked configurations objects are passed between the components. This makes it technically difficult to handle linked systems where some components are OpenMI Java compliant and some OpenMI C# compliant. At previous meeting we have discussed this issue and one of the conclusion is that since we are not the only ones having this problem, at solution for this may arise from outside. What is the current status with respect to this?
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. Rob: Maybe it is (sometimes) a solution to serialise the object as XML or JSON and then exchange them from Java to C# and back. There might be open source solutions, e.g. http://woxserializer.sourceforge.net/
. Of course performance is a potential issue.
4. OATC Procedures
4.1 Proposal for procedures for OpenMI Standard releases
From Jan: I have at task from one of the previous OpenMI Association Executive Committee meeting to elaborate a proposal see: Proposed procedure for OpenMI Standard release procedure. These procedures will define the rules for how to go from OpenMI Standard release version x to OpenMI standard version x+1. I think that the OpenMI standard it selves is the most important asset of the OpenMI Association, which also means that rules for how this standard may be change becomes very important. I thought a lot about it (apparently, more difficult that I first anticipated), and I have now written my first idea down in draft form. I would appreciate if we, at the OATC meetings, could discuss these ideas.
Please review the Proposed procedure for OpenMI Standard releasesreleases
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 meeting was generally happy about the presented proposal. Each member til put specific comments using the commenting facility on the wiki. Jan will ask the OAEC also to read and comment and ask to have this issue in the OAEC agendaOpenMI 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.
...
We have already put enormous efforts into documenting the OpenMI standard and the SDK. By the end of the HarmonIt project we wrote hundreds of page in the formal documentation (the Book A -F stuff), and more recently we have worked especially on the wiki to improve the documentation in order to facilitate people new to OpenMI (the HowTo pages). So even though we are well above the typical documentation level for research projects, we still need to improve. I think that improving documentation and guidelines will be the area where we achieve most effect in order to get OpenMI used around the world. Naturally we still need to develop new features, but should not sacrifice documentation. I believe that the getting started pages on the wiki is currently be best entry for new people and I will typically direct such people to these pages. I would appreciate if we could spend a little time going through the getting started pages and assign task for improvements. Specifically, I have noticed that after the upgrade of the wiki sofware some pages have been corrupted.
David Maidment recently wrote in a mail to Roger. "I think the OpenMI conceptual model is presently contained in Appendix G or somewhere else near the end of your large manual. I wonder if this model could be restated in a separate document so that reviewers of it don't have to extract the key points out of a huge software engineering manual. I am thinking of something that could be read and understood by your hydrologic science colleagues at CHE, the scientists in our ChyMP group, etc.". Most likely he did not know about the wiki, which make me think if the wiki exposed sufficiently on the official openmi web,
(Jan)
...
5.2 Could we simply use a wiki for the official OpenMI web site
Currently the official OpenMI is exposed on three different web sites www.OpenMI.org, wiki.OpenMI.org and http://sourceforge.net/projects/openmi. There are naturally good reasons for running these three web sites. www.OpenMI.org is the very official nicely formatted quality assured stuff, whereas the wiki is more quick and dirty, and finally sourceforge provides tools for version control, task and bug trackers, and help forum. It is my impression that people, in their search for information about OpenMI may get confused, also I sometimes have doubts about how much funding we will have when the Life project ends, hence we need to go for agile solutions. I discussed these issues with Michiel Blind some month ago and we agreed it should be investigated if we simply could use a wiki for the official web site. There are examples of very nicely formatted wikis around (see e.g.). In my opinion largest advantage of switching to a wiki, it the ability for a large group to easily edit the text on the wiki - so we get the nice stuff out there quickly. So, what is the OATC opinion about this? Can we recommend specific wiki software? Would it be possible to spend some time setting something up, that will demonstrate how is could look? Jan Gregersen
...
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.
Plan from now until next meeting
...
6. Miscellaneous issues
6.1 Meeting plan for 2009
I have proposed dates for the OATC meeting for 2009. Please see the OATC Calendar
Minutes:
The proposed dates were accepted except the meeting from April 28-30 2009, which was moved to April 21-23 2009. The OATC wiki calendar has been updated to reflect the agreed dates for meetings.
6.2 How can Java developers contribute
(from Rob Knapen( There are some people expressing interest to contribute to the OpenMI
Java development, any ideas how this can be set up? Is it something the
OpenMI TC would like to handle, as part of the OpenMI open source
community?
Minutes:
Curret status: The Java SDK is under MyOpen Source on source forge is difficult for people to find.
Rob and Andrea will make a wiki HowTo page describing the Java SDK and explaining how to use it and where to download it.
6.3 OpenMI Compliance HTML tool
Adrain has completed the first version of a tool that can take the OpenMIComplinanceInfo.xml file and transform it into readable HTML. This tool is intended to be used by the OATC in to take XML files submitted to the OpenMI Association and convert them to HTML and then put these op the OpenMI web (the OpenMI compliant components page). I tried to make it work, but I did not have sufficient patience to make it work. Always a problem with command line programs that take a number of arguments and file paths. Since this tool is something that is going to be used only whenever someone submits a XML file to the OpenMI Association for approval, I think it would be very useful with a simple user interface. Otherwise you will forget how to work with it from time to time. I can see that one of the arguments is the path to the xsd file. Would it not be simpler to have a copy of this file at the same place as the OpenMIComplinceHTML.exe file, it is always the same XSD file that should be used anyway.
As I see it a GUI will simply be one form / dialog which has a field to browse for the OpenMICompliance.xml file and one field to define the name and location of the ouput.HTML file.
Minutes:
Adrian made a nice user interface and the produced HTML files looks very nice. The general idea is that these HTML should be put on the official OpenMI page (www.openmi.org). However, we need to find out what to do with the model already listed. Jan will make a couple of wiki pages to see how this could be done, and subsequently mail OATC to ask for comments.
Jan Gregersen
6.4 Sourceforge SVN cleanup
From Jan: For some reason I like to have a full copy of OpenMI SourceForge repository on my local disk. However, currently this is about 4GB data (takes forever to download). One of the problems is the HEC model data that for some reason is checked into the repository. Could we somehow remove these data files and possibly also review if some of the branches are outdated and can be removed.
Minutes:
Gena will create new my openMI open source version control repository on source forge and move the HEC files to this repository
6.5 OpenMI workshop at the BAW
There will be an OpenMI workshop at the BAW in Hamburg on the 31. October 2008. The aim of the workshop is to encourage modellers and developers in Germany to join the OpenMI community. The BAW is interested in finding partners with a strong interest in 2D or 3D models.
We sent the potential attendants a questionnaire. The feedback to the questionnaire displayed a technical interest and can be discussed with the developers as well as with the dissemination committee. The most demanded question was how to make an existing model OpenMI compliant. Thus, we and the participants would appreciate OpenMI developers as presenters.
...
Peter Schade
6.6 Review of submitted InfoWorks OpenMI 1.4 xml files
Adrian has on behalf of Wallingford Software submitted xml files for InfoWorks according the the OpenMI 1.4 standard. Formally, the OATC should review these files and make recommendations to the OAEC for accepting or rejecting the components as officially OpenMI compliant. The files are attached to this agenda: InfoWorksXMLZipFile
Minutes:
OATC decided to recommend that the submitted xml's are accepted
7. Tasks and unresolved issues
All tasks are handled by sourceForge. GOTO: OpenMI Tasks on source forge
*8. Any other business
Plan from now until next meeting
...