...
2.1.3. What does the compliancy definition mean for the user?
(Peter)
"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.
...
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 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."
(Adrian)
"Potential users of an OpenMI compliant component should understand the following point
"Being compliant is no guarantee that it can be usefully linked to another OpenMI compliant component. It is a necessary but not sufficient condition."
To be usable the user must also consider the following factors
1. Do both components target the same system infrastructure. Currently Java and .Net components cannot be mixed within the same composition.
2. Do both components implement the same OpenMI version. Development is under way to allow 1.4 components to be loaded alongside version 2 components within version 2 of the configuration editor; however, currently this is not possible. Even when possible, there will still be restrictions as version 2 of the standard exposes new (additional) data exchange concepts which are incompatible with version 1.4
3.Do both components provide and consume all the required data interactions for the underlying physics for the two models interaction. Breaking the underlying physics will cause instabilities (at best) or wrong answers (at worst). The underlying issue here is that OpenMI provides the means to couple models together, but cannot make judgements on the advisability of doing so. The responsibility for this lies with the user; it is expected that they should have competence in the use and application of both models.
4. Are all required output adapters implementations compatible. Version 2 allows for adapters tailored for specific applications and hence some combinations could be invalid. Whilst it can be reasonably expected that adapter implementations from the same software source (SDK) should either be compatible or create sensible runtime warnings if not (if developed well). This is unlikely to be the case when mixing adapters from different software sources. Hence, when using output adapters care should be taken to understand their implementation details."
(Peter at Adrian):
All four points are very true.
I'd suggest to add 1. and 2. to the compliancy info
and to put 3. and 4. into the StandardSpecificationOpenMI_20.pdf,
Chapter "2.8. Assumptions underlying the OpenMI architecture".
2.1.4. What does the compliancy definition mean for an application developer?
...