Versions Compared

Old Version 66

changes.mady.by.user Peter Schade

Saved on

compared with

New Version 67

changes.mady.by.user Stef Hummel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
scrollbar
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)
...

~jgr@dhigroup.com
...
, 
...
 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
...
 Table of Contents
1. 
...
 Minutes 
...
 from 
...
 previous 
...
 OATC 
...
meeting
2. 
...
 Documentation 
...
 (most 
...
 important)
...
Primary 
...
 about 
...
 C# 
...
 based 
...
 on 
...
 this 
...
 prepare 
...
 Java
...
2.1 
...
 Standard
...
To 
...
 produce 
...
 the 
...
 final 
...
 version 
...
 of 
...
 the 
...
 standard 
...
 the 
...
 following 
...
 steps 
...
 have 
...
 to 
...
 be 
...
 taken:
...
  • Wednesday 
...
  •  morning: 
...
  •  the 
...
  •  Oatc 
...
  •  finalizes 
...
  •  the 
...
  •  comments 
...
  •  in 
...
  •  the 
...
  •  standard
...
  • Before 
...
  •  the 
...
  •  end 
...
  •  of 
...
  •  this 
...
  •  meeting: 
...
  •  the 
...
  •  documentation 
...
  •  will 
...
  •  be 
...
  •  generated 
...
  •  from 
...
  •  the 
...
  •  code 
...
  •  (using 
...
  •  Enterprise 
...
  •  Architect)
...
  • Before 
...
  •  the 
...
  •  end 
...
  •  of 
...
  •  the 
...
  •  week, 
...
  •  Steven 
...
  •  will 
...
  •  review 
...
  •  the 
...
  •  documentation, 
...
  •  makes 
...
  •  adjustments 
...
  •  in 
...
  •  the 
...
  •  source
...
  • After 
...
  •  that, 
...
  •  the 
...
  •  documentation 
...
  •  will 
...
  •  be 
...
  •  generated 
...
  •  again, 
...
  •  and 
...
  •  will 
...
  •  be 
...
  •  provided 
...
  •  to 
...
  •  the 
...
  •  Oaec
...
  • During 
...
  •  Wednesday 
...
  •  and 
...
  •  Thursday, 
...
  •  we 
...
  •  will 
...
  •  try 
...
  •  to 
...
  •  produce 
...
  •  the 
...
  •  additional 
...
  •  documents 
...
  •  (see 
...
  •  next 
...
  •  section)
...
  • The 
...
  •  Oaec 
...
  •  will 
...
  •  meet 
...
  •  next 
...
  •  week, 
...
  •  and 
...
  •  will 
...
  •  hopefully 
...
  •  approve 
...
  •  on 
...
  •  this 
...
  •  version 
...
  •  to 
...
  •  be 
...
  •  a 
...
  •  candidate 
...
  •  for 
...
  •  review
...
To 
...
 support 
...
 the 
...
 review 
...
 process 
...
 we 
...
 will:
...
  • clearly 
...
  •  present 
...
  •  the 
...
  •  Standard, 
...
  •  the 
...
  •  current 
...
  •  version 
...
  •  of 
...
  •  the 
...
  •  SDK, 
...
  •  a 
...
  •  presentation 
...
  •  of 
...
  •  the 
...
  •  GUI, 
...
  •  and 
...
  •  the 
...
  •  documentation 
...
  •  the 
...
  •  wiki
...
  • facilitate 
...
  •  downloading/installing 
...
  •  these 
...
  •  items
...
  • ask 
...
  •  reviewers 
...
  •  to 
...
  •  sign 
...
  •  up 
...
  •  to 
...
  •  the 
...
  •  wiki 
...
  •  as 
...
  •  reviewer
...
  • indicate 
...
  •  how 
...
  •  the 
...
  •  reviewers 
...
  •  can 
...
  •  post 
...
  •  their 
...
  •  comments
...
  • organize 
...
  •  the 
...
  •  wiki 
...
  •  in 
...
  •  such 
...
  •  a 
...
  •  way 
...
  •  that 
...
  •  we 
...
  •  can 
...
  •  easily 
...
  •  keep 
...
  •  track 
...
  •  of 
...
  •  and 
...
  •  summarize 
...
  •  the 
...
  •  comments
...
Modified 
...
 1.4 
...
 documentation
...
The 
...
 1.4 
...
 document 
...
 "The 
...
 OpenMI 
...
 Standard 
...
 in 
...
 a 
...
 nutshell", 
...
 together 
...
 with 
...
 the 
...
 document 
...
 "What's 
...
 new 
...
 in 
...
 OpenMI 
...
 2.0" 
...
 is 
...
 a 
...
 good 
...
 base 
...
 for 
...
 "The 
...
 OpenMI 
...
 2.0 
...
 Standard 
...
 in 
...
 a 
...
 nutshell".
...
Jan 
...
 emphasizes 
...
 that 
...
 the 
...
 nutshell 
...
 document 
...
 is 
...
 not 
...
 enough 
...
 as 
...
 documentation. 
...
 We 
...
 should 
...
 produce 
...
 a 
...
 document 
...
 comparable 
...
 to 
...
 1.4's 
...
 "Part 
...
 C 
...
 - 
...
 the 
...
 org.OpenMI.Standard 
...
 interface 
...
 specification", 
...
 maybe 
...
 a 
...
 bit 
...
 less 
...
 intensive.
...

 We 
...
 will 
...
 do 
...
 our 
...
 utmost 
...
 to 
...
 produce 
...
 such 
...
 a 
...
 document 
...
 next 
...
 week. 
...
 Documentation 
...
 that 
...
 needs 
...
 update 
...
 (prioritized):
...
  • Comments 
...
  •  to 
...
  •  the 
...
  •  source 
...
  •  code, 
...
  •  Standard 
...
  •  only 
...
  •  (Stef)
...
  • What 
...
  •  is 
...
  •  new 
...
  •  in 
...
  •  OpenMI 
...
  •  2.0? 
...
  •  First 
...
  •  version 
...
  •  in 
...
  •  trunk/doc. 
...
  •  (Stef)
...
  • How 
...
  •  to 
...
  •  migrate 
...
  •  from 
...
  •  1.4 
...
  •  (Jesper)
...
  • UML diagrams, 
...
  •  conceptual 
...
  •  diagrams 
...
  •  of 
...
  •  2.0. 
...
  •  (Gena)
...
  • 1.4's 
...
  •  "Part 
...
  •  C, 
...
  •  Interface 
...
  •  specification" 
...
  •  document 
...
  •  (all 
...
  •  - 
...
  •  we 
...
  •  take 
...
  •  a 
...
  •  first 
...
  •  look 
...
  •  thursday 
...
  •  morning) 
...
    • What 
...
    •  to 
...
    •  take 
...
    •  out, 
...
    •  rewrite, 
...
    •  update. 
...
    •  Less 
...
    •  comprehensive 
...
    •  than 
...
    •  1.4.
...
  • UI 
...
  •  help 
...
  •  document 
...
  •  (Adrian)
...
  • Howto 
...
  •  document 
...
  •  (Getting 
...
  •  Started) 
...
  •  on 
...
  •  the 
...
  •  web. 
...
  •  (Peter) 
...
    • Create 
...
    •  skeleton.
...
  • 1.4's 
...
  •  "Part 
...
  •  A, 
...
  •  Scope" 
...
  •  document
...
  • 1.4's 
...
  •  "Part 
...
  •  B, 
...
  •  Guidelines" 
...
  •  document
...
  • The 
...
  •  OpenMI 
...
  •  2.0 
...
  •  Standard 
...
  •  in 
...
  •  a 
...
  •  nutshell
...
  • The 
...
  •  paper 
...
  •  presented 
...
  •  in 
...
  •  JoH 
...
  •  (Gregersen, 
...
  •  Gijsbers, 
...
  •  Westen). 
...
  •  We 
...
  •  must 
...
  •  take 
...
  •  care 
...
  •  of 
...
  •  copy 
...
  •  right 
...
  •  issues 
...
  •  here.
...
  • The 
...
  •  Tuesday 
...
  •  afternoon 
...
  •  presentations
...
  • The 
...
  •  minutes 
...
  •  in 
...
  •  of 
...
  •  the 
...
  •  Oatc 
...
  •  meetings
...
  • Scope 
...
  •  document 
...
  •  about 
...
  •  the 
...
  •  OpenMI. 
...
  •  Look 
...
  •  at 
...
  •  the 
...
  •  1.4 
...
  •  scope 
...
  •  document.
...
  • SDK 
...
  •  documentation 
...
  •  (SDK 
...
  •  namespaces/organization). 
...
  •  As 
...
  •  class 
...
  •  library?
...
Tasks:
...
  • Standa: 
...
    • Make 
...
    •  the 
...
    •  sequence 
...
    •  diagrams 
...
    •  available 
...
    •  in 
...
    •  Enterprise 
...
    •  Architect
...
    • Gather 
...
    •  the 
...
    •  sources. 
...
    •  If 
...
    •  they 
...
    •  can 
...
    •  not 
...
    •  be 
...
    •  found, 
...
    •  Standa 
...
    •  will 
...
    •  let 
...
    •  a 
...
    •  tool 
...
    •  generate 
...
    •  Word 
...
    •  documents 
...
    •  from 
...
    •  the 
...
    •  relevant 
...
    •  pdf's
...
  • Adrian: 
...
    • Make 
...
    •  a 
...
    •  document 
...
    •  presenting 
...
    •  the 
...
    •  GUI 
...
    •  (
...
    • done 
...
    •  by
...
    • : 
...
    •  realized 
...
    •  during 
...
    •  meeting
...
    • )
...
    • Produce 
...
    •  a 
...
    •  help 
...
    •  document, 
...
    •  with 
...
    •  2 
...
    •  turials 
...
    •  in 
...
    •  (the 
...
    •  tutorials 
...
    •  will 
...
    •  also 
...
    •  be 
...
    •  put 
...
    •  on 
...
    •  the 
...
    •  "what 
...
    •  is 
...
    •  OpenMI" 
...
    •  documentation 
...
    •  page. 
...
    •  (
...
    • done 
...
    • by: end of November)
    • Update compliancy xsd for review at next OATC meeting
  • Stef: 
    • Documententation in the Standard: (done by: realized during meeting)
  • Jesper: 
    • How to migrate (done by: first version realized during meeting)
Structure of the 2.0 documentation web-pages
  • What is OpenMI 
    • 1 minute tutorial
    • 10 minute tutorial
    • Scope document
  • Whats new in 2.0
  • OpenMI 2.0 Standard specifications 
    • Standard Reference manual (class library)
  • SDK Developer guide/documentation 
    • SDK Reference manual (class library)
  • GUI user manual 
    • GUI Reference manual (class library)
  • How to 
    • How to Migrate from 1.4
    • How to migrate existing Fortran based models codes
    • How to work with OMI files
    • How to connect OpenMI components via interface calls
    • How to link to Excel
    • How to turn an Ascii file reader into a Linkable Component
    • How to turn a database into a LinkableComponent
    • How to make linking of models with different grids possible.
    • How to get the most recent source code for the GUI and SDK
    • How to get started with OpenMI and Java
    • How to port the OpenMI from Windows to Linux
    • How to generate a LinkableComponent with a Fortran engine on Linux
  • Review of 2.0 standard (restricted access)
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)
 Code Block
titleSTANDARD SUGGESTIONS: OMI XML
borderStylesolid
 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)

{code:title=STANDARD SUGGESTIONS: OMI XML|borderStyle=solid}
allow missing xmlns?
{code}


Conclusion: 
...
 (thumbs up) Give 
...
 warning 
...
 on 
...
 missing 
...
 xmlns 
...
 field, 
...
 but 
...
 still 
...
 load 
...
 file.


{:=   | =
 Code Block
title
STANDARD 
 SUGGESTIONS: 
 IIdentifier/IDescribable
borderStyle
solid
}
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 }
}
{code}


Conclusion: 
...
 (thumbs up) Accepted. 
...
 Name 
...
 may 
...
 be 
...
 changed 
...
 to 
...
 IDescriptiveIdentifier.
 (warning) 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:
 Code Block
titleADJUSTED STANDARD SUGGESTION: IIdentifiable/IDescribable
borderStylesolid

(!) 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:

{code:title=ADJUSTED STANDARD SUGGESTION: IIdentifiable/IDescribable | borderStyle=solid}
Should be merged together!

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

IIdentifiable : IDescribable
{
  string UniqueId { get; }
}


 Code Block
titleSTANDARD SUGGESTIONS: IArgument
borderStylesolid
{code}

{code:title=STANDARD SUGGESTIONS: IArgument|borderStyle=solid}
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; }

}
{code}


Conclusions:
 (thumbs up) We agree that that we need a method access the value as an argument with a string. (Pictured above as ValueAsString.
 (warning) Gena will check other standards on the naming of this property or method.
 (thumbs up) We agree that the opr file will store the Assembly.Class info for a model instance, as well as the arguments that are used for that instance
 (thumbs up) Initialize call will let the component try to initialize itself. If the component does not succeed to initialize, it sets it state to Failed and throws an exception. The exception text will contain a clear message indicating what went wrong.
 (thumbs up) characteristics should be placed in Description. Together with IArgument.ValueType this provides enough information to know what type of arguments should be provided.
 (thumbs up) The Initialization of the Linkable Component will be split in first setting the arguments, and then initializing the model, see below. Please not that each argument key can appear in the list only once:
 Code Block

(y) We agree that that we need a method access the value as an argument with a string. (Pictured above as {{ValueAsString}}.
(!) Gena will check other standards on the naming of this property or method.
(y) We agree that the opr file will store the Assembly.Class info for a model instance, as well as the arguments that are used for that instance
(y) Initialize call will let the component try to initialize itself. If the component does not succeed to initialize, it sets it state to *{_}Failed{_}* and throws an exception. The exception text will contain a clear message indicating what went wrong.
(y) characteristics should be placed in {{Description}}. Together with {{IArgument.ValueType}} this provides enough information to know what type of arguments should be provided.
(y) The Initialization of the Linkable Component will be split in first setting the arguments, and then initializing the model, see below. Please not that each argument key can appear in the list only once:
{code}
  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();
{code}

{
 Code Block
titleSTANDARD SUGGESTIONS: ExchangeItemEventArgs
borderStylesolid
code:title=STANDARD SUGGESTIONS: ExchangeItemEventArgs|borderStyle=solid}
class ExchangeItemEventArgs
{
   IExchangeItem ExchangeItem;

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

(y) Original 
(thumbs up) Original suggestion/remarks 
...
 have 
...
 been 
...
 discussed 
...
 and 
...
 agreed 
...
 upon. 
...
 ExchangeItemEventArgs 
...
 has 
...
 been 
...
 reduced 
...
 to 
...
 what 
...
 is 
...
 above.


{:=  |=
 Code Block
title
STANDARD 
 SUGGESTIONS: 
 IExchangeItemDecoratorFactory
borderStyle
solid
}
/// (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; }

{code}

(y) Original 
(thumbs up) Original suggestion/remarks 
...
 have 
...
 been 
...
 discussed 
...
 and 
...
 agreed 
...
 upon. 
...
 Result 
...
 is 
...
 as 
...
 above.
 (warning) 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.
 Code Block
titleSTANDARD SUGGESTIONS: ILinkableComponent
borderStylesolid

(!) 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.

{code:title=STANDARD SUGGESTIONS: ILinkableComponent|borderStyle=solid}
/// 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!
			 */
{code}

(y) Agreed upon.
(?) Note: there is a 
(thumbs up) Agreed upon.
 (question) 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.



{code:title=STANDARD  |=
 Code Block
titleSTANDARD 
 SUGGESTIONS: 
 IExchangeItem
borderStyle
solid
}
/// 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)

{code}

(y) "_RawValues_
(thumbs up) "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.
 (thumbs down) 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.
 Code Block
titleSTANDARD SUGGESTIONS: LinkableComponentStatus
borderStylesolid

(n) 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.

{code:title=STANDARD SUGGESTIONS: LinkableComponentStatus|borderStyle=solid}
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
{code}

(y) *{_}enum should be 
(thumbs up) enum should be 1,2,4,8
...
: 
...
Agreed
 (thumbs up) WaitingForFinish: Agreed, however: we will call it LinkableComponentStatus.Done(thumbs up) WaitingForData before Updating: Agreed. Related to this:
 (thumbs up) The IOutputItem will be extended with a property:
IOutputItem.IsLocked;}}This 
...
 flag 
...
 will 
...
 be 
...
 set 
...
 to 
...
 {{true
...
 for 
...
 each 
...
 output 
...
 item 
...
 that 
...
 the 
...
 linkable 
...
 component 
...
 is 
...
 producing 
...
 output 
...
 for. 
...
 It 
...
 will 
...
 be 
...
 set 
...
 to 
...
false
...
 as 
...
 soon 
...
 as 
...
 the 
...
 output 
...
 is 
...
 computed.
...

 The 
...
 flag 
...
 serves 
...
 mainly 
...
 the 
...
 loop 
...
 approach, 
...
 but 
...
 it 
...
 may 
...
 also 
...
 be 
...
 beneficial 
...
 in 
...
 case 
...
 of 
...
 bidirectional 
...
 links 
...
 in 
...
 the 
...
 pull 
...
 approach.
...
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
 Anchor
chapter5
chapter5
5 Necessary changes to the Standard
Suggestions based on the implementation. Only if really needed !!!!!!
Additional status for LinkableComponent.Status
The status 'computation done, but not yet finishing' can not be speficied. This occurs when one component in a composition is done, while others are not. The deployer will call Finish when all components are done. Suggestion: add the status WaitingForFinish.
 (thumbs up) Has been discussed, see above (LinkableComponentStatus.Done).
IOutputItem.Decorators
During a plenary Skype meeting one of the questions was whether the list of added decorators should be public or not (see). During the discussion it was suggested to put the list of decorators not on ILinkableComponent, but on IOutputItem. This indeed is very useful, because then the
 IList<IOutputItemDecorator> IOutputItem.Decoratorsproperty facilitates update the decorators in the right order.
 (thumbs up) We will indeed add this list to the IOutputItem.
 The AddDecorator and RemoveDecorator methods from the LinkableComponent will be removed.
Time Horizon / Spatial domain (back) on ILinkableComponent
We removed TimeHorizon from ILinkableComponent. However, configuration time it still would be handy, as well as run time, to display a progress bar.
 Of course, there now is IExchangeItem.TimeSet.TimeHorizon, but the TODO in the documentation of ITimeSet.TimeHorizon shows that one could easily (and most probably would preferably) explain this as the time horizon of the available resp. required time.
 However, exactly the same can be said for the spatial domain 'horizon' of a component. Where can the component do its work, where are things available or required.
 (thumbs up) To handle part the issues mentioned above, we in 2.0 introduce:
 ITimeSet ILinkableComponent.TimeExtent(thumbs down) For symmetry, we would like to have SpatialExtend too, but we have no clear insight in the actual usage and consequences, so we will put on the wish list for 3.0 something like:
 IElementSet IOutputItem.SpatialExtent
(thumbs up) 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.
This mechanism, e.g. a flag needsUpdate (the inverse of what was once introduced as isAvailable) is needed for the loop driven approach. However, it is also useful for optimization in the pull driven approach. If nothing has been changed at the providing side, the previous values can be used.
 To be discussed at the meeting.
IQuality / ICategory
(thumbs up) For consistency the ICategory.Values will be changed to type object instead of string, unless Rob K. has arguments that this is wrong
 (thumbs down) It was suggested to make ICategory extend IEquatable, but this has been rejected (no .Net specific items in the standard).
IValueSet instead of IList
(thumbs up) We agreed that we introduce the IValueSet. It will be proposed as below. During the review phase however, we will clearly state that it is a first suggestions, and that any remark very welcome.
 Code Block



{anchor:chapter5}

h1. 5	Necessary changes to the Standard

Suggestions based on the implementation. Only if really needed \!\!\!\!\!\!

h2. Additional status for LinkableComponent.Status

The status 'computation done, but not yet finishing' can not be speficied. This occurs when one component in a composition is done, while others are not. The deployer will call Finish when all components are done. Suggestion: add the status *{_}WaitingForFinish{_}*.
(y) Has been discussed, see above (LinkableComponentStatus.Done).

h2. IOutputItem.Decorators

During a plenary Skype meeting one of the questions was whether the list of added decorators should be public or not (see). During the discussion it was suggested to put the list of decorators not on ILinkableComponent, but on IOutputItem. This indeed is very useful, because then the
{{IList<IOutputItemDecorator> IOutputItem.Decorators{}}}property facilitates update the decorators in the right order.
(y) We will indeed add this list to the IOutputItem.
The {{AddDecorator}} and {{RemoveDecorator}} methods from the LinkableComponent will be removed.

h2. Time Horizon / Spatial domain (back) on ILinkableComponent

We removed TimeHorizon from ILinkableComponent. However, configuration time it still would be handy, as well as run time, to display a progress bar.
Of course, there now is IExchangeItem.TimeSet.TimeHorizon, but the TODO in the documentation of ITimeSet.TimeHorizon shows that one could easily (and most probably would preferably) explain this as the time horizon of the available resp. required time.
However, exactly the same can be said for the spatial domain 'horizon' of a component. Where can the component do its work, where are things available or required.

 (y) To handle part the issues mentioned above, we in 2.0 introduce:
{{ITimeSet ILinkableComponent.TimeExtent}}(n) For symmetry, we would like to have SpatialExtend too, but we have no clear insight in the actual usage and consequences, so we will put on the wish list for 3.0 something like:
{{IElementSet IOutputItem.SpatialExtent}}

(y) 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

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

This mechanism, e.g. a flag needsUpdate (the inverse of what was once introduced as isAvailable) is needed for the loop driven approach. However, it is also useful for optimization in the pull driven approach. If nothing has been changed at the providing side, the previous values can be used.
To be discussed at the meeting.

h2. IQuality / ICategory

(y) For consistency the ICategory.Values will be changed to type {{object}} instead of {{string}}, unless Rob K. has arguments that this is wrong
(n) It was suggested to make {{ICategory}} extend {{IEquatable}}, but this has been rejected (no .Net specific items in the standard).

h2. IValueSet instead of IList

(y) We agreed that we introduce the IValueSet. It will be proposed as below. During the review phase however, we will clearly state that it is a first suggestions, and that any remark very welcome.

public interface IValueSet
{
      IList<IList> Values2D { get; set; }

      bool PreferedOrderIsElements { get; }

      object GetValue(int time, int element);
      void SetValue(object value, int time, int element);

      IList GetTimeSeriesValuesForElement(int elementIndex);
      void SetTimeSeriesValuesForElement(IEnumerable values, int elementIndex);

      IList GetElementValuesForTime(int timeIndex);
      void SetElementValuesForTime(IEnumerable values, int timeIndex);
}

add generic version of IInputExchangeItem, IOutputExchangeItem, IValueSet
(thumbs down) We tend to include a generic version of interfaces like IInputExchangeItem, IOutputExchangeItem, IValueSet (see examples below). However: we should either introduce Generics as fully supported and elaborated concept, including the java version, or leave it out for now. Given the stage of the project, we chose the latter.
 Code Block
{code}


h2. add generic version of IInputExchangeItem, IOutputExchangeItem, IValueSet

(n) We tend to include a generic version of interfaces like IInputExchangeItem, IOutputExchangeItem, IValueSet (see examples below). However: we should either introduce Generics as fully supported and elaborated concept, including the java version, or leave it out for now. Given the stage of the project, we chose the latter.

{code}
public interface IInputExchangeItem<T>: IInputExchangeItem
{
    IValueSet<T> { get; set; }
    ...
}


public interface IOutputExchangeItem<T>: IOutputExchangeItem
{
    IValueSet<T> { get; set; }
    ...
}

public interface IValueSet<T>: IValueSet
{
      IList<IList<T>> Values2D { get; set; }

      bool PreferedOrderIsTime { get; set; }

      T GetValue(int time, int element);
      void SetValue(T value, int time, int element);

      IList<T> GetTimeSeriesValuesForElement(int elementIndex);
      void SetTimeSeriesValuesForElement(IEnumerable<T> values, int elementIndex);

      IList<T> GetElementValuesForTime(int timeIndex);
      void SetElementValuesForTime(IEnumerable<T> values, int timeIndex);
}
{code}


h1. 6 Public talk

The public talk by the Oatc was visited by the OAEC and by about ten external participants. 

The [program|^OpenMI_2_0_Programme.pdf] and the presentations are available here:
* The potential of Integrated Modelling and the OpenMI: [Powerpoint 2003 presentation|^OpenMI_2_Hamburk.pps]
* Java use cases of OpenMI compliant JGrass components: [Powerpoint 2003 presentation|^JavaUseCase_JGrass.ppt]
* OpenMI goes Linix: [PDF|^OpenMIGoesLinux.pps]
* From OpenMI Standard 1.4 to 2.0: [Powerpoint Show|^FromOpenMI14_to20.pps] (presentation can be retrieved from [~hummel] or [~peter_schade])
* Design of OpenMI 2.0 :[Powerpoint 2007 Presentation|^OpenMI 2.0 Design.pptx]
* Migration of models from 1.4 to 2.0 :[PDF|^OpenMI_Wrapping_1.4_In_2.0.pdf], [Powerpoint 2007 Presentation|^OpenMI_Wrapping_1.4_In_2.0.pptx]
* Comparison between Editor v.1 and v.2 :[PDF|^EditorComparisonV1V2.pdf]

Comments from the meeting:
* Optimized Get/Set value compared to 1.4 is good - no need for dictionaries of linkId's, quantityId's and ElementSetId's
* General return type of exchangeItem allows for a specialized set of quantities in one exchange item.
** Do we need further support for this in the Standard? Could be an extension to the released version.
* GUI - how to change the arguments of a decorator? Is there already\!
* What is the difference between the link and the provider-consumer relation? We have to be very explicit in the documentation there.
* Clarify the "locationSpecification" term from the presentation.
* Nice to see events in the standard.

* Generic version of standard
** Make a OpenMI.Standard.Generic namespace and put it there?
* Fully 1.4 wrapping into 2.0.
** Changing namespace will make things easier - OpenMI.Standard2. Though probably not a strong enough argument for changing the standard namespace.
* GUI - Displaying values of exchangeitems/monitoring the change of values.
* How to link a java and a .NET LinkableComponent?
** Possible to do this through some standard communication framework.
** RabbitMQ - spring.NET - others exists as well.

h1. 7 Version 3 Wish List

* Support of super computing and parallel computing
** OpenMP, MPI, ...??
* C+\+ version of standard
* JAVA/.NET interoperability
** Allowing cross platform OS (Linux/Windows)
* Version 2 makes some features possible, but realistic examples need to be developed and tested
** Dynamic changes of ElementSets
** Datasases
** WebServices
* Interoperability with other standards
** OGC, .... ???
** US frameworks?
* Tools to support 3D models
** Interpolation, buffering, ...
* Improved UI to improve introduction of public to technology and its possibilities
** PlugIns, Google Maps, ....??
* Consistent use of generics in standard

h1. 8 Some pictures

{gallery:title=Some pictures, taken during the four days of the meeting|columns=3}
{gallery}
6 Public talk
The public talk by the Oatc was visited by the OAEC and by about ten external participants. 
The program and the presentations are available here:
Comments from the meeting:
  • Optimized Get/Set value compared to 1.4 is good - no need for dictionaries of linkId's, quantityId's and ElementSetId's
  • General return type of exchangeItem allows for a specialized set of quantities in one exchange item. 
    • Do we need further support for this in the Standard? Could be an extension to the released version.
  • GUI - how to change the arguments of a decorator? Is there already!
  • What is the difference between the link and the provider-consumer relation? We have to be very explicit in the documentation there.
  • Clarify the "locationSpecification" term from the presentation.
  • Nice to see events in the standard.
  • Generic version of standard 
    • Make a OpenMI.Standard.Generic namespace and put it there?
  • Fully 1.4 wrapping into 2.0. 
    • Changing namespace will make things easier - OpenMI.Standard2. Though probably not a strong enough argument for changing the standard namespace.
  • GUI - Displaying values of exchangeitems/monitoring the change of values.
  • How to link a java and a .NET LinkableComponent? 
    • Possible to do this through some standard communication framework.
    • RabbitMQ - spring.NET - others exists as well.
7 Version 3 Wish List
  • Support of super computing and parallel computing 
    • OpenMP, MPI, ...??
  • C++ version of standard
  • JAVA/.NET interoperability 
    • Allowing cross platform OS (Linux/Windows)
  • Version 2 makes some features possible, but realistic examples need to be developed and tested 
    • Dynamic changes of ElementSets
    • Datasases
    • WebServices
  • Interoperability with other standards 
    • OGC, .... ???
    • US frameworks?
  • Tools to support 3D models 
    • Interpolation, buffering, ...
  • Improved UI to improve introduction of public to technology and its possibilities 
    • PlugIns, Google Maps, ....??
  • Consistent use of generics in standard
8 Some pictures
 Gallery
columns3
titleSome pictures, taken during the four days of the meeting