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)
~psi@dhigroup.com, DHI - Water & Environment (psi@dhigroup.com)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don (Gena), Deltares (gennadii.donchyts@deltares.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)
~onnoroos, Alterra (Onno.Roosenschoon@wur.nl)
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
1. Minutes from previous OATC meeting
2. Maintenance and support
- Reported bugs
(GOTO bug list on SourceForge)
- Feature requests
(GOTO Feature requests on SourceForge)
and
(GOTO Feature requests on SourceForge (under forums))
- Help issues
(GOTO help issues on SourceForge)
- Discussion issues
(GOTO discussion issues on SourceForge)
3. OpenMI 2.0 Issues
3.1 Use cases
3.2 OpenMI 2.0 architecture
3.2.1 DataOperation (suggestion from Adrian Harper)
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.
3.2.2 ValuesSet (from ~don (Gena))
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.
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)
5. OpenMI WIKI
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.
