Page History

...

1. Question: what does isAvailable() mean in case of multiple consumers. Do all consumers need to have the same time(s)?
   Discussion/Conclusion: We decided to extend the IsAvailable() method with an IExchangeItem argument, so that the caller can specify which availability he wants to check:
   bool IsAvailable(IExchangeItem querySpecification).
   The ValueDefinition/ElementSet/TimeSet definition of the querySpecification specifies exactly what is needed.
   Generally speaking, it is on of the consumers that is passed as the argument:

...

values = providingOutputItem.GetValues(consumerThatIsAsking);

1. Remark: When experimenting with the IsAvailable(), Rob B. and Stef introduced the IExchangeDefinition (see below). Rob K. actually introduced the same interface in the java version. Indeed it is quite natural entity, the exchange definition. Question: do we want to introduce it .

   Code Block
   java java
   public interface IExchangeDefinition { IValueDefinition ValueDefinition { get; } ITimeSet TimeSet { get; } IElementSet ElementSet { get; } }

1. "string Validate()" / "bool IsValid(IExchangeItem item)" / "IsAvailable()", etc. to be reviewed at this meeting

1. Should we introduce a boolean argument that indicates whether the component should run in a pull mode (like in OpenMI 1.4) or in loop mode?
2. Discuss component operation mode here comment from Peter Gijsbers need to be discussed
3. 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'.
    

Discussion/Conclusion: We decided to let the LinkableComponent have a propery: CascadingCallsDisabled.
The default is false, indicating that the component is running in Pull Driven mode (there will be a cascade of update() calls. This Pull Driven mode has to be supported by every component.
If set to true, the component is expected to run Update()-step by Update-Step(), controlled by some outer world (which may be another component). If the component does not support this Update() by Update() way of running, it will throw an Exception when CascadingCallsDisabled = true is called;

...

1. Decorator issues:
   • Do we need to recognize the type of decorator (time, space, SI-conversion)?
   • Do we want to support 3th-party decorators indeed?
     Discussion/Conclusion: We will add an Update() method to the OutputDecorator. The linkable component calls this Update() on all its decorators at the end of its own Update(). This actually is completely the same as what happens in the current 1.4 Wrapper: after IEngine.PerformTimeStep the wrapper updates the buffers.

...

Current version:

Code Block
java java
public interface IArgument : IDescribable { string Key { get; } string Value { get; set; } bool ReadOnly { get; } }

Proposed change to cover types:

Code Block
java java
public interface IDescribable { string Caption { get; set; } string Description { get; set; } } public interface IValueDefinition : IDescribable { Type ValueType { get; } bool DescribesSameAs(IValueDefinition otherValueDefinition); } public interface IArgument : IValueDefinition { object Value { get; set; } bool ReadOnly { get; } }

...

  public interface ILinkableComponent
  {
      LinkableComponentStatus Status { get; }
            
      void Initialize();

      void Validate();

      void Update();

      void Finish();
              

      IList<IInputItem> InputItems { get; }
              
      IList<IOutputItem> OutputItems { get; }
      
      IList<IOutputDecorator> OutputDecorators { get; }

      // (another discussion) filtered data
      // get's values from the specified component
      IMatrix GetValues(IInputExchangeItem query);
      
      //    
      // when this property is set to true
      //
      // default value is false (allow cascade calls, pull-driven)
      //
      bool CascadeUpdateCallsDisabled { get; set; }        
  }

  public interface IInputItem : IExchangeItem
  {
      IMatrix Values { get; set; }
  }
    
  public interface IOutputItem : IExchangeItem
  {
      IMatrix Values { get; }
  }

  // =================================== pull approach
  
  var triggerExchangeItem = component.OutputItems[0];
  
  triggerComponent.GetValues(triggerExchangeItem);


  // =================================== loop approach
  
  while(!allComponentsAreFinished)
  {
      foreach(var component in components)
      {
          if(component.Status != LinkableComponentStatus.Finished)
          {
              component.Update();
          }
      }
  }  

  // current
  public interface IMatrix : IList
  {
      int Rows { get; }
      
      int Columns { get; }

      object GetValue(int row, int column);

      void SetValue(object value, int row, int column);
      
      object[,] GetValues(int startRow, int endRow, int startColumn, int endColumn);

      void SetValues(object[,] values, int startRow, int endRow, int startColumn, int endColumn);
  }

...

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

...

• Do the OATC members agree with a public talk?
• Aim: Spreading the OpenMI in Germany
• Target group: Developers
• Tuesday afternoon, 9th of September

Discussion/Conclusion: We all agree that indeed it will be useful to have a public session on on Tuesday afternoon on the OpenMI 2.0 developments.
The main part of the public will be java oriented, and we may not have java up and running by then, but the .Net version most probably will suffice to introduce the new concepts to the developers.
Before mid of july the OATC will confirm that indeed the public session will take place.

...