Give warning on missing xmlns field, but still load file.
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)
Unknown User (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:
Unknown User (jnh@dhigroup.com), DHI (jnh@dhigroup.com)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Unknown User (moovida), Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org
Primary about C# based on this prepare Java
To produce the final version of the standard the following steps have to be taken:
To support the review process we will:
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):
Tasks:
Progress as of 26/08/09
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; }
}
|
Conclusions:
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.
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
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.
characteristics should be placed in Description. Together with IArgument.ValueType this provides enough information to know what type of arguments should be provided.
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:
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 |
enum should be 1,2,4,8: Agreed
WaitingForFinish: Agreed, however: we will call it LinkableComponentStatus.Done WaitingForData before Updating: Agreed. Related to this:
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.
Suggestions based on the implementation. Only if really needed !!!!!!
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.
Has been discussed, see above (LinkableComponentStatus.Done).
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.
We will indeed add this list to the IOutputItem.
The AddDecorator and RemoveDecorator methods from the LinkableComponent will be removed.
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.
To handle part the issues mentioned above, we in 2.0 introduce:
ITimeSet ILinkableComponent.TimeExtent 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
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:TimeSet.Times == null : time independent itemTimeSet.Times.Count == 0 : time dependent item, but no values available yet.TimeSet.TimeHorizon == null: time independent itemTimeHorizon.StampAsModifiedJulianDay == Double.NegativeInfinity : far back in timeTimeHorizon.Duration == Double.PositiveInfinity : far in the futureThis 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.
For consistency the ICategory.Values will be changed to type object instead of string, unless Rob K. has arguments that this is wrong
It was suggested to make ICategory extend IEquatable, but this has been rejected (no .Net specific items in the standard).
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);
}
|
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.
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);
}
|
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: