You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 was 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 and based on this 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.

Unit Test

  • No labels