scrollbar}
See also: OATC Wiki Home
Date: June 8 - 9, 20010
Venue: Unesco-IHE, The Netherlands
Participants:
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Jesper Grooss, DHI (jgr@dhigroup.com)
Apologies:
~jnh@dhigroup.com, DHI (jnh@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
Daniele Andreis,Universita` di Trento,(daniele.andreis@gmail.com)
Jan Gregersen, LicTek
Documents:
Table of contents
1. Comments from review
Consider support for parallel computations
This is a candidate for an extension to the component, see section "Possible candidates for extensions". We will try to make the standard such that it ease the development of such an extension.
Make clear how use IElementSet to work with OGC formats
Two alternatives were discussed:
- Document how each OGC feature is to be used by the current elementset.
- Make a more general element set, and let the current element set extent from the general one. And open for the possibility for other extensions of the general one, being e.g. the different OGC feature classes.
The discussion turned into which strategy was the best for OpenMI: To document specialized interfaces, or to have general ones and allow them to be extended over time.
Add initialize method to IAdaptedOutput
Adding Initialize() to IAdaptedOutput, similar to the method of the ILinkableComponent .
See minutes of meeting 26 - the "IArgument.IsReadOnly" section - describes that the Initialize should not have any arguments. Though, that has not been implemented, and may produce some work, especially for the GUI. We will investigate the amount of work, and may leave it with the arguments in. In any case we will assure that the two have the same Initialize method signature.
Re-introduce the IState interface
Discussion turned first to whether the IIdentifiable should extend from the IDescribable, in which case the IState is redundant. Their relation has been discussed before.
Especially extra method has been introduced due to the two interfaces not being related.
Two options were discussed:
public interface IIdentity : IIdentifiable, IDescribable {}
or alternatively
public interface IIdentifiable : IDescribable { string Id { get; } }
Currently all classes implementing IIdentifiable also need to implement IDescribable. Hence there is no problem in either ways.
Vote resulted in the bottom case.
IManagedState still returns the IIdentifiable, and will then include the description.
Does not have any impact on SDK.
How to make the standard extendable
Meeting with EPA on how to make OpenMI and FRAMES work together, and also several reviewers, have revealed the necessity of making the standard extendable instead of "all inclusive". since the "all inclusive" is very difficult to predict.
The base idea is to make very general versions of interfaces, and provide specializations of these. These specializations can be released at a later stage than the standard, and without affecting the standard.
See the section on "Possible candidates for extensions".
Strategy for releasing 2.0
Releasing standard and then extensions.
Possible candidates for extensions:
- LinkableComponent: Parallel computing component
- ExchangeItem: FRAMES dictinaries.
- ValueDefinition: ontologies, FRAMES dictinaries.
- ElementSet: Advanced spatial/GIS functionality.
- ValueSet: FRAMES dictinaries.
- TimeSet.
ad: ElementSet: Advanced spatial/GIS functionality:
Typical geometrical element types for models are:
- Point
- LineString - values defined on each LineString coordinate (node based values on a line)
- MultiLineString - values defined on each LineString (element based values on a line)
- 2D/3D mesh based - the IElementSet of today
- Element values (finite volume type values)
- Node values (finite element type values)
- Grid based, element/node/face values
- Structured grid, (x0, dx, xCount)^dimension + rotation from true north
- CurveLinear grid (coordinates for all grid points)
- Polygon/MultiPolygon
Some of these have directly an OGC feature counterpart, while others (the grid) has not. Some of these are covered by the current element set, and some are not, or only in a "generic" geometrical way, i.e. without topology information.
So it would be nice to have a general element set and in time release extensions to the standard that includes new type of "often used"/requested element sets.
Remove loop approach.
Loop approach is not really tested and possibly only half included in the standard. It is better to completely remove it and then add it fully as an extension when it is mature.
Remove the ILinkableComponent.CascadingUpdateCallsDisabled property.
Check in the status flag whether there are specific loop approach flags.
Releasing full standard
The full release, reflecting all suggested review requests, including fully functional and tested SDK and GUI.
Current problems:
No model, neither test models nor real world model has really been used and tested using the 2.0 standard. Hence, there are many unknowns and in order to get around all possible issues, quite a lot of work is required.
Limited resources within OATC for testing and development, in order to get as well the standard as the SDK "correct".
Limited resources for GUI development and support.
Updates to the standard
Documentation, IValueSet:
IExchangeItem.ElementSet == null : spatially independent
IExchangeItem.ElementSet.ElementCount == 0 : spatially dependent but no values available yet.
IExchangeItem.TimeSet == null : Time independent.
IExchangeItem.TimeSet.Times == null : No meaning, not allowed.
IExchangeItem.TimeSet.Times.Count == 0 : Time dependent, but no values available yet.
IValueSet.ElementCount and IValueSet.TimesCount is removed - redundant .