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

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. 
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. 
3. Question: what does isAvailable() mean in case of multiple consumers. Do all consumers need to have the same time(s)?
   1. 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. Leave as is, as definatly cannot use set as unimplemented in .NET currently.
   2. 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. Unresolved at this time, if Rob can convinve Gena then we can . 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. 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

   • 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. 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. 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:
WaitingForData status
Loop around Validate after each Update()
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)?

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

  Stef: alternative would be to add get to the IInputExchangeItem

  • get accepted,
  • set review lator
• Change ID to Id - .NET Style Guidelines, FxCop
  • , it is our intent to follow FxCop guidelines
• Add params keyword to IArguments[] args parameter in Initialize(IArgument[] args).
  •  Adrian review, if happy then ...
• Add IArguments[] Arguments { get; } to ILinkableComponent
  • 
• 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.

  • 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

  • as IOutputItem, maybe later generalise to IExchangeItem i.e. allow IInputItem
• Add WaitingForData status to the LinkableComponentStatus
  • see previous item
• Remove AddConsumer/RemoveConsumer and use BindingList in the implementation instead to listen to IOutputItem.Consumer.Add() / Remove()
  • 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)
  • Rename
  • 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
  • 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.**
  •   Review lator (today?)
• Change XYPoint+XYZPoint, ZYPolyline+XYZPolyline => Point, Polyline (make it look more like OGC entities)
  • 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; } }
  • Splitting interfaces
  • Make various interfaces derive from IIdentifiable, to review
• Make ComponentId and InstanceId properties strings - currently it is a bit overkill.
  • 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
  • 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
  • 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; }
}

• Do it now
• 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

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

• http://tortoisesvn.net/ - link to Subversion client for Standa, Johan

• 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

  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; }
  }

  interface ITime
  {
      DateTime TimeStamp { get; set; }
      TimeSpan Duration { get; set; }
  }	
  
  public interface ITimeSet
  {
      IList<ITime> Times { get; set; }
      TimeZoneInfo TimeZone { get; set; }
  }

  public interface ITime {
      public Date getTimeStamp();
      public long getDurationMillis();
  }	

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