Introduction

As for OpenMI version 1.4 we also need a wrapper for model engine for version 2. Such wrapper will assist people which are not oo specialist in making their models OpenMI compliant. I have made the first considerations for making such wrapper package. At first, it was my intention to build a new wrapper that could access the model engine through the old IEngine interface or something that was very close to this. This seemed logic because the IEngine basically has very little to do with OpenMI, but reflect the obvious was of accessing a time stepping kind of model engine. However, since the version 2 ILinkableComponent interface is much more like the IEngine interface, it turned out to make more sense simply to implement the ILinkableComponent interface directly.

Migration of the simple river

My approach has been to start migrating one specific model and based on experiences from this design a generic wrapper. This was actually also the approach we followed when we designed the version 1 wrapper. Simply migrate specific models where after it became clear how to make the generic wrapper. For my wrapping I have used the well know simple river. You can find a description of the simple river here: Oatc.OpenMI.Examples.ModelComponents.SimpleRiver. However, the simple river is written in Fortran, which makes things a bit more complicated, so I have translated the Fortran part to C#, but kept the clear destination between wrapper and engine. Both the wrapper and the engine are checked in on source forge in the trunk under the namespaces: "Oatc.OpenMI.Examples.ModelComponents.SimpleCSharpRiver.Engine" "Oatc.OpenMI.Examples.ModelComponents.SimpleCSharpRiver.Wrapper". If you search the code you can find places where I have written comments starting with "Note:". These are comments to things that we may want to change to the standard or the SDK.

Experiences from the migration

Simple Access methods

Implementing all the simple methods such a ComponentIdentifer, InstaceIdenfer, TimeHorison and Initialize went smoothly. Almost no changes as compared to implementing these method under the IEngine interface.

Update and ExchangeItems

For the simple river I made specialized implementations of output and input items. So, in my case I have FlowInputItem and FlowOutputItem, which were inherited from Backbone.InputItem and Backbone.OutputItem, respectively. Both classes has an initialize method, where a reference directly to the corresponding data in the model engine can be set. - in my case simply an index in a array.

The Update method in my LinkableComponent is very similar to the pattern used in the old wrapper implementation of the the GetValues method. First update every input exchange items (I implemented an update method in my FlowInputItem). This will ensure that data from outside in feed into my engine. Then the time step is made, and finally all output exchange items are populated with the data calculated by the engine. However, there is a potential performance problem. I have assumed that I do not know if anyone will ask my output items for data, which means that each and every output item must be updated after each time step. I could have checked if the output item had consumers and only update items with consumers. However, I think that it would be very unfortunate if you are required to add a consumer to an output item in order to get the data. A better solution would be to override the [] method in the Values property so data is only copied to the output exchange item when needed. It turns out that, when we use the System list this is not possible. So, we could consider to make out own implementation of IList.

Unit Test

I made two unit tests; a RiverModelWrapperTest and a ConfigurationTest. The first one tests the simple access and the second one tests a case where two instances of the simple river models are linked. So, far I have not implemented any decorator so the configuration test is a bit of a hack. However, according to the standard it is allowed to add OutputItems to InputItems, so in principle this should be ok. Perhaps it would make more sense only to allow decorators to be added to inputItems.

Conclusions

When I did the implementation I had many doubts about how to do things right. I also have some worries about the standard - is it too flexible to ensure safe linking of components by third party users. Anyway, my suggestion is to, at the OATC meeting, to go through the code (the wrapper as well as the unit tests), and discuss the implementation for each method and evaluate the OpenMI standard based on this.