...
Linking OpenMI 2 compliant components has become much more flexible than it used to be with OpenMI 1.x. Components with different concepts or in OpenMI language extensions can exchange their data. A component with the classical Modified Julian Day time definition can for example provide a consumer component, defining its simulation time by an index, with data. The provider would implement the time and space extension whereas the consumer could implement an extension for index-related dictionaries. The provider should contain an AdaptedOutput converter using both time definitions and thus being able to convert the time to the index value. More knowledge about the underlying extensions is required from the user in order to select the appropriate items and to check the plausibility of the results. This is the price being paid for higher flexibility, less due to the OpenMI but to the complexity of the task.
If both LinkableComponents implement the same OpenMI extension interface, their provider consumer relationship will remain as straight forward as with OpenMI 1.x, the conversions in AdaptedOutput will be easier to use.
When writing this documentation in Summer 2010, only the base interfaces and an extension for the classical time and space dependent components are available. Future extensions could support parallel computing, compliancy with the standards of the Open Geospatial Consortium OGC and much more.
One should remember that compliancy does not mean a pure plug and play connection. From the technical point of view most of the input and output of two LinkableComponents can be connected for data exchange. But neither the standard nor the related sdk offer too much methods for checking the correctness of the selected variables. The user has the responsibility for selecting for example the appropriate quantities and the locations where they are defined. The approved, but updated interface definitions as well as the extensions preserve the slimness of the OpenMI.
...