Participants:

Standa Vanecek, 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)
Unknown User (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:
Unknown User (jnh@dhigroup.com), DHI (jnh@dhigroup.com)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Unknown User (moovida), Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)

Documents:

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

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

allow missing xmlns?

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

STANDARD SUGGESTIONS: IIdentifier/IDescribable

Should be merged together!

IIdentifier
{
  /// Unique with respect to instantiated class type i.e.
  /// String unique = instantiated.Getype() + instantiated.UniqueId;
  /// UI's will use these for persistance, hence new component
  /// releases should maintain UniqueId value backwards compatability
  string UniqueId { get; }

  /// Short description.
  /// Suitable for displaying via a UI.
  /// Suitable for translation (hence set)
  /// NOTE: If passed back into component, might be changed, use UniqueId
  string Caption { get; set; }

  /// Longer, more generic, description.
  /// Suitable for displaying via a UI as additional info.
  /// Suitable for translation (hence set)
  /// NOTE: If passed back into component, might be changed, use UniqueId
  string Description { get; set }
}

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

Should be merged together!

IDescribable
{
  string Caption { get; set; }
  string Description { get; set }
}

IIdentifiable : IDescribable
{
  string UniqueId { get; }
}

STANDARD SUGGESTIONS: IArgument

IArgument
{
  ....

  /// Used by UI to determine whether user has to
  /// change/set the value
  /// Returned reasons can be displayed by UI in ignorance
  /// If true returned, reasons will be treated as warnings
  /// if false returned, resaons will be treated as a mixture of errors and warnings,
  /// the Caption should make clear whether a Error or a Warning. UI will display
  /// in order, so typically errors first warnings lator etc.
  bool IsValid(out IDescribable[] reasons);

  ///
  /// *Must* the argument be provided or not?
  ///
  bool IsOptional { get; }

  /// == null: not applicable
  /// != null: list of possible values (of value type)
  IList<object> GetPossibleValues();

  /// Value only returns null if DefaultValue == null, as will
  /// return DefaultValue anyway
   object Value { get; set; }

  /// Allows UI to persist values (e.g. too/from opr file)
  /// without knowing anything about their type
  string ValueAsString { get; set; }

}

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:

  ILinkableComponent.Arguments[0].ValueAsString = "value for argument 0";
  ILinkableComponent.Arguments[1].ValueAsString = "value for argument 1":
  ILinkableComponent.Arguments[2].ValueAsString = "value for argument 2":
  ILinkableComponent.Initialize();

STANDARD SUGGESTIONS: ExchangeItemEventArgs

class ExchangeItemEventArgs
{
   IExchangeItem ExchangeItem;

   /// Message describing the event
   String Message { set; get; };
}

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

STANDARD SUGGESTIONS: IExchangeItemDecoratorFactory

/// (y) The targetItem can be null
/// (used in case of stringing decorators together, and until full stack is
/// constructed targetItem might not be valid).
/// Hence, implementer can use targetItem as a guide only, maybe rename to possibleTargetItem
IDescriptiveIdentifier[] GetAvailableOutputDecorators(IOutputItem itemToDecorate, IInputItem targetItem);

/// List of factories
/// - a component may provide different type of factories:
///   . factory for time inter/extrapolation
///   . factory for spatial inter/extrapolation
///   . factory for Quantity converters: linear conversion, SI-conversions, derivatives handling, etc.
IExchangeItemDecoratorFactory[] ILinkableComponent.DecoratorFactories { get; }

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

/// NEEDED .... or see Stefs suggestion
/// 1 requirement is needed for temporal components to allow progress % calculations
ITime ILinkableComponent.TimeHorizon (?) Will be discussed below (see [Chapter 5|#chapter5]).

			/* Exception Responsabilities
			 * Any ILinkableComponent method can throw an exception of any type
			 * Before final throw out of a ILinkableComponent method
			 *  o Change Status to Failed
			 *  o Notify any delegates of Status change
			 *  o Throw
			 *  o Does NOT call Finish, thats for the calling code as Finish
			 *    as could in turn throw an exception!
			 */

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

/// Name change
/// Really means unadulterated cached values
/// RawValues ?
IList IOutputItem.Values { get; }

/// NEW
bool IExchangeItem.ValidTimeSet(ITimeSet iTimeSet, out IDescribable[] reasons)
bool IExchangeItem.ValidValue(IList values, out IDescribable[] reasons)

/// NEW
bool IInputItem.ValidProvider(IOutputItem iProvider, out IDescribable[] reasons)
bool IOutputItem.ValidConsumer(IExchangeItem iInputItemOrDecorator, out IDescribable[] reasons)

"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 etc so can be bitted

					/* TODO new state in Standard WaitingForFinish
					 * Cant call finish here as might clear up resources
					 * associated with output items buggers etc.
					 * so just need to return and wait for external
					 * controller to call finish
					 *
					 * Desirable to have a new state
					 * LinkableComponentStatus.WaitingForFinish
					 * to make this clear in UI's etc.
					 *
					 * For now will use Finishing
					 */


					// TODO Note I prefer WaitingForData before Updating

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.

public interface IValueSet
{
      IList<IList> Values2D { get; set; }

      bool PreferedOrderIsElements { get; }

      object GetValue(int time, int element);
      void SetValue(object value, int time, int element);

      IList GetTimeSeriesValuesForElement(int elementIndex);
      void SetTimeSeriesValuesForElement(IEnumerable values, int elementIndex);

      IList GetElementValuesForTime(int timeIndex);
      void SetElementValuesForTime(IEnumerable values, int timeIndex);
}

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.

public interface IInputExchangeItem<T>: IInputExchangeItem
{
    IValueSet<T> { get; set; }
    ...
}


public interface IOutputExchangeItem<T>: IOutputExchangeItem
{
    IValueSet<T> { get; set; }
    ...
}

public interface IValueSet<T>: IValueSet
{
      IList<IList<T>> Values2D { get; set; }

      bool PreferedOrderIsTime { get; set; }

      T GetValue(int time, int element);
      void SetValue(T value, int time, int element);

      IList<T> GetTimeSeriesValuesForElement(int elementIndex);
      void SetTimeSeriesValuesForElement(IEnumerable<T> values, int elementIndex);

      IList<T> GetElementValuesForTime(int timeIndex);
      void SetElementValuesForTime(IEnumerable<T> values, int timeIndex);
}

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:

The potential of Integrated Modelling and the OpenMI: Powerpoint 2003 presentation
Java use cases of OpenMI compliant JGrass components: Powerpoint 2003 presentation
OpenMI goes Linix: PDF
From OpenMI Standard 1.4 to 2.0: Powerpoint Show (presentation can be retrieved from Stef Hummel or Peter Schade)
Design of OpenMI 2.0 :Powerpoint 2007 Presentation
Migration of models from 1.4 to 2.0 :PDF, Powerpoint 2007 Presentation
Comparison between Editor v.1 and v.2 :PDF

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