...
Participants:
Jan Gregersen, DHI / LicTek (gregersen@lictek.dk) (chairman of the meeting)
~psi@dhigroup Unknown User (psi@dhigroup.com), DHI - Water & Environment (psi@dhigroup.com)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
~don
Apologies:
Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)
~onnoroos, Alterra (Onno.Roosenschoon@wur.nl Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Rob Knapen, Alterra (Rob.Knapen@wur.nl) (only on Monday)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)Apologies:
Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Objective:
OpenMI version 2.0
Documents:
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org/OATC
Agenda & Minutes (
Minutes are under construction )
1. Minutes from previous OATC meeting
No comments to the minutes from the previous meeting. The minutes were accepted.
2. Maintenance and support
- Reported bugs
(GOTO bug list on SourceForge)
We reviewed the list of reported bugs. Some were already fixed (now in the OpenMI-1.4.1-dev branch on source forge) to be included in the next release. Two bugs remained on the list and were assigned to Adrain and Jan, respectively.
- Feature requestsFeature requests
(GOTO Feature requests on SourceForge)
and
(GOTO Feature requests on SourceForge (under forums))
)
The are two feature requests, which both can and will be included in the next SDK and GUI release 1.4.1. Stef and Jan will take care of this.
- Help issues
(GOTO help issues on SourceForge)
A few questions has not been answered. We agree that questions posted on the help forum should be answered quickly (next day or so). Jan will be responsible for this and either provide an answer him selves or make sure that someone else does it.
- Discussion issues
(GOTO discussion issues on SourceForge)
3. OpenMI 2.0 Issues
3.1 Use cases
no actions to be done
3.2 OpenMI 2.0 architecture
3.2.1 DataOperation (suggestion from Adrian Harper)
| Code Block |
|---|
IDataOperation { int StatusSourceElement(int nSourceElementIndex); int StatusTargetElement(int nTargetElementIndex); } |
This suggestion is aimed at allowing GUI's to assist users when selecting DataOperations.
...
The gui could use
status = NearestPoint.StatusSourceElement(0..N);
to determine what colour color to display each of the elements in the source elementset. ie for the NearestPoint dataoperation StatusSourceElement could return zero for all element indexsindexes
except for the one that is actually nearest. The Gui could then paint all elements in the source element set as black except for one red one.
Of course the gui does not necesarily necessarily know what the dataoperation does. Hence all the GUI could do is colour/label the elements based on what integer was returned and the user
would have to refer to the dataoperation user manual to determine what the codes indicate in that specific case.
We could even state that the returned integer is actually an rgb value.
...
Another example could be a RegularExpression DataOperation. The source element set could be 100 IDBased items, the user sets the RegularExpression.Arg to a regular expression and the gui uses the StatusSourceElement method to hide all non matching elements. Thus giving ConfigurationEditor a Filtering mechanism on the Link connnection connection dialog.
3.2.2 ValuesSet (from Unknown User (don) (Gena))
One of the solutions, hope it is not too exterme but certainly a modern programming technique:
| Code Block |
|---|
public interface IExchangeItem { T GetValue<T>(time); }
|
unit test:
| Code Block |
|---|
IExchangeItem exchangeItem = new ExchangeItem(); IValueSet valueSet = exchangeItem.GetValue<IValueSet>(time); |
--------------
However I do not understand why do we duplicate .NET in the current implementation and wrapping double[] by something like IValueSet, sounds a bit overkill. I can understand meaning of asking something like an entity representing Value of a certain Quantity on a specific ElementSet, which in my opinion should at least keep references to instances of those classes:
| Code Block |
|---|
public interface IValueSet { IElementSet ElementSet { get; } IQuantity { get; } double\[\] Values { get; } }
|
If there are constructive arguments that IValueSet should be only double[] then the folowing code sounds better, and we will get rid of a few interfaces (which is always good once functionality remains the same 
:
| Code Block |
|---|
IExchangeItem exchangeItem = new ExchangeItem(); double\[\] valueSet = exchangeItem.GetValue<double\[\]>(time);
|
Please check a complete and working example in attachment. Hope you'll have time to have a look at it next week 
. In example a method GetValues() should use seme different strategy instead of all those if(...).
In general this way can be a very powerful since it allows all functionality of current version and will also allow to provide conversions on-the-fly in case if someone will want to get value back in some specific format, and user implementation of IExchangeItem will be able to provide it.
3.3 Development and release roadmap
3. OpenMI Java and OpenMI .net synchronization
3.1 clarification on how you consider the state of this SDK (Rob)
Just a small thing that hopefully can be discussed at the next TC meeting (even though I will not be present). The original Alterra Java OpenMI 1.4 SDK implementation that I uploaded to SourceForge was moved from the trunk to a branch (branches/OpenMI-1.4.1-dev/MyOpenSource/Alterra/OpenMI-1.4-SDK) and then the package with some extended interfaces has been removed and the code updated (by Stef), to see if a Java SDK could be made that is very close to the .Net SDK.
I would just like a clarification on how you consider the state of this SDK now. Due to the changes it does not match my (internal) Alterra version of the source code anymore, but on the other hand it is also not (yet) an OATC supported version. Or is it now? Who will do the maintenance of this version? And for someone browsing through svn and looking for the correct Java SDK it might be rather confusing (since it is still in a folder called Alterra)...
4. OATC Procedures
Review and update the OATC procedures (GOTO OATC procedures)
...
6. www.OpenMI.org
7. Miscellaneous issues
7.1 Proposed meeting (Onno)
Would it not be a good idea to plan a meeting in the Netherlands (Wageningen) were at least the Dutch contingent will be present to work on 2.0 issues together. This meeting should take place in the second half of June. Other people here at Alterra, like Peter Verweij, could then also take part if needed.
8. Tasks and unresolved issues
...