Participants:

Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don, Deltares (gennadii.donchyts@deltares.nl)
~jnh@dhigroup.com Johan Hartnack , DHI (jnh@dhigroup.com)

Apologies:
Jesper Grooss, DHI (jgr@dhigroup.com)

Documents:

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

agenda

1. Minutes from previous OATC meeting

1.1 Status of the Linux test

1.2 Release 1.4.1

1.3 www.OpenMI.org and wiki.OpenMI.org

2. Status of the implementation .NET

2.1 Changest to the standard

2.2 Backbone

2.3 Buffer

2.4 Time interpolation Decorator

2.5 GUI

2.6 SimpleRiver Model - running in GUI

2.7 OpenMI 2.0 wrapper around OpenMI 1.4 Components

Status of the Java implementation

3.2 Pending Remarks on Standard as result of Java review

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:

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);
2. Will be discussed later during the meeting, Stef will show an example of using isAvailable(whosAsking);
Question: Collection or Set instead of List for (In|Out)putExchangeItems in LC?
1. It will be ICollection .
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)
1. Gena has discussed with Rob between last and current meeting. After some discussion the final result is described on: Suggestion about changed to state management
To be discussed: Introduce generics in IOutputItem.Values()? i.e. weakly typed via <T>
1. We will not introduce generics in the standard. However, they could be used in the SDK.
Remark: Working with providers/consumers, we should take care that such a circularity might give garbage collection problems. After a short discussion, we see no real general way so solve this risk, so it has been decided that we should leave this up to the Garbage Collector.
- Point noted, no specific agreement as to solution
We will introduce something like OpenMIException : Exception. However, first we will have a detailed look at the guidelines for introducing custom exceptions in both .Net and Java. Rob K. has added a page for this, Guidelines for introducing custom exceptions. It now includes Java suggestions, Gena will add .Net suggestions.

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.

3.5 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)?
Move Values { get; set; } to IExchangeItem?
- get; set; to be reviewed at this meeting
  
  When discussing get/set, the subject of the discussion graduallly moved to the pull versus loop driven approach. This led to an important decision : We will 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
Add params keyword to IArguments[] args parameter in Initialize(IArgument[] args).
- Adrian review, if happy then ...
"string Validate()" / "bool IsValid(IExchangeItem item)" / "IsAvailable()", etc.
- to be reviewed at this meeting
Add "params IOutputItem[] items" argument to Update() in order to specify explicitly what should be updated.
- Maybe generalise to IExchangeItem i.e. allow IInputItem?
Remove AddConsumer/RemoveConsumer and use BindingList in the implementation instead to listen to IOutputItem.Consumer.Add() / Remove()
We will leave AddConsumer/RemoveConsumer for now. The BindingList mechanism has been implemented, though, so anyone can use it
When we get loops in the compositions - we have to tell which component will be first! In the new GUI, we will let the user indicate the 'Start up component'.
Add Durations, TimeZone properties to ITimeSet? (see also changes from Rob in Java version)
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.
- all time issues will be discussed at this meeting
Change XYPoint+XYZPoint, ZYPolyline+XYZPolyline => Point, Polyline (make it look more like OGC entities)
- Reviewed: OGC approach to see how we know when a Z coordinate exists:
  IElementSet.SpatialReferenceWkt contains Z (vertical reference) and M systems, see http://en.wikipedia.org/wiki/Well-known_text.
- To get the M-coordinate, a method should be added:
```
        ...
        double GetVertexMCoordinate(int elementIndex, int vertexIndex);
        ...

        // proposal:
        // the four methods could be replaced with this:
        public enum SpatialDimension { X, Y, Z, M }
        public double getVertexCoordinate(int elementIndex, int vertexIndex, SpatialDimension dim);
```

IIdentity has been split in IIdentifiable and IDescribable. Some interfaces already have been derived from IIdentifiable and/or IDescribable** At some stage, we should check all interfaces on whether to derive from IIdentifiable and/or IDescribable or not.
- At this meeting, we have checked that IIdentifiable and/or IDescribable are not used as seperate entities.

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's proposal is below

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

Child pages

Participants:

Documents:

Table of contents

agenda

1. Minutes from previous OATC meeting

1.1 Status of the Linux test

1.2 Release 1.4.1

1.3 www.OpenMI.org and wiki.OpenMI.org

2. Status of the implementation .NET

2.1 Changest to the standard

2.2 Backbone

2.3 Buffer

2.4 Time interpolation Decorator

2.5 GUI

2.6 SimpleRiver Model - running in GUI

2.7 OpenMI 2.0 wrapper around OpenMI 1.4 Components

Status of the Java implementation

3.2 Pending Remarks on Standard as result of Java review

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

3.5 More suggestions on v2.0 changes

5. OATC Procedures

7. Miscellaneous issues

8. Tasks and unresolved issues

9. Any other business

Child pages

OpenMI Association Technical Committee meeting no 24

Participants:

Documents:

Table of contents

agenda

1. Minutes from previous OATC meeting

1.1 Status of the Linux test

1.2 Release 1.4.1

1.3 www.OpenMI.org and wiki.OpenMI.org

2. Status of the implementation .NET

2.1 Changest to the standard

2.2 Backbone

2.3 Buffer

2.4 Time interpolation Decorator

2.5 GUI

2.6 SimpleRiver Model - running in GUI

2.7 OpenMI 2.0 wrapper around OpenMI 1.4 Components

Status of the Java implementation

3.2 Pending Remarks on Standard as result of Java review

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

3.5 More suggestions on v2.0 changes

5. OATC Procedures

7. Miscellaneous issues

8. Tasks and unresolved issues

9. Any other business