In the GUI, the models run to the latest overlapping date/time. If this date is, say, the 7th January 2000, then the models will not actually reach the 7th January, they run to the timestep just before 7th January. I think it would be more logical for the models to run to, and including, the end time. What does anyone else think?
RE: Latest Overlapping Date/Time
By: Rob Knapen (rknapen) - 2006-12-05 14:09 
I think that from the outside (the GUI) you should only see the request to a linkable component for a specific date. It is up to the inner workings of the component how best to answer the request. Perhaps no time steps are used or time steps are very long. And perhaps it is OK for the model to stop one time step short of the requested date. The model specific tracing / logging information however should clearly indicate how the requested data has been calculated. 
However yes, if the linkable component uses an engine that is driven by time steps, most likely the component will do a performTimeStep call until the engine's currentTime is the same as or exceeds the requested time.

To represent dimensions as text it would convenient to add the symbols to the DimensionBase enumeration.

In some domains where we want to use OpenMI it is very common to work with grid based (spatial) data. It is rather awkward to represent this in the current available ElementSet. In general the information that the data represents a grid is lost and there is no way to optimize processing anymore. Preferably ElementTypes for grid cells are added together with methods for handling grid data. This could be done in a IGridElementSet interface that inherits from IElementSet.

To group linkable components introduce a LinkableComponentGroup class (in the backbone). This class implements the ILinkableComponent interface, but internally can contain a number of ILinkableComponents and ILinks. Further nesting is possible. A Composition then can be implemented as a specific form of a LinkableComponentGroup. Groups are handy to re-use (parts) of compositions and for user interface representation. The Java org.openmi.alterra.configuration package contains an implementation of this.

For persistency a specification should be added for representing the state of an Argument in a string, and to restore it from a string. For example it can be: a key-value list with "=" as separator between key and value, and ";" to separate the pairs. Together with a list of standard key names.

The Argument class should be extended with some additional properties (required, possible values, argument type) to allow for automatic processing and constructing (input) GUI widgets for them. Currently the contents of an argument is to unstructured to do this.

A method added to the LinkableComponent to request the list of initialization arguments (e.g. getInitialisationArguments()) would be convenient. Currently there is no way for an application to find out what arguments a component needs. It can only be provided by documentation, or by an additional (non OpenMI) interface.

To be able to use OpenMI in other domains there is a large request to support qualitative data (besides the current quantitative data). To implement this a parent interface (IDataType) could be introduced, which specifies into the IQuantity and IQuality interfaces. I have a Java sample implementation of this, for those interested. If possible it should be included into the (next) specification.

Jeremy from WRc requested that an image be displayed on the models when they load up in the GUI to make them more identifiable.
RE: To display an image on the model
By: Jan Gregersen (jan_gregersen) - 2006-08-07 04:48 
I think this would be a nice feature, since the visual appearance of a OpenMI configuration can pretty messy in the graphical view of the OpenMI configuration editor (OmiED). However, including such feature would require changes to the OpenMI standard (the OmiED needs a standardized way to request the image to show). Therefore I think we should conceder this feature for OpenMI version 2.0

There is no copy and paste functionality in the datamonitor at the moment. It would be useful for copying the data from the DataMonitor and pasting it into Excel for data analysis

Please may I request that the latest overlapping time control in the GUI show the date/time format depending on the user-culture, for instance, in the UK we use dd/mm/yyyy but in the US they use mm/dd/yyyy. At the moment the GUI always shows the date/time the US way which can be a bit confusing for us! 

Can the datamonitor be part of the standard install - at the moment you could get hold of it by doing a build of the source code but this is not really practical for non-programmers. Two files would need to be installed - org.OpenMI.Tools.DataMonitor.dll and datamonitor.omi

Dear members of the OpenMI Association
In the project proposal of the OpenMI LIFE project, there is stated in form T2a for task B at paragraph 2 Trial integrated modelling that the (linked) models (shall be) running on different platforms and on different machines.
The Scheldt partners are interpreting this as each model running on its own platform, thus on its own location ; the link shall be created by Internet data or communication exchange on line. 
As the runs of linked models shall spend many hours, even more than one day time, the Scheldt partners believe this way of working shall not be successfull, and thus not reliable, because of a too high risk of communication failure.
The proposal of the Scheldt partners is to organise a hardware environment with linked multiprocessors on one location instead of to organise the adaption of existing hardware environments (for each model) on different locations.
Which is the point of view of the OpenMI Association about this matter ?
RE: Possibilities of hardware environment
By: Jan Gregersen (jan_gregersen) - 2006-11-29 01:47 
The current version of OpenMI (version 1.*) requires that all LinkableComponents are running in one thread and on one machine. However, you can implement your LinkableComponent is such a way that it internally communicates with your calculating engine that is located on a different machine. The advantages of not including such communication protocols into the OpenMI standard is that choice of protocol for communication between processes or machines can be made based on what is optimal for your particular model. Practically, seen from the users perspective, all LinkableComponents that are part of a OpenMI configuration are installed on the local machine, and the user does not have to worry about that one of more of these components internally exchange data with their calculation engines e.g. over the internet. These special types of LinkableComponents can be very small in size, since they only act as proxy's for the real models. People that are migrating models to comply with the OpenMI standard are typically using the OpenMI wrapper utilities package, which makes the migration much easier. For the proxy kind of components there are no utilities available, but the OpenMI Association will discuss this issue at the next technical committee meeting, and may decide to create such utilities.
 You also ask about running all models on one multiprocessor machine. Basically, you can do this with "normal" kind of LinkableComponents. However, since OpenMI is single threaded I would not expect that you will improve the performance due to multiple processors. When one model is calculating all other models in the configuration are just waiting for this model to return the data. There may be some cases where some models may be allowed to proceed with their calculations after they have returned the requested data. Such a feature could be implemented in the wrapper utilities.

public interface Ilink

}
public interface Ilink
{
     ITimeStampEarliestInputTime {{color:blue}set;}
} | Accepted [A], Rejected [R] or Considered [C]
for implementation in version:
OpenMI .Net 1.3 [  ]
OpenMI Java 1.3 [  ]
OpenMI .Net 2.0 [C]
OpenMI Java 2.0 [C]
Comments:
Implementation status: |
| 16 | Stay close to the concept "Ask for values as needed by the requesting linkable component"
By Rob Brinkman
Importance: high  Impact: high _Target:_org.OpenMI.Standard
Beneficial to: trainers, SmartWrapper, any mapping functionality, future developments

The most important basic rule of OpenMI is that you ask a component for values of a quantity, define their location and specify how they are calculated. In OpenMI terminology you ask for values at a ITime for a IQuantity on an IElementSet using several IDataOperations.

During the development of OpenMI we drifted away from this principle, which is regarded as one of the strengths of OpenMI. This was done for many good reasons, for example in the beginning a typical usage of OpenMI was to link two ID based element sets. In order to perform appropriate mapping, the source element set was specified. But as we use geographical mappings nowadays, the source element set is not of any importance and confuses a lot of people. Actually, if you want to deliver data on an ID based element set, the source element set is part of how you map two ID based element sets and therefore should be part of a data operation
As links define the necessary meta data for the GetValues call, links should only hold data for doing this. Therefore links don't need to have a property for the target component, since this should not have any influence on handling the GetValues call.
Actually, all information needed for defining how data are to be calculated should be stored in data operations. This is the case for element set mappings, but also for quantity mappings. This removes the need for having a source quantity as property of the link. The link is changed as follows (quantity and element set are the former target quantity and element set):
public interface Ilink
{
     IQuantityTargetQuantity

     IQuantitySourceQuantity

     IQuantity Quantity {{color:blue}get;}
     IElementSetElementSet {{color:blue}get;}
} 
A common data operation will be the quantity mapper. This data operation is needed almost always, but we think it is good to realize that it is a data operation. Unit conversion should be performed by this data operation.
As a consequence, we doubt the functionality of the IOutputExchangeItem. Its properties reflect very much the approach that a source element set is needed. For a geographical mapping this is not needed. However, in user interfaces you need something to apply the right data operations. To support a user interface, you need the following:
-          The available data operations for a certain input exchange item.
-          The available options for a certain data operation (e.g. the source quantities for a quantity mapping data operation)
The first requirement is achieved by additional methods in the linkable component. The second requirement is realized by using the arguments of a data operation. An argument is extended with choices, i.e. the possible values from which the user can choose an appropriate value. So for quantity mapping, there is one argument named "Source Quantity" with all source quantities as possible values. This leads to the following changes in interfaces:
public interface ILinkableComponent
{
    intOutputExchangeItemCount

} 
public interfaceIDimension

public interface IValueSet

public enum ValueType
public interface IScalarSet
public interface IVectorSet
The latter two methods in the IValueSet are convenience methods; they return a slice or single value of the value set. The main method is the Values property. There must be a rule how to interpret the array, since you can choose between (x,y,z,x,y,z,x,y,z,x,y,z) and (x,x,x,x,y,y,y,y,z,z,z,z) for vector quantities. We prefer the latter one, since that enables easier subarray extraction.
Note that there is no difference for the simple quantity (i.e. not combined, delivering a scalar set). The resulting value set will be very similar to a scalar set.

 
The size of the array in the IValueSet is the number of ITimes in the GetVales call times the number of elements in the element set times the number of quantity parts in the quantity. See the following examples:
Asking for two  times for a simple quantity on an element set of three elements would return an array like : x_t=1,e=1,x_t=1,e=2, x_t=1,e=3,x_t=2,e=1,x_t=2,e=2, x_t=2,e=3.
Asking for multiple times (2) for a combined quantity (x,y) on an element set (3) would return an array like : x_t=1,e=1,x_t=1,e=2, x_t=1,e=3,y_t=1,e=1,y_t=1,e=2,y_t=1,e=3,x_t=2,e=1,x_t=2,e=2,x_t=2,e=3,y_t=2,e=1,y_t=2,e=2,y_t=2,e=3.

 This interface is used just before the run. The deployer (or another piece of software triggering the run) checks if this interface is implemented by a linkable component and if so, loads the state. The state reference is retrieved from the omi file by a new, optional xml attribute.