Page History

See also: OATC Wiki Home

Date: November 9 - 12, 2009
Venue:BAW, Hamburg, Germany

...

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 Unknown User (don), Deltares (gennadii.donchyts@deltares.nl) Mo - Wed
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade@baw.de)
~jgr@dhigroup.com, DHI (jgr@dhigroup.com)
Jan Gregersen, LicTek on Mo (afternoon) + Tu (Gregersen@LicTek.dk)

Apologies:
~jnh@dhigroup Unknown User (jnh@dhigroup.com), DHI (jnh@dhigroup.com)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
~onnoroos Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
~moovida Unknown User (moovida), Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)

...

• 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?

Conclusion: Give warning on missing xmlns field, but still load file.

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

Conclusion: Accepted. Name may be changed to IDescriptiveIdentifier.
Conclusion after documenting the standard according to this: Not fully accepted yet.
It leads to the strange situation that the items that currently are only IDescribable and not IIdentifiable now have to provide a unique identifier.
We currently only have one interface that is IIdentifiable but not IDescribable. However, in the GUI, even a state would ppreferably have a state and/or a description, so a better suggestion might be:

Should be merged together!

IDescribable
{
  string Caption { get; set; }
  string Description { get; set }
}

IIdentifiable : IDescribable
{
  string UniqueId { get; }
}

IArgument
{
  ....

  /// 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);

  ///
  /// *Must* the argument be provided or not?
  ///
  bool IsOptional { get; }

  /// == null: not applicable
  /// != null: list of possible values (of value type)
  IList<object> GetPossibleValues();

  /// Value only returns null if DefaultValue == null, as will
  /// return DefaultValue anyway
   object Value { get; set; }

  /// Allows UI to persist values (e.g. too/from opr file)
  /// without knowing anything about their type
  string ValueAsString { get; set; }

}

...

  ILinkableComponent.Arguments[0].ValueAsString = "value for argument 0";
  ILinkableComponent.Arguments[1].ValueAsString = "value for argument 1":
  ILinkableComponent.Arguments[2].ValueAsString = "value for argument 2":
  ILinkableComponent.Initialize();

class ExchangeItemEventArgs
{
   IExchangeItem ExchangeItem;

   /// Message describing the event
   String Message { set; get; };
}

Original suggestion/remarks have been discussed and agreed upon. ExchangeItemEventArgs has been reduced to what is above.

/// (y) The targetItem can be null
/// (used 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
IDescriptiveIdentifier[] GetAvailableOutputDecorators(IOutputItem itemToDecorate, IInputItem targetItem);

/// List of factories
/// - a component may provide different type of factories:
///   . factory for time inter/extrapolation
///   . factory for spatial inter/extrapolation
///   . factory for Quantity converters: linear conversion, SI-conversions, derivatives handling, etc.
IExchangeItemDecoratorFactory[] ILinkableComponent.DecoratorFactories { get; }

Original suggestion/remarks have been discussed and agreed upon. Result is as above.
Gena will try to show by coding that a single factory is more handy. If he succeeds in showing this, we will go back to the single factory.

/// NEEDED .... or see Stefs suggestion
/// 1 requirement is needed for temporal components to allow progress % calculations
ITime ILinkableComponent.TimeHorizon (?) Will be discussed below (see [Chapter 5|#chapter5]).

			/* Exception Responsabilities
			 * Any ILinkableComponent method can throw an exception of any type
			 * Before final throw out of a ILinkableComponent method
			 *  o Change Status to Failed
			 *  o Notify any delegates of Status change
			 *  o Throw
			 *  o Does NOT call Finish, thats for the calling code as Finish
			 *    as could in turn throw an exception!
			 */

Agreed upon.
Note: there is a 'gap' when the component crashes on a runtime exception (e.g. array out of bounds), so it can not set Status == Invalid itself. We might consider let the Gui set the status to Invalid. To be studied.

/// Name change
/// Really means unadulterated cached values
/// RawValues ?
IList IOutputItem.Values { get; }

/// NEW
bool IExchangeItem.ValidTimeSet(ITimeSet iTimeSet, out IDescribable[] reasons)
bool IExchangeItem.ValidValue(IList values, out IDescribable[] reasons)

/// NEW
bool IInputItem.ValidProvider(IOutputItem iProvider, out IDescribable[] reasons)
bool IOutputItem.ValidConsumer(IExchangeItem iInputItemOrDecorator, out IDescribable[] reasons)

"RawValues": indeed we should indicate clearly in the documentation here that we are talking on the basic values, as they are in item, according to the TimeSet and the ElementSet.
Discussion on the NEW proposition: we for now leave it as a utility in the SDK. If we think we need it on the interface to support less trivial exchange items, we will introduce it in the standard.

enum should be 1,2,4,8 etc so can be bitted

					/* TODO new state in Standard WaitingForFinish
					 * Cant call finish here as might clear up resources
					 * associated with output items buggers etc.
					 * so just need to return and wait for external
					 * controller to call finish
					 *
					 * Desirable to have a new state
					 * LinkableComponentStatus.WaitingForFinish
					 * to make this clear in UI's etc.
					 *
					 * For now will use Finishing
					 */


					// TODO Note I prefer WaitingForData before Updating

...

The actual runtime situation is then presented by the current anItem.ElementSet and anItem.TimeSet, i.e.:

• anItem.ElementSet: for what location(s) are the values required (input) or available (output)
• anItem.TimeSet.Times: for what time(s) are the values required (input) or available (output)
• anItem.TimeSet.TimeHorizon:
  a. InputItem: for what time span may an input item require values (thus covering 1.4's EarliestInputTime mechanism):
  b. outputItem/decorator: in what time span can I provide values
  Additional definitions:
  . TimeSet.Times == null : time independent item
  . TimeSet.Times.Count == 0 : time dependent item, but no values available yet.
  . TimeSet.TimeHorizon == null: time independent item
  . TimeHorizon.StampAsModifiedJulianDay == Double.NegativeInfinity : far back in time
  . TimeHorizon.Duration == Double.PositiveInfinity : far in the future

Mechanism to indicate whether an output item has up to date data or not.

...