Minutes are under construction )
Date: June 2-4, 2008
Venue: Wallingford Software, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom,
Participants:
Jan Gregersen, DHI / LicTek (gregersen@lictek.dk) (chairman of the meeting)
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)
Apologies:
Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.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)
Objective:
OpenMI version 2.0
Documents:
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org/OATC
Minutes are under construction )No comments to the minutes from the previous meeting. The minutes were accepted.
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.
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.
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.
no actions to be done
IDataOperation { int StatusSourceElement(int nSourceElementIndex); int StatusTargetElement(int nTargetElementIndex); }
|
This suggestion is aimed at allowing GUI's to assist users when selecting DataOperations.
Example:
A DataOperation called "NearestPoint" which could be used to map between a source elementset of N Points to a target elementset of 1 point.
It might be obvious to the user what will happen if he uses this, but what if he doesnt. He needs help as to whether to use this dataoperation or another.
The ideal solution is for the user to ask the GUI to show what would happen if he used this dataoperation on these elementsets during the configuration period.
The gui could use
status = NearestPoint.StatusSourceElement(0..N);
to determine what color to display each of the elements in the source elementset. ie for the NearestPoint dataoperation StatusSourceElement could return zero for all element indexes
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 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.
Whatever, I'm sure you get the idea. Its a small idea but could have a massive impact on usability.
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 connection dialog.
One of the solutions, hope it is not too exterme but certainly a modern programming technique:
public interface IExchangeItem { T GetValue<T>(time); }
|
unit test:
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:
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 
:
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.
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)...
Review and update the OATC procedures (GOTO OATC procedures)
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.