See also: OATC Wiki Home

Date: September 7 - 10, 2009
Venue:BAW, Hamburg, Germany

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

Documents:

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

Table of contents

1. Minutes from previous OATC meeting

2. Documentation (most important)

Primary about C# based on this prepare Java

2.1 Standard

Automatic using Enterprise Architect

Modified 1.4 documentation

Changes in standard from 1.4

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)

allow missing xmlns?

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

IArgument
{
  ....
  
  /// Allows UI to persist values (e.g. too/from opr file)
  /// without knowing anything about their type
  string ValueViaString { get; set; }
 
  /// 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); 
  
  /// Redundant?
  /// IsValid(...) always returns false until set
  bool IsRequired { get; }
  
  /// Redundant?
  IList<object> GetPossibleValues(); 
  
  /// Redundant?
  string Characteristics { get; }
  
  /// Does returned null mean use DefaultValue, or as I prefer
  /// Value only returns null if DefaultValue == null, as will 
  /// return DefaultValue anyway
   object Value { get; set; }
}

class IExchangeItemEventArgs
{
   IExchangeItem _exchangeItem;
   
   /// either ...
   string _information;
   
   /// .... or ...
   IDescribable[] _information;
   
   /// UI can then serve information up in a dumb way
   /// Derived classes  (in SDK not STandard) can have 
   /// additional members such as _hasElementsChanged
   /// if wanted, but keep minimal in standard
}

/// Can targetItem be null, I think it can and we should ask programmers to allow for this
/// Null 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
IIdentifiable[] GetAvailableOutputDecorators(IOutputItem decoratedItem, IInputItem targetItem);

/// Redundant?
/// Note: Combined IDescribable/IIdentifiable makes working with factories much simpler
IDescribable GetDecoratorDescription(IIdentifiable decoratorId);

/// Dont need IExchangeItemDecoratorFactory to derive from IIdentifier/IDescribable
/// as we will either have the instance or Assembly/Type info to identify it
// However, do want
static public IDescribable IExchangeItemDecoratorFactory.Describes { get; }
// So without going to the cost of creating an instance can gather
// UI information for users to choose factories

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

Sugested based on the implementation. Only if really needed !!!!!!

6 Public talk

We need to discuss extend of the meeting and more detail agenda. Our primary focus for the meeting need to be create progress especially in the version 2.0 documentation. In the week starting 24.8 we need to indicate content of the planed talks - provide to the Peter enough time to invite peoples.