OpenMI Association Technical Committee meeting no 25

Skip to end of metadata
Go to start of metadata
OpenMI Association Technical Committee meeting no 24 Meetings OpenMI Association Technical Committee meeting no 26

See also: OATC Wiki Home

Date: November 9 - 12, 2009
Venue:BAW, Hamburg, Germany

Participants:

[~s.vanecek@dhi.cz], DHI (s.vanecek@dhi.cz)
Daniele Andreis,Universita` di Trento,(daniele.andreis@gmail.com)
Roger Moore, on Mo + Tu (rvm@ceh.ac.uk)
Imran Younas on Mo + Tu (imun@ceh.ac.uk)
Stephen Morris on Mo + Tu (smorris@butford.co.uk)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
[~don], Deltares (gennadii.donchyts@deltares.nl) Mo - Wed
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
Jesper Grooss, DHI (jgr@dhigroup.com)
Jan Gregersen, LicTek on Mo (afternoon) + Tu (Gregersen@LicTek.dk)

Apologies:
[~jnh@dhigroup.com], DHI (jnh@dhigroup.com)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
[~onnoroos], Alterra (Onno.Roosenschoon@wur.nl)
[~moovida], Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)

Documents:

http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org

Table of contents

1. Minutes from previous OATC meeting

2. Documentation (most important)

Primary about C# based on this prepare Java

2.1 Standard

To produce the final version of the standard the following steps have to be taken:

  • Wednesday morning: the Oatc finalizes the comments in the standard
  • Before the end of this meeting: the documentation will be generated from the code (using Enterprise Architect)
  • Before the end of the week, Steven will review the documentation, makes adjustments in the source
  • After that, the documentation will be generated again, and will be provided to the Oaec
  • During Wednesday and Thursday, we will try to produce the additional documents (see next section)
  • The Oaec will meet next week, and will hopefully approve on this version to be a candidate for review

To support the review process we will:

  • clearly present the Standard, the current version of the SDK, a presentation of the GUI, and the documentation the wiki
  • facilitate downloading/installing these items
  • ask reviewers to sign up to the wiki as reviewer
  • indicate how the reviewers can post their comments
  • organize the wiki in such a way that we can easily keep track of and summarize the comments

Modified 1.4 documentation

The 1.4 document "The OpenMI Standard in a nutshell", together with the document "What's new in OpenMI 2.0" is a good base for "The OpenMI 2.0 Standard in a nutshell".

Jan emphasizes that the nutshell document is not enough as documentation. We should produce a document comparable to 1.4's "Part C - the org.OpenMI.Standard interface specification", maybe a bit less intensive.
We will do our utmost to produce such a document next week. Documentation that needs update (prioritized):

  • Comments to the source code, Standard only (Stef)
  • What is new in OpenMI 2.0? First version in trunk/doc. (Stef)
  • How to migrate from 1.4 (Jesper)
  • UML diagrams, conceptual diagrams of 2.0. (Gena)
  • 1.4's "Part C, Interface specification" document (all - we take a first look thursday morning)
    • What to take out, rewrite, update. Less comprehensive than 1.4.
  • UI help document (Adrian)
  • Howto document (Getting Started) on the web. (Peter)
    • Create skeleton.
  • 1.4's "Part A, Scope" document
  • 1.4's "Part B, Guidelines" document
  • The OpenMI 2.0 Standard in a nutshell
  • The paper presented in JoH (Gregersen, Gijsbers, Westen). We must take care of copy right issues here.
  • The Tuesday afternoon presentations
  • The minutes in of the Oatc meetings
  • Scope document about the OpenMI. Look at the 1.4 scope document.
  • SDK documentation (SDK namespaces/organization). As class library?

Tasks:

  • Standa:
    • Make the sequence diagrams available in Enterprise Architect
    • Gather the sources. If they can not be found, Standa will let a tool generate Word documents from the relevant pdf's
  • Adrian:
    • Make a document presenting the GUI (done by: realized during meeting)
    • Produce a help document, with 2 turials in (the tutorials will also be put on the "what is OpenMI" documentation page. (done by: end of November)
    • Update compliancy xsd for review at next OATC meeting
  • Stef:
    • Documententation in the Standard: (done by: realized during meeting)
  • Jesper:
    • How to migrate (done by: first version realized during meeting)

Structure of the 2.0 documentation web-pages

  • What is OpenMI
    • 1 minute tutorial
    • 10 minute tutorial
    • Scope document
  • Whats new in 2.0
  • OpenMI 2.0 Standard specifications
    • Standard Reference manual (class library)
  • SDK Developer guide/documentation
    • SDK Reference manual (class library)
  • GUI user manual
    • GUI Reference manual (class library)
  • How to
    • How to Migrate from 1.4
    • How to migrate existing Fortran based models codes
    • How to work with OMI files
    • How to connect OpenMI components via interface calls
    • How to link to Excel
    • How to turn an Ascii file reader into a Linkable Component
    • How to turn a database into a LinkableComponent
    • How to make linking of models with different grids possible.
    • How to get the most recent source code for the GUI and SDK
    • How to get started with OpenMI and Java
    • How to port the OpenMI from Windows to Linux
    • How to generate a LinkableComponent with a Fortran engine on Linux
  • Review of 2.0 standard (restricted access)

2.2 Model migration

From 1.4

For the new model (modified existing documentation)

Changes compare to previous version

2.3 SDK

Components migrated to the 2.0

Automatic generated EA

Changes 1.4

2.4 Tools

Modified 1.4 documentation

2.5 GUI

Progress as of 26/08/09

  • Simple C# River example
    • Has been largley rewritten to conform with version 2
    • Uses base classes that hide some of drudgery of implementation, see (in namespace Oatc.OpenMI.Examples.ModelComponents.SimpleCSharpRiver.Wrapper)
      • class ItemBase {}
      • class OutputItemBase : ItemBase {}
      • class OutputItemDoubleBase: OutputItemBase{}
      • class InputItemBase : ItemBase {}
      • class InputItemDoubleBase : InputItemBase {}
      • class InputFlowItem : InputItemDoubleBase {}
      • class OutputFlowItem : OutputItemDoubleBase {}
      • class LinkableComponent  : ILinkableComponent, IDisposable {}
      • class RiverModelLinkableComponent : LinkableComponent {}
    • These have many TODO's which indicate Standard queries and unimplemented features.
  • UI Editor
    • Largly Rewritten, still much to do, currently ....
      • Add/Remove Models
      • Composition Save, Open & Reload
      • New opr format valid for
        • models
        • exchange items (including decorators) examples under ??\Examples\ModelComponents\SimpleCSharpRiver\Data\Rivers
      • New Link dialog
        • Allows adding of decorators via factories (3rd party factories still to do)
      • New run dialog
        • Run, Abort & Reload
        • Real time update of model status via events
        • Basic Log info
      • Unit Tests
        • Completed
          • Stand alone Simple C# river
          • Two Simple C# rivers in series (Unidirectional)
        • Todo
          • Two Simple C# rivers in series (Unidirectional) with 1 decorator
          • Two Simple C# rivers in series (Unidirectional) with 2 decorators
          • Two Simple C# rivers in series (Bidirectional)
STANDARD SUGGESTIONS: OMI XML

Conclusion: Give warning on missing xmlns field, but still load file.

STANDARD SUGGESTIONS: IIdentifier/IDescribable

Conclusion: Accepted. Name may be changed to IDescriptiveIdentifier.
Conclusion after documenting the standard according to this: Not fully accepted yet.
It leads to the strange situation that the items that currently are only IDescribable and not IIdentifiable now have to provide a unique identifier.
We currently only have one interface that is IIdentifiable but not IDescribable. However, in the GUI, even a state would ppreferably have a state and/or a description, so a better suggestion might be:

ADJUSTED STANDARD SUGGESTION: IIdentifiable/IDescribable
STANDARD SUGGESTIONS: IArgument

Conclusions:
We agree that that we need a method access the value as an argument with a string. (Pictured above as ValueAsString.
Gena will check other standards on the naming of this property or method.
We agree that the opr file will store the Assembly.Class info for a model instance, as well as the arguments that are used for that instance
Initialize call will let the component try to initialize itself. If the component does not succeed to initialize, it sets it state to Failed and throws an exception. The exception text will contain a clear message indicating what went wrong.
characteristics should be placed in Description. Together with IArgument.ValueType this provides enough information to know what type of arguments should be provided.
The Initialization of the Linkable Component will be split in first setting the arguments, and then initializing the model, see below. Please not that each argument key can appear in the list only once:

STANDARD SUGGESTIONS: ExchangeItemEventArgs

Original suggestion/remarks have been discussed and agreed upon. ExchangeItemEventArgs has been reduced to what is above.

STANDARD SUGGESTIONS: IExchangeItemDecoratorFactory

Original suggestion/remarks have been discussed and agreed upon. Result is as above.
Gena will try to show by coding that a single factory is more handy. If he succeeds in showing this, we will go back to the single factory.

STANDARD SUGGESTIONS: ILinkableComponent

Agreed upon.
Note: there is a 'gap' when the component crashes on a runtime exception (e.g. array out of bounds), so it can not set Status == Invalid itself. We might consider let the Gui set the status to Invalid. To be studied.

STANDARD SUGGESTIONS: IExchangeItem

"RawValues": indeed we should indicate clearly in the documentation here that we are talking on the basic values, as they are in item, according to the TimeSet and the ElementSet.
Discussion on the NEW proposition: we for now leave it as a utility in the SDK. If we think we need it on the interface to support less trivial exchange items, we will introduce it in the standard.

STANDARD SUGGESTIONS: LinkableComponentStatus

enum should be 1,2,4,8: Agreed
WaitingForFinish: Agreed, however: we will call it LinkableComponentStatus.Done WaitingForData before Updating: Agreed. Related to this:
The IOutputItem will be extended with a property:
IOutputItem.IsLocked;}}This flag will be set to {{true for each output item that the linkable component is producing output for. It will be set to false as soon as the output is computed.
The flag serves mainly the loop approach, but it may also be beneficial in case of bidirectional links in the pull approach.

2.6 Test cases

2.7 General introduction

2.8 Linux

3. Review of the implementation

3.1 SDK + standard

3.2 Already migrated model

3.3 Running of the connected models from GUI

3.4 Pending tasks

4 Plan of the Ver. 2.0 release

4.1 Alpha for review (documentation, announced on the OpenMI Web)

4.2 Beta + new release of the documentation

4.3 Final delivery -+ text for the Life project report

5 Necessary changes to the Standard

Suggestions based on the implementation. Only if really needed !!!!!!

Additional status for LinkableComponent.Status

The status 'computation done, but not yet finishing' can not be speficied. This occurs when one component in a composition is done, while others are not. The deployer will call Finish when all components are done. Suggestion: add the status WaitingForFinish.
Has been discussed, see above (LinkableComponentStatus.Done).

IOutputItem.Decorators

During a plenary Skype meeting one of the questions was whether the list of added decorators should be public or not (see). During the discussion it was suggested to put the list of decorators not on ILinkableComponent, but on IOutputItem. This indeed is very useful, because then the
IList<IOutputItemDecorator> IOutputItem.Decoratorsproperty facilitates update the decorators in the right order.
We will indeed add this list to the IOutputItem.
The AddDecorator and RemoveDecorator methods from the LinkableComponent will be removed.

Time Horizon / Spatial domain (back) on ILinkableComponent

We removed TimeHorizon from ILinkableComponent. However, configuration time it still would be handy, as well as run time, to display a progress bar.
Of course, there now is IExchangeItem.TimeSet.TimeHorizon, but the TODO in the documentation of ITimeSet.TimeHorizon shows that one could easily (and most probably would preferably) explain this as the time horizon of the available resp. required time.
However, exactly the same can be said for the spatial domain 'horizon' of a component. Where can the component do its work, where are things available or required.

To handle part the issues mentioned above, we in 2.0 introduce:
ITimeSet ILinkableComponent.TimeExtent For symmetry, we would like to have SpatialExtend too, but we have no clear insight in the actual usage and consequences, so we will put on the wish list for 3.0 something like:
IElementSet IOutputItem.SpatialExtent

The actual runtime situation is then presented by the current anItem.ElementSet and anItem.TimeSet, i.e.:

  • anItem.ElementSet: for what location(s) are the values required (input) or available (output)
  • anItem.TimeSet.Times: for what time(s) are the values required (input) or available (output)
  • anItem.TimeSet.TimeHorizon:
    a. InputItem: for what time span may an input item require values (thus covering 1.4's EarliestInputTime mechanism):
    b. outputItem/decorator: in what time span can I provide values
    Additional definitions:
    . TimeSet.Times == null : time independent item
    . TimeSet.Times.Count == 0 : time dependent item, but no values available yet.
    . TimeSet.TimeHorizon == null: time independent item
    . TimeHorizon.StampAsModifiedJulianDay == Double.NegativeInfinity : far back in time
    . TimeHorizon.Duration == Double.PositiveInfinity : far in the future

Mechanism to indicate whether an output item has up to date data or not.

This mechanism, e.g. a flag needsUpdate (the inverse of what was once introduced as isAvailable) is needed for the loop driven approach. However, it is also useful for optimization in the pull driven approach. If nothing has been changed at the providing side, the previous values can be used.
To be discussed at the meeting.

IQuality / ICategory

For consistency the ICategory.Values will be changed to type object instead of string, unless Rob K. has arguments that this is wrong
It was suggested to make ICategory extend IEquatable, but this has been rejected (no .Net specific items in the standard).

IValueSet instead of IList

We agreed that we introduce the IValueSet. It will be proposed as below. During the review phase however, we will clearly state that it is a first suggestions, and that any remark very welcome.

add generic version of IInputExchangeItem, IOutputExchangeItem, IValueSet

We tend to include a generic version of interfaces like IInputExchangeItem, IOutputExchangeItem, IValueSet (see examples below). However: we should either introduce Generics as fully supported and elaborated concept, including the java version, or leave it out for now. Given the stage of the project, we chose the latter.

6 Public talk

The public talk by the Oatc was visited by the OAEC and by about ten external participants.

The program and the presentations are available here:

Comments from the meeting:

  • Optimized Get/Set value compared to 1.4 is good - no need for dictionaries of linkId's, quantityId's and ElementSetId's
  • General return type of exchangeItem allows for a specialized set of quantities in one exchange item.
    • Do we need further support for this in the Standard? Could be an extension to the released version.
  • GUI - how to change the arguments of a decorator? Is there already!
  • What is the difference between the link and the provider-consumer relation? We have to be very explicit in the documentation there.
  • Clarify the "locationSpecification" term from the presentation.
  • Nice to see events in the standard.
  • Generic version of standard
    • Make a OpenMI.Standard.Generic namespace and put it there?
  • Fully 1.4 wrapping into 2.0.
    • Changing namespace will make things easier - OpenMI.Standard2. Though probably not a strong enough argument for changing the standard namespace.
  • GUI - Displaying values of exchangeitems/monitoring the change of values.
  • How to link a java and a .NET LinkableComponent?
    • Possible to do this through some standard communication framework.
    • RabbitMQ - spring.NET - others exists as well.

7 Version 3 Wish List

  • Support of super computing and parallel computing
    • OpenMP, MPI, ...??
  • C++ version of standard
  • JAVA/.NET interoperability
    • Allowing cross platform OS (Linux/Windows)
  • Version 2 makes some features possible, but realistic examples need to be developed and tested
    • Dynamic changes of ElementSets
    • Datasases
    • WebServices
  • Interoperability with other standards
    • OGC, .... ???
    • US frameworks?
  • Tools to support 3D models
    • Interpolation, buffering, ...
  • Improved UI to improve introduction of public to technology and its possibilities
    • PlugIns, Google Maps, ....??
  • Consistent use of generics in standard

8 Some pictures

Some pictures, taken during the four days of the meeting
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.