See also: OATC Wiki Home

Date: March 9-12, 2009
Venue:Wallingford Software, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom,
Participants:

Standa Vanecek, (chair), DHI (s.vanecek@dhi.cz)
Unknown User (jnh@dhigroup.com) Johan Hartnack , DHI
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)

Apologies:

Jan Gregersen, LicTek (gregersen@lictek.dk)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)
Jon Goodall, Univ South Carolina (goodall@engr.sc.edu)
Rob Knapen, Alterra (Rob.Knapen@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)

Documents:

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

Table of contents

Minutes

1. Minutes from previous OATC meeting

2. Maintenance and support

2.1 OpenMI 1.4.1 release

Two new issues have come to light
1) GetHashCode
2) Event check boxes (worked in 1.2, broken 1.4 onwards)
adrian will review these and decide whether to include in 1.4.1 release, delay to 1.4.2 or 2.0.0
Then do whatever required to release 1.4.1 ASAP

3. OpenMI 2.0 Issues

3.1 Oatc.OpenMI.Sdk.ModelWrapper

Introduction

As for OpenMI version 1.4 we also need a wrapper for model engine for version 2. Such wrapper will assist people which are not oo specialist in making their models OpenMI compliant. I have made the first considerations for making such wrapper package. At first, it was my intention to build a new wrapper that could access the model engine through the old IEngine interface or something that was very close to this. This seemed logic because the IEngine basically has very little to do with OpenMI, but reflect the obvious was of accessing a time stepping kind of model engine. However, since the version 2 ILinkableComponent interface is much more like the IEngine interface, it turned out to make more sense simply to implement the ILinkableComponent interface directly.

Migration of the simple river

My approach has been to start migrating one specific model and based on experiences from this design a generic wrapper. This was actually also the approach we followed when we designed the version 1 wrapper. Simply migrate specific models where after it became clear how to make the generic wrapper. For my wrapping I have used the well know simple river. You can find a description of the simple river here: Oatc.OpenMI.Examples.ModelComponents.SimpleRiver. However, the simple river is written in Fortran, which makes things a bit more complicated, so I have translated the Fortran part to C#, but kept the clear destination between wrapper and engine. Both the wrapper and the engine are checked in on source forge in the trunk under the namespaces: "Oatc.OpenMI.Examples.ModelComponents.SimpleCSharpRiver.Engine" "Oatc.OpenMI.Examples.ModelComponents.SimpleCSharpRiver.Wrapper". If you search the code you can find places where I have written comments starting with "Note:". These are comments to things that we may want to change to the standard or the SDK.

Experiences from the migration

Simple Access methods

Implementing all the simple methods such a ComponentIdentifer, InstaceIdenfer, TimeHorison and Initialize went smoothly. Almost no changes as compared to implementing these method under the IEngine interface.

Update and ExchangeItems

For the simple river I made specialized implementations of output and input items. So, in my case I have FlowInputItem and FlowOutputItem, which were inherited from Backbone.InputItem and Backbone.OutputItem, respectively. Both classes has an initialize method, where a reference directly to the corresponding data in the model engine can be set. - in my case simply an index in a array.

The Update method in my LinkableComponent is very similar to the pattern used in the old wrapper implementation of the the GetValues method. First update every input exchange items (I implemented an update method in my FlowInputItem). This will ensure that data from outside in feed into my engine. Then the time step is made, and finally all output exchange items are populated with the data calculated by the engine. However, there is a potential performance problem. I have assumed that I do not know if anyone will ask my output items for data, which means that each and every output item must be updated after each time step. I could have checked if the output item had consumers and only update items with consumers. However, I think that it would be very unfortunate if you are required to add a consumer to an output item in order to get the data. A better solution would be to override the [] method in the Values property so data is only copied to the output exchange item when needed. It turns out that, when we use the System list this is not possible. So, we could consider to make out own implementation of IList.

Unit Test

I made two unit tests; a RiverModelWrapperTest and a ConfigurationTest. The first one tests the simple access and the second one tests a case where two instances of the simple river models are linked. So, far I have not implemented any decorator so the configuration test is a bit of a hack. However, according to the standard it is allowed to add OutputItems to InputItems, so in principle this should be ok. Perhaps it would make more sense only to allow decorators to be added to inputItems.

Conclusions

When I did the implementation I had many doubts about how to do things right. I also have some worries about the standard - is it too flexible to ensure safe linking of components by third party users. Anyway, my suggestion is to, at the OATC meeting, to go through the code (the wrapper as well as the unit tests), and discuss the implementation for each method and evaluate the OpenMI standard based on this.

3.2 Remarks on Standard as result of Java review

From the Trento C# version I (Stef) created a java version, code only, no comments, which was reviewed by Rob. See trunk/OpenMI.Standard/src/javaFor2.0.
This led to some remarks, of which a few were "java only", but some of them reflected on the Standard in general. Items to be addressed at the next meeting:

  1. IDimension.equals() should be been renamed to IDimension.describesSameAs(), to be constistent with IValueDefinition.describesSameAs(), and to put emphasis on the fact the we are comparing dimensions from a "content point of view", and not implementing the language's Object.equals() function
    1. (thumbs up)
  2. Question: do we still want to have the hardcoded integer enumeration values in ElementType, DimensionBase, etc.? I think they originated from the time that we also wanted to describe these possible values in c and/or Fortran.
    1. (thumbs up)
  3. Question: what does isAvailable() mean in case of multiple consumers. Do all consumers need to have the same time(s)?
    1. (question) Leave in for now, review after more implementation, one suggestion of modification bool isAvailable(whosAsking);
  4. Question: Collection or Set instead of List for (In|Out)putExchangeItems in LC?
    1. (thumbs down) Leave as is, as definatly cannot use set as unimplemented in .NET currently.
    2. (question) Gena: I will check if changing it to ICollection<> works fine.
  5. Question: Introduce IState instead of Object? This will emphasize the relation between IManageState and IPersistentState. Additional suggestion: IPersistentState extends IState.
    (b.t.w: makePersistent / readPersistentState are wrong names, should be something like getAsByteStream)

    Gena will discuss with Rob

    1. (question) Unresolved at this time, if Rob can convinve Gena then we can (thumbs up). The suggestion is the following: Suggestion about changed to state management
  6. To be discussed: Introduce generics in IOutputItem.Values()? i.e. weakly typed via <T>
    1. (question) Gena will implement examples in the SDK, but not, for now, in the standard
  7. Remark: Working with providers/consumers, we should take care that such a circularity might give garbage collection problems

    Implementing IDisposable and removing item from Provider/Consumers there might solve the problem

    • (question) Point noted, no aggreement as to solution
  8. Question: for Java, shall we use Observer/Observable for events? We then have to offer a base implementation comparable with the current IListener/IProvider.
    1. (thumbs up) accepted, Rob and Gina to investigation a suitable solution. The suggestion is the following: Suggestion about Java observer based event handling
  9. To be discussed: what exactly is returned by IOutputDecorater.Arguments()?

    Adrian suggested to have Provider there in the interface, then we can step to the previous decorators (if there are any) and get their arguments, and show them nicely grouped in the GUI.

    1. (thumbs up) resolved by other item on agenda

3.3 Suggestions for the states and possible transitions between the states of the ILinkableComponent

If component has Invalid status and we call Validate() - it may even call Update() on another components in order to validate itself.

New things:
(thumbs up) WaitingForData status
(thumbs up) Loop around Validate after each Update()
(thumbs up) Invalid status

Action Stef: will add these changes to the v2 Trunk

3.4 More suggestions on v2.0 changes

  • Move IsAvailable to IExchangeItem. Is it only for a thread-safety? If yes than see also ICollection.IsSynchronized

    Stef: The question is confusing, the actual issue is that we should distinguish between IsAvailable and IsValid.
    We are now realized that there is a difference between IsAvailable (only for output item, means it is for consumers) IsValid (probably for IExchangeItem, meaning if item is valid in the context of current component, maybe updated during Validate() call)?

    • (question) To discuss lator
  • Move Values { get; set; } to IExchangeItem

    Stef: alternative would be to add get to the IInputExchangeItem

    • (thumbs up) get accepted,
    • (question) set review lator
  • Change ID to Id - .NET Style Guidelines, FxCop
    • (thumbs up) , it is our intent to follow FxCop guidelines
  • Add params keyword to IArguments[] args parameter in Initialize(IArgument[] args).
    •  Adrian review, if happy then ... (question)(thumbs up)
  • Add IArguments[] Arguments { get; } to ILinkableComponent
    • (thumbs up)
  • Change "string Validate()" to "bool IsValid(IExchangeItem item)"

    Gena: probably the second one is not needed if we will have IsValid in IExchangeItem.
    string return type in the Validate() has to be changed to void.

    • (question) Requires review after more experiance with implementing standard
  • Add "params IExchangeItem[] items" argument to Update() in order to specify explicitly what should be updated.

    Can be used for example to run analysis only in geographical specified area

    Can help in the optimizing of the buffer

    This will improve performance a lot if we call Update(items) via internet

    Should we use IExchangeItem there (meaning only value definition, times, elements) or IOutputItem

    • (thumbs up) as IOutputItem, maybe later generalise to IExchangeItem i.e. allow IInputItem
  • Add WaitingForData status to the LinkableComponentStatus
    • (thumbs up) see previous item
  • Remove AddConsumer/RemoveConsumer and use BindingList in the implementation instead to listen to IOutputItem.Consumer.Add() / Remove()
    • (question) Not critical yet, so leave for now, review again later
  • Temporal ==(rename)==> TimeSet and add Durations, TimeZone properties to it (see also changes from Rob in Java version)
    • (thumbs up) Rename
    • (question) Requires discussion in lator meetings
  • When we get loops in the compositions - we have to tell which component will be first! (WHAT SHOULD WE DO IN THIS SITUATAION?) Relevant when implementing the Runner process in GUI
    • (question) Revisit in lator meeting
  • Replace all ITime, ITimeStamp, ITimeSpan by: System.DateTime, System.TimeSpan. Should be straightforward. For components working in Julian only time in FORTRAN CalendarConverter can be used. But for .NET all nice features of the .NET date time, time span will be available, e.g. DateTime.AddDays(int), DateTime.AddHours(int), time1 > time2, time1.AddDays(1) > DateTime.Now, and so on.
    Seems to be very straightforward and simple to implement.**
    •  (question) Review lator (today?)
  • Change XYPoint+XYZPoint, ZYPolyline+XYZPolyline => Point, Polyline (make it look more like OGC entities)
    • (question) Review OGC methods to see how we know when a Z coordinate exists?
  • Split IIdentity into class IIdentifiable { long Id { get; set; } } and class IDescribable { string Caption { get; set; } string Description { get; set; } }
    • (thumbs up) Splitting interfaces
    • (question) Make various interfaces derive from IIdentifiable, to review
  • Make ComponentId and InstanceId properties strings - currently it is a bit overkill.
    • (thumbs up) Properties on ILinkableComponent
      • IDescribable InstanceDescription { get;  }
      • IDescribable ComponentDescription { get; }
  • Do we need a TimeHorizon in the ILinkableComponent ? Seems to be useless since we have ITemporal
    • (thumbs up) Move TimeHorizon to ITemporal
  • IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
    • (question) Adrian to come up with proposal for next meeting

How IOutputItem.Values can be used, one possible way:

  • Component1 <>-- [OutputItem1] --> [InputItem1] --<> Component2
  • Component2 updates and sets times, elements, quantity/quality which it needs in the IntputItem1
  • Component1 updates and sets new computed values into it's OutputItem1
  • OutputItem1 (IOutputItem implementation) will check it's Consumers[], which are of course IInputItems, and if they are compatible - will set values into them
  • If IInputItems are not compatible - there should be a DataOperation / Decorator inserted in between (or more than one), or error should be generated.

Please put comments here: Discussion on the possible use of IOutputItem.Values

We should have way in the decorator to trace it in the debugger, gui.

  • Make IOutputDecorator to be:
interface IOutputItemDecorator : IOutputItem
{
   IArgument[] Arguments { get; }
   IOutputItem DecoratedOutputItem { get; set; }
}
  • (thumbs up) Do it now
  • (question) Maybe changed in future - need to be tested

Internally decorator may connect output item which is being decorated to internal IInputItem which has exactly the same structure as output item being decorated. Then it can transform values into required output structure, which can be determined by the Arguments or consuming input item(s).

Decorator of the IOutputItem, current version introduced before meeting 22

Note, that current implementation actually does not include IInputItem inside decorator implementation, so, the question arises: where output exchange item being decorated is connected to?. It should be something compatible with it (the same element set, time set, value definition).

Decorator as a component embedded into linkable component

It can be implemented in this way using current standard, however those internal decorating components are not visible using current standard. It would be possible to access them if the following property will be added:

public interface ILinkableComponent
{
    IList<ILinkableComponent> Components { get; } 
}

Empty Sets in Input items / ElementSet changing in time

Using empty ElementSet or TimeSet in the InputItem were discussed. This discussion open problems in using of the ElementSets changing in time. See Empty Sets in the Input Items - Element set changing in time

Use Case: analytical function

See Implementation of the AnalyticalFunction use case for unit tests showing different ways to implement components

5. OATC Procedures

6. Miscellaneous issues

7. Tasks and unresolved issues

All tasks are handled by sourceForge. GOTO: OpenMI Tasks on source forge

8. Any other business

  • Check ideas mentioned in the poster of Jon Goodall:

See goodall_poster.pdf

Discussions about Times in OpenMI

Please put comments here: Discussion on times, to use or not to use standard .NET times

In the current version of the OpenMI (1.4) we use our own interfaces to implement times. A few meetings ago the idea of using standard .NET times was introduced. However we could not convince Adrian that we should switch to standard .NET times. This page is created to discuss this issue and to write down all pros / cons.
Current approach (1.4)
  public interface ITime
  {
  }

  public interface ITimeSpan : ITime
  {
      ITimeStamp Start    { get;}
      ITimeStamp End      { get; }
  }

  public interface ITimeStamp : ITime
  {
      double ModifiedJulianDay { get; }
  }
		
  public interface ITimeSet
  {
      IList<ITime> Times { get; }
      TimeZoneInfo TimeZone { get; set; }
  }
Suggested approach using standard .NET types (2.0)
  interface ITime
  {
      DateTime TimeStamp { get; set; }
      TimeSpan Duration { get; set; }
  }	
  
  public interface ITimeSet
  {
      IList<ITime> Times { get; set; }
      TimeZoneInfo TimeZone { get; set; }
  }
  • DateTime and TimeSpan in the 2nd case are from standard .NET types. Similar types are available in Java. Actually TimeSpan is missing from current standard Java 6, so we would need to use something like a long to store the duration as milliseconds.
Suggested approach using standard Java types
  public interface ITime {
      public Date getTimeStamp();
      public long getDurationMillis();
  }	

  public interface ITimeSet {
      public TimeZone getTimeZone();
      public List<ITime> getTimes();
      public Date getTimeHorizon();
  }