Versions Compared

Old Version 81

changes.mady.by.user Stef Hummel

Saved on

compared with

New Version Current

changes.mady.by.user Rob Knapen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
scrollbar
See also: OATC Wiki Home
Date: June 8 - 11, 2009
 Venue:Deltares , Rotterdamseweg 185, Delft, The Netherlands
...
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 Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
~jnh@dhigroup Unknown User (jnh@dhigroup.com), DHI (jnh@dhigroup.com)
 Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
 Rob Brinkman, Deltares (rob.brinkman@deltares.nl)
 Bert Jagers, Deltares (bert.jagers@deltares.nl)
Apologies:
 Jesper Grooss, DHI (jgr@dhigroup.com)
 Jan Gregersen, LicTek, (Gregersen@LicTek.dk)
 Unknown User (moovida), Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
...
Stef experimented a bit. Two major issues to have a look at came up:
  • when to extrapolate/interpolate
  • the component needs to know which decorator is a TimeDecorator.
     See discussion in chapter 4 on decorators.
2.5 GUI
The Gui is quite on its way. To be done:
...
  • IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
     Various solutions were proposed (see below). Disadvantage of having an enumeration in the Standard is that it can not be extended easily. An object type definition would be more specific.
     Rob K. concludes that Alterra's approach works quite well for what we want. The approach is based on recognized strings in the key of the Argument.
     Action: Rob K. will provide an example.
     Done June 10: Please see the IArgumentV2.java class file that I have attached to these meeting notes. This interface documents all the extensions we made to standard OpenMI 1.2 IArgument interface to make it more usable for our (GUI related) purposes (some time ago). The comments in the source file should provide all the explanation needed (smile)
     We have studied the example and various propositions, and choose (thumbs up) for to the following solution (to be documented yet) (question) .
...
  • : 
     Code Block
...
...
  • 
    public 
...
  • interface 
...
  • IArgument : IIdentifiable, IDescribable
    {
        Type ValueType { get; }
        bool IsRequired { get; }
        bool IsReadOnly { get; }
        object Value { get; set; }
        object DefaultValue { get; }
        IList<object> GetPossibleValues();
        string Characteristics { get; }
    }

The Characteristics attribute can be used to describe requirements on or additional qualification on the argument, e.g.: "NewFile", "ExistingFile". Although understanding the characteristics is GUI-dependent, we expect that a list of generally known qualifiers will gradually arise.
The IsReadOnly attribute defines whether the Values property may be edited from outside, as in OpenMI 1.4.
 Some Oatc members think it should be removed (assuming that every argument is editable), others think it is needed.
 Stef has given two examples of 1.4. omi files where to his opinion it is needed indeed.
Adrian's proposal:
 Code Block
java
java

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

...
The result of this meeting is a candidate for the alpha release.
 In the weeks to come, every Oatc member can plead for minor adjustments. If the Oatc agrees to the adjustment, it will be incorporated in the final alpha release. The last day for these changes will be July 2 nd, because:
 (thumbs up) The alpha release will be produced on Friday July 3 th, so it can be presented on the July 4 th.
On the page Version 2.0 Alpha We will keep track of:
  • the opinions and comments on the standard
  • the results of various tests
  • etc.
5.3. External review and further migration of models
The external reviewers can start to do their work from Monday July 6 th onMonday July 6 th on.
 They will be asked to submit their remarks before September 1 st.
5.4. Migration of commercial models and documentation
...
Has not been discussed.
6. OATC Procedures
7. Miscellaneous issues
During the various discussion some things came up as may useful for, or even strongly recommened to be in version 3.0.
 We will keep track of a wish list for version 3.0.
7.1 SourceForge clean up
Recently, I checked out the entire OpenMI source forge repository. This took forever, the size of the whole repository is 4.2GB. From this, 3.8GB is located in directories called "Wrappers", which is mainly code and data from HEC, RAS, CUAHI and MODFLOW. Long time ago we made a folder on the OpenMI source forge called MyOpenSource. The idea behind this directory was to have a place where people could put some code, that did not fit into the SDK, but still could be useful for OpenMI developers. Placing an entire model, data and binary files there is in my opinion too much. It is annoying to have so long download times when checking out and it may also add to some confusion, that the OpenMI repository mainly consists of various wrappers. My suggestion is to ask those responsible for the code in the wrappers directories to make their own repositories on source forge, where after we can remove all these files from the OpenMI repository. In order to make sure that people know about these important wrapper developments we could make a page on the wiki with a short description of the various projects and link to the location of the code.
 Kind regards
 Jan Gregersen
Discussion/Conclusion: Gena will have a session with the Hec-Ras and Modflow developers at the beginning of july. Most propably their developments will be moved out of the current repository.
 Action Gena will take care that, once this is done, the OpenMI sourgeforge project will contain a reference to the Hec-Ras and Modflow developments.
 Comment by Jan: Thanks (smile)
7.2. September OATC meeting in Hamburg
...
  • Do the OATC members agree with a public talk?
  • Aim: Spreading the OpenMI in Germany
  • Target group: Developers
  • Tuesday afternoon, 9th of September
...
All tasks are handled by sourceForge. GOTO: OpenMI Tasks on source forge
They have not been reviewed at this meeting.
9. Any other business
No other business.