| Wiki Markup |
|---|
{scrollbar}
See also: [OATC Wiki Home|OpenMI AssociationTechnical Committee]
Date: April 8.6 - 11.2, 2009
Venue:[Deltares |http://www.http://www.deltares.nl/], Rotterdamseweg 185, Delft, The Netherlands
h1. Participants:
[~rob.knapen@wur.nl], Alterra, Wageningen UR (Rob.Knapen@wur.nl)
[~s.vanecek@dhi.cz], DHI (s.vanecek@dhi.cz)
[~harper], Wallingford Software (adrian.harper@wallingfordsoftware.com)
[~hummel], Deltares (stef.hummel@deltares.nl)
[~don], Deltares (gennadii.donchyts@deltares.nl)
[~jnh@dhigroup.com], DHI (jnh@dhigroup.com)
[Peter Schade|https://public.deltares.nl/display/~peter_schade], Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
Apologies:
[~jgr@dhigroup.com], DHI (jgr@dhigroup.com)
[~gregersen@LicTek.dk], LicTek, (Gregersen@LicTek.dk)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
h1. Documents:
[http://www.openmi.org/]
[http://sourceforge.net/projects/openmi]
wiki.openmi.org
h1. Table of contents
{toc}
h1. agenda
h1. 1. Minutes from previous OATC meeting
h2. 1.1 Status of the Linux test
Deltares did not find time yet. This afternoon a test will be done on one of the Deltares 64 bit systems (*action*: Bert).
Later this week, preferably Wednesday or Thursday, (*action*) Rob K. will test it at Alterra, on a 32 bit machine.
h2. 1.2 Release 1.4.1
No action taken yet, so still pending. However, in 1.4.0 there appear not to be any really blocking problems.
h2. 1.3 www.OpenMI.org and wiki.OpenMI.org
The Dissimination Committee has concluded that the current www.OpenMI.org is is quite OK, so this site will remain the main OpenMI entry.
However, we will still move the wiki.OpenMI.org content from the public.wldelft.nl site to the new confluence server that has been prepared to serve the wiki.OpenMI.org space.
*Action*: Gena / Stef / Deltares automation department.
h1. 2. Status of the implementation .NET
h2. 2.1 Changes to the standard
All proposed changes resulting from the previous meeting have been realized.
h2. 2.2 Backbone
Gena update the backbone according to the latest version of the Standard. Small modifications by Stef and Adrian afterwards.
*Note*: the documentation is not up to date at all. Actually: the documentation of the Standard is the most important one. We could already start to work on this documentation for the more static items, like the ValueDefinition, ElementSet, etc.
h2. 2.3 Buffer
The buffer has been "ported" to the latest 2.0.
However, there is an issue to adress: the extrapolation, interpolation, etc.
h2. 2.4 Time interpolation Decorator
Stef experimented a bit. Two major issues to have a look at came up:
- when to extrapolate/interpolate
- the component needs to know which decorator is a TimeDecorator.
See discussion in chapter 4 on decorators.
h2. 2.5 GUI
The Gui is quite on its way. To be done:
* details on working with decorators
* actually run the application
Details on working with decorators have been presented by Adrian. (y) We all agreed to the approach of introducing a button that shows a window containing the available decorator and/or factories. The selected one will be added to the component, and thus to the list of output items. By repeated doing this step, the end user can build a chain of decorators.
h2. 2.6 SimpleRiver Model - running in GUI
While developing the GUI, the Simple River Model has been updated also (there might be small issues when really running it).
Note: the Update cascade mechanism is not implemented yet. *Action*: Stef will do that.
h2. 2.7 OpenMIException : Exception - suggestions
Introducing the OpenMI exception is being rediscussed.
The opinion is that it might be done, but that it does not have a very high priority. During the present meeting we will focus on other, more urgent, issues. The OpenMI exception then will be considered at the september meeting.
h2. 2.7 OpenMI 2.0 wrapper around OpenMI 1.4 Components
Jesper worked on it quite a bit, together with Stef when needed. Quite some progression was made.
The content of the task shifted from wrapping a 1.4 LinkableComponent to wrapping the 1.4 Sdk.Wrapper.IEngine.
So people who have implemented their wrapper based on the IEngine will be able to migrate their model to 2.0 quite easily.
h1. 3 Status of the Java implementation
We once again discussed to which extend we should support Java for version 2.0.
|| Part || To be done or not? || How to do it? ||
| Standard | surely t.b.d. | convert C# to Java, including comments, semi-automatically |
| Backbone/Buffer | most probably | take java-1.2 as base |
| Spatial | most probably | take java-1.2 as base (there have been only slight modifications to the IElementSet |
| Wrapper | probably not |
h1. 4 Pending from previous meetings / Other items to be discussed
# Question: what does isAvailable() mean in case of multiple consumers. Do all consumers need to have the same time(s)?
*{_}Discussion/Conclusion{_}*: (y) We decided to extend the IsAvailable() method with an IExchangeItem argument, so that the caller can specify which availability he wants to check:
*bool IsAvailable(IExchangeItem querySpecification)*.
The ValueDefinition/ElementSet/TimeSet definition of the querySpecification specifies exactly what is needed.
Generally speaking, it is one of the consumers that is passed as the argument:
{code:java}
IInputItem consumerThatIsAsking;
consumerThatIsAsking.TimeSet.Times[0] = requiredTime;
while (!providingOutputItem.IsAvailable(consumerThatIsAsking)) {
providingOutputItem.Component.Update();
}
values = providingOutputItem.Values;
{code}
*Note*: We may want te consider looking again at the IsAvailable method, and separate it into 2 different indicators, e.g.
* IsValid on the exchange item
* canProvide or something like that on the decorator.
On the other hand, this would be confusing for the consuming input.
For now, we will start to make more implementation examples. After that, we will look at IsAvailable again.
Related issue: The *while(\!Available){Update}* code above is actually representing the original 1.4 GetValues() call. So it might be wise, to put emphasis again on the still working 'pull approach', to introduce a getValues() call, e.g.:
{code:java}
values = providingOutputItem.GetValues(consumerThatIsAsking);
{code}
This is considered to be a useful extension. It is a convenient method, and it explitly shows the pull approach, so we will add it (y).
It might even be considered to move the method to the LinkableComponent, see also Gena's suggestion on loop vs. pull later on this page.
# Remark: When experimenting with the IsAvailable(), Rob B. and Stef introduced the IExchangeDefinition (see below). Rob K. actually introduced the same interface in the java version. Indeed it is quite natural entity, the exchange definition. *Question*: do we want to introduce it (?) .
{code:java}
public interface IExchangeDefinition
{
IValueDefinition ValueDefinition { get; }
ITimeSet TimeSet { get; }
IElementSet ElementSet { get; }
}
{code}
# Are we happy with IOutputItem.IsAvailable() and with ILinkableComponent.Validate(), or do we need additional methods on LinkableComponent and/or ExchangeItem to check validity.
We are happy. The only small change that has been proposed and has been agreed on is:
(y) The return value will be an array of strings, to let the component compose a multi line message.
# Should we introduce a boolean argument that indicates whether the component should run in a pull mode (like in OpenMI 1.4) or in loop mode?
# [Discuss component operation mode here] *comment from Peter Gijsbers need to be discussed*
*{_}Discussion/Conclusion{_}*: (y) We decided to let the LinkableComponent have a propery: *CascadingUpdateCallsDisabled*.
The default is *false*, indicating that the component is running in Pull Driven mode (there will be a cascade of update() calls. This Pull Driven mode has to be supported by every component.
If set to *true*, the component is expected to run Update()-step by Update-Step(), controlled by some outer world (which may be another component). If the component does not support this Update() by Update() way of running, it will throw an Exception when *CascadingUpdateCallsDisabled= true* is called.
In the GUI, the user hat to tell which component is at the end of the chain. This _controlling component_ will be triggered first.
# The Timezone issue has been re-adressed.
*{_}Discussion/Conclusion{_}* led to the following decisions:
## Daylight Saving Time jumps in time series are not allowed
## The TimeSet will contain a property that expresses its offset from UTC, expressed in hours (see below). The Gui will check these offsets, and if they are different, it will ask the user to put a decorator in between.
Note: in future and/or more platform specific versions of the standard we may reconsider introducing the timezone info again.
# Decorator issues:
#* Do we need to recognize the type of decorator (time, space, SI-conversion)?
#* Do we want to support 3th-party decorators indeed?
*{_}Discussion/Conclusion{_}*: (y) We will add an Update() method to the OutputDecorator. The linkable component calls this Update() on all its decorators at the end of its own Update(). This actually is completely the same as what happens in the current 1.4 Wrapper: after IEngine.PerformTimeStep the wrapper updates the buffers.
* Decorator issues, GUI:
** How to support the end user, when "chaining" decorators? (y) Taken care of, see section 2.5
** To identify/describe the various decorator factories, the IOutputDecoratorFactory will be IIdentifiable/IDescribable
* Decorator issues, other:
** Is is useful to let the component have a property OutputDecorators, containing the list of already created decorators? (n) For now, we will stick to the "keep it lean and mean" principle. As soon as it is really clear that it is needed (*action* Gena) it will be added.
* IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
Various solutions were proposed (see below). Disadvantage of having an enumeration in the Standard is that it can not be extended easily. An object type definition would be more specific.
Rob K. concludes that Alterra's approach works quite well for what we want. The approach is based on recognized strings in the key of the Argument. *Action*: Rob K. will provide an example. After studying that, we will discussed what to do (?).
Adrian's proposal:
{code:java}
namespace OpenMI.Standard
{
public enum EArgType
{
String = 0, // default
Bool,
Int,
Double,
Path, // presummed to exist and accessable
FilePath, // presummed to exist and accessable
PathNew,
FilePathNew,
XML, // Rob: can be used together with a schema for complex argument data
MIME, // Rob: might be useful to pass in images, or text documents, etc.
}
/// <summary>
/// The IArgument interface defines a key - value pair. If the property ReadOnly is
/// false the value is editable otherwise it is read-only.
/// </summary>
public interface IArgument : IDescribable
{
/// <summary>
/// Type that string value represents and can be converted to
/// </summary>
EArgType ValueType { get; }
/// <summary>
/// The key (string) in key-value pair.
/// </summary>
string Key {get;}
/// <summary>
/// <para>The value (double) in key-value pair.</para>
///
/// <para>If the ReadOnly property is true and the property is attempted to be changed
/// from outside an exception must be thrown.</para>
/// </summary>
string Value { get; set; }
/// <summary>
/// Defines whether the Values property may be edited from outside.
/// </summary>
bool ReadOnly {get;}
}
}
{code}
Gena's proposal:
Current version:
{code:java}
public interface IArgument : IDescribable
{
string Key { get; }
string Value { get; set; }
bool ReadOnly { get; }
}
{code}
Proposed change to cover types:
{code:java}
public interface IDescribable
{
string Caption { get; set; }
string Description { get; set; }
}
public interface IValueDefinition : IDescribable
{
Type ValueType { get; }
bool DescribesSameAs(IValueDefinition otherValueDefinition);
}
public interface IArgument : IValueDefinition
{
object Value { get; set; }
bool ReadOnly { get; }
}
{code}
# Suggestion by Gena on pull / loop approach
*_Discussion/Conclusion_*: (?) A good idea to introduce the GetValues, to recognize the pull approach. However, instead of on the LinkableComponent, for now it has been put on the output item (see above).
{code}
// =================================== pull approach
var triggerExchangeItem = component.OutputItems[0];
triggerComponent.GetValues(triggerExchangeItem);
// =================================== loop approach
while(!allComponentsAreFinished)
{
foreach(var component in components)
{
if(component.Status != LinkableComponentStatus.Finished)
{
component.Update();
}
}
}
public interface ILinkableComponent
{
LinkableComponentStatus Status { get; }
void Initialize();
void Validate();
void Update();
void Finish();
IList<IInputItem> InputItems { get; }
IList<IOutputItem> OutputItems { get; }
bool CascadeUpdateCallsDisabled { get; set; }
// Suggestion: ask for specific values: e.g. filtered data
IList GetValues(IInputExchangeItem query);
}
{code}
# Gena's suggestion for 2D return type (see below)
*_Discussion/Conclusion_*: (n) Not to be included in the standard 2.0. Could be used in the backbone, and probably in later versions of the standard.
{code}
public interface IInputItem : IExchangeItem
{
IMatrix Values { get; set; }
}
public interface IOutputItem : IExchangeItem
{
IMatrix Values { get; }
}
public interface IMatrix : IList
{
int Rows { get; }
int Columns { get; }
object GetValue(int row, int column);
void SetValue(object value, int row, int column);
object[,] GetValues(int startRow, int endRow, int startColumn, int endColumn);
void SetValues(object[,] values, int startRow, int endRow, int startColumn, int endColumn);
}
{code}
h1. 5. Release 2.0 plan
h2. 5.1. Documentation / basic / changes
We will identify the parts of the Standard that are quite stable by now. These Items are:
* IValueDefinition and all related interfaces/enumerations
* IElementSet and related enumerations
* ITimeSet / ITime
This means that effectively the only interfaces not to be documented directly are:
* ILinkableComponent
* IExchangeItem and its descendents.
Once the documentation of the more stable items is complete, we will check what the documentation will look like in the Object Browser, Enterprise Architect, and in Doxygen.
Steps to take before we can invite external reviewers to have a look at things:
* *Action*: Johan will take the lead in gathering reviewers (all of us have to think of names).
* *Action*: Rob B. will write a 2 page document on what are the main differences between 1.4 and 2.0.
* *Action*: All: cleanup all code in 2.0 from code which is not relevant anymore (left from 1.4). This is including unit and integration tests.
* *Action*: All of us will update the documentation of the interfaces, properties and methods whereever and whenever possible
* *Action*: On july 10th, Standa will tag a version, generate EA-documentation, and inform the reviewers.
h2. 5.2. Alpha release
h2. 5.3. External review and further migration of models
h2. 5.4. Migration of commercial models and documentation
h2. 5.3. Discusion
h1. 6. OATC Procedures
h1. 7. Miscellaneous issues
h2. 7.1 SourceForge clean up
Recently, I checked out the entire OpenMI source forge repository. This took forever, the size of the whole repository is 4.2GB. From this, 3.8GB is located in directories called "Wrappers", which is mainly code and data from HEC, RAS, CUAHI and MODFLOW. Long time ago we made a folder on the OpenMI source forge called MyOpenSource. The idea behind this directory was to have a place where people could put some code, that did not fit into the SDK, but still could be useful for OpenMI developers. Placing an entire model, data and binary files there is in my opinion too much. It is annoying to have so long download times when checking out and it may also add to some confusion, that the OpenMI repository mainly consists of various wrappers. My suggestion is to ask those responsible for the code in the wrappers directories to make their own repositories on source forge, where after we can remove all these files from the OpenMI repository. In order to make sure that people know about these important wrapper developments we could make a page on the wiki with a short description of the various projects and link to the location of the code.
Kind regards
Jan Gregersen
*{_}Discussion/Conclusion{_}*: Gena will have a session with the Hec-Ras and Modflow developers at the beginning of july. Most propably their developments will be moved out of the current repository.
*Action* Gena will take care that, once this is done, the OpenMI sourgeforge project will contain a reference to the Hec-Ras and Modflow developments.
*Comment by Jan:* Thanks :-)
h2. 7.2. September OATC meeting in Hamburg?
* Do the OATC members agree with a public talk?
* Aim: Spreading the OpenMI in Germany
* Target group: Developers
* Tuesday afternoon, 9th of September
*{_}Discussion/Conclusion{_}*: We all agree that indeed it will be useful to have a public session on on Tuesday afternoon on the OpenMI 2.0 developments.
The main part of the public will be java oriented, and we may not have java up and running by then, but the .Net version most probably will suffice to introduce the new concepts to the developers.
Before mid of july the OATC will confirm that indeed the public session will take place.
h1. 8. Tasks and unresolved issues
All tasks are handled by sourceForge. GOTO: [OpenMI Tasks on source forge|http://sourceforge.net/pm/task.php?group_id=136874&set=custom&group_project_id=54144&_assigned_to=0&_status=1&SUBMIT=Browse]
h1. 9. Any other business |
Page History
Overview
Content Tools