OpenMI is an open standard that facilitates linking of hydrological models and modules. It allows components like rainfall, rainfall-runoff, and river models to be linked together to pass data between them. OpenMI provides a standardized interface that models implement, allowing them to be connected in different configurations without being hardcoded. It works by having each component query the exchange items it provides and requires, and links are created between matching inputs and outputs. When the simulation runs, components request data from each other through these links. This makes models more interoperable and reusable.
2. What is OpenMI Rainfall module OpenMI is an open IT-standard that facilitates Linking of hydrological model and modules Rainfall / Precipitation Rainfall-runoff model Runoff River model
3. Different approaches to linking Output file Output file Output file Output file Output file All together “hardcoded” File based The OpenMI way RR model River model RR model RR model & River model Write Write Write Write Read River model Write
4. Another standard - USB Rainfall module USB Precipitation My model River model Runoff Rainfall-runoff model Leakage Provides freedom of choice for the users Provides opportunities for suppliers Ground water model
5. DEMO River model Runoff Rainfall-runoff model 3 : Inspect the results 2 : Configure and run 1 : Setup your models OMI file
7. How does OpenMI work Setup files Output file void Initialize(IArgument[] properties) string ComponentID string ComponentDescription string ModelID string ModelDescription ITimeSpanTimeHorizon IInputExchangeItemGetInputExchangeItem(int index) IOutputExchangeItemGetOutputExchangeItem(intidex) intInputExchangeItemCount intOutputExchangeItemCount void AddLink (ILink link) void RemoveLink(string linkID) string Validate() void Prepare() IValueSet GetValues(ITime time, string linkID) ITimeStamp EarliestInputTime void Finish() void Dispose() User Interface OpenMI Standard Write Run Write My model OMI file Read .NetOrJava model engine Fortran, C, c++, Pascal, C#, Java, etc. OpenMIStandardInterface Write
8. How OpenMI works From outside all OpenMI compliant components look the same void Initialize(IArgument[] properties) string ComponentID string ComponentDescription string ModelID string ModelDescription ITimeSpanTimeHorizon IInputExchangeItemGetInputExchangeItem(int index) IOutputExchangeItemGetOutputExchangeItem(intidex) intInputExchangeItemCount intOutputExchangeItemCount void AddLink (ILink link) void RemoveLink(string linkID) string Validate() void Prepare() IValueSet GetValues(ITime time, string linkID) ITimeStamp EarliestInputTime void Finish() void Dispose() RR model River model
9. How does OpenMI work void Initialize(IArgument[] properties) string ComponentID string ComponentDescription string ModelID string ModelDescription ITimeSpanTimeHorizon IInputExchangeItemGetInputExchangeItem(int index) IOutputExchangeItemGetOutputExchangeItem(intidex) intInputExchangeItemCount intOutputExchangeItemCount void AddLink (ILink link) void RemoveLink(string linkID) string Validate() void Prepare() IValueSet GetValues(ITime time, string linkID) ITimeStamp EarliestInputTime void Finish() void Dispose() My model Read OMI file Create component Invoke (call) Initialize Component will read input files and initialize
10. How does OpenMI work The OMI file <?xml version="1.0"?> <LinkableComponent Type=“RainfallRunoffModelLC" Assembly="..inainfallRunoffModel.dll"> <Arguments> <Argument Key=“InputFileName" ReadOnly="true" Value=“..atayInputFile.xml" /> </Arguments> </LinkableComponent>
17. Looking forward OpenMI Version 2.0 Rainfall module New concept for data operations and linking Better support for non-model components Precipitation Not only pull-driven No trigger And much more, to be presented later today…..
Hi and welcome to this video based introduction to OpenMIIn this video I will explain very briefly what OpenMI is, how it works, and how you, as a modeler or water manager, can take advantage of OpenMI.The video contains a power point presentation and a demonstration of how you can configure systems ofOpenMI linked models and modules.
So, what is OpenMIOpenMI is an open IT-standard that facilitates linking of hydrological models and modules.Just to get started let’s take a look at a simple example. A rainfall module, which could be a database with time series of rainfall data inside.A rainfall-runoff model, which can calculate the runoff or the discharge to the river systemAnd finally a river model that can simulated the flow in the riverIn order to make this work information must be passed between the modules.Precipitation data must be passed from the rainfall module to the rainfall-runoff model.The data to be passed is a time series, which basically is a series of corresponding values of time and precipitation. And finally -The calculated runoff must be passed from the rainfall-runoff model to the river model, which again take the form of a time series.Such interlinked systems have been created also before OpenMI was around, so in order to place OpenMI into a wider context I will explain three different approached for creating such a systems on the next slide. For sake of simplicity I will leave out the rainfall module and only explain approaches for the coupling between the rainfall-runoff model and the river model
The first approach is the file based approach.In this approach the rainfall-runoff model will be executed first. Then the river model will run – using the output file from the rainfall-runoff models as part of it’s input.Even though the file based approach may seem pretty simple it has some major drawbacks.Most likely the output file from the rainfall-runoff models cannot be read directly by the river model. This file must be converted to a format that is readable by the river model or the river model must be changed so it can read the rainfall-runoff model output file. This will require considerable efforts and your solution can only be used for linking those two specific models. Another problem is that the output file from the rainfall-runoff model may be written in a binary format that you cannot access. So, you are totally dependent on the model software providers for solving this problem, which becomes even more problematic if you are using model software from different providers.In the “all together” approach, you have a complete solution where the rainfall-runoff model and the river model are build into one single application. Using such a system is pretty strait forward, since you do not have to worry about how the data is transferred between the models. But, say you already have a rainfall-runoff model, which work perfectly for you and you want to extent your system with at river model. Buying a complete solution will most likely mean that you will have to get used to another rainfall-runoff model, and the problem of linking will arise again if you what to extent your system with a third model.In the OpenMI approach, the two model component communicated directly with no file in-between. This type of linking requires that the two models are OpenMI compliant. <click> The link between the two models can be configured without any programming. Because the models are communicating during the calculations two way linking is also possible, which definitely cannot be achieved with the file based approach. And there are no requirements for the two models to use the same time step length or even the same grid or schematization, all this is handled by the OpenMI.
Before going into details about OpenMI the Standard, let’s take a look at another – USB. Before USB was around it could be a pretty tedious process to do even simple things such as getting your printer to work with your computer. <click>. Now a days you can easily connect all kind of devices with no efforts. <click> This is possible because there is a strict standard defining how plugs and sockets are manufactured and how the data is transferred across the line. <click>.The USB standard has given the users the freedom to setup systems of interconnected hardware devices, regardless of which manufacturer produced the device. And from the manufacturers perspective USB has given opportunities to produce and sell all kind of devices that would have little value on their own.So what has this to do with OpenMI.Well, for OpenMI it is also a strict standard that make the communication between OpenMI compliant components possible. This allows modelers to select those OpenMI compliant models and modules that are most suited for each particular case and link all these together. And this is possible even when those components come from different providers. And seen from the providers perspective, OpenMI provides opportunities for creating specialized models and tools, that would have little value on their own.
In a moment I will demonstrate how you can configure and run OpenMI linked systems.For this demonstration I will use the example where a rainfall-runoff model is linked to a river mode.There are basically three steps involved in this <click>The first step is to setup each of the models that you will use in your configuration. This is done in the normal way, where you typically use the models user interfaces to define all the input needed for your models.<click>When you save your setup, OpenMI compliant models will, apart from saving the model setup, also save a small OpenMI specific xml file – the OMI file, which contains sufficient information for an OpenMI environment to load and initialize the calculation core of your model. <click>After that you will use a configuration editor to configure the links between the models, and subsequently run the linked system.When the system is running each model will write output to it’s own output files in exactly the same way as if it was running on it’s own. <click>After the calculations have finished you can inspect the output files in the same way a you would normally do, for instance by use of the models user interface.I will use dummy models for the demonstration, simply because these will run fast and because these models are publicly available, so if you like, you can download these and try it out for yourselves.In the demonstration I will skip the first and the third step, and simple show how to configure and run the system.
Just to make sure that we have a common understanding of the concepts of a model, let me explain a few things.Basically a model is a numerical representation of reality. In this example it is a river that is represented by the model on the computer.When you prepare your model you will feed the computer with lots of information about physical reality. <click>For river models for instance you will define the river network by polygons, calculation points and cross sections. <click>Metrological data such a precipitation is represented by time series. <click>If you were working with a ground water models you would define a two or three dimensional grid and define soil conductivity, porosity and so on for each grid cell.<click>For conceptual lumped models, such as the rainfall-runoff model we used in the demonstration, things a bit easier, since you only enter one set of parameter for the whole catchment.When all this is done you can run your models and investigate the predicted outcome for a number of different scenarios.
Now let’s take a look at how OpenMI works. Internally, most models are organized in the same way. <click>The modeler will use the user interface to define the input data.<click> When the user saves the setup the model application will save all this information into on or several setup files.<click> OpenMI compliant models will also save the OMI file at this time.<click>In order to run the model, the user will typically press a run button in the user interface, where after the model engine is loaded. <click>The model engine will read the setup filesdo the calculations and <click>write the results to one or several output files. After end of calculations the output is typically loaded back into the user interface where the results are presented to the user.When the model is running in an OpenMI environment it is only the model engine that is used. So, OpenMI does not care about input and output files.<click>In order to enable the configuration editor and other OpenMI compliant models to access the model engine, the engine must have a number of standardized functions or methods that can be called.<click>This is typically achieved by adding a software layer around the engine. This layer will make all the OpenMI standard methods available to the outside. In software terms such layer is called a wrapper and we say that the wrapper implements the standard interface. <click>The wrapper must be programmed in .Net or Java, <click>whereas the model engine can remain in it’s original programming language. The good thing about this is that the model provider do not have to totally re-programme the model engine and the same engine can be used both for normal running of the model and for running in an OpenMI environment.In the following slides I will go through the demonstration with the rainfall-runoff model and the river model again, and this time show how the standard methods are used.
First of all is it important to understand that all OpenMI compliant components and models can en accessed in exactly the same way through the OpenMI standardized methods. So, seen from outside, or as it was the case in the demo I showed you a moment ago, seen from the perspective of the configuration editor, the rainfall-runoff model and the river model will look the same.
Now, let’s go through the configuration and running of the linked rainfall-runoff model and river model, a look at how the methods in the OpenMI standard are used.After loading the OpenMI configuration editor I selected “add model” and browsed to find and select an OMI file. After that the configuration read the OMI file, where information about model dll, class name, and input file name and location could be found. Then the configuration editor created an instance of the model component and called the initialize method in the standard interface, passing the input file name and location as an argument. The model component could then initialized it selves, which typically involves reading the input file, allocation of memory and so on.
Just to make sure that there is not mystery associated with the OMI file let me show you an example.The LinkableComponent Type is the class name of the OpenMI compliant component – in this case it is RainfallRunoffModelLC and the Assembly is the name and location of the corresponding dll. With this information an instance of the component can be created.In this example there is only one argument – the path and file name for the input fileRemember that end-users do not have to worry about OMI files at all. OMI files are typically generated to the model user interface, so all the user need to do is to select the OMI file.
The next thing I did was to right click on the model – the yellow box, and select model properties.The configuration editor responded with presenting information about the rainfall-runoff model such as component ID and time horizon. The red arrows on the slide show which methods in the OpenMI standard interface, that was used to get this information.
I added the river model and created a connection between the two models. Right clicking on the connection brought up the connection properties dialog. All possible output exchange items for rainfall-runoff model were presented in the left panel and all possible input exchange items for the river model were presented in the right panel. Again this information was obtained through the OpenMI standard methods– in this case the GetInputExchangeItems and GetOutputExchangeItem methods. I made selections so discharge for the lumped catchment would be used a flow input at node 0 in the river model.After pressing the apply button, the configuration editor created a link object, which contained all this information.This object was then added to both the rainfall-runoff model and the river model, by use of the OpenMI standard Add link method. In this way both models were aware of what information they had to pass during the computation.
After the trigger was added to the configuration I selected Run from the composition menu.As you can see from the list of OpenMI standard methods there are not run method. OpenMI is using the so called pull-driven architecture. This means that all components will stay idle until another component asks for data. Asking for data takes place by use of the OpenMI standard GetValues method. <click>The trigger component will start calculations by invoking the GetValues method <click> in the river model, asking for some data corresponding to the end time for the simulation. <click>Because the river model at this time is at it’s initial state it must start it’s internal time stepping loop to get to the time where is can deliver the data.But since the river model is linked to the rainfall-runoff model it must before each time step obtain the inflow to it’s top node from this model according to the link we defined earlier. So the river model invokes the GetValues method <click> in the rainfall-runoff model with a time argument that corresponds to the time at which it needs the flow.<click> The rainfall-runoff model does not have any incoming links so it can simply do as many time steps as needed in order to get to the state where it has calculated the requested flow. Since there is no requirements for the linked models to use the same time step length most likely the rainfall-runoff model will use simple interpolation to calculate the flow corresponding to the requested time. <click>The rainfall-runoff model can then return the flow <click> and the river model can complete it’s time step. Before proceeding with the next time step the river model will again invoke the GetValues method in the rainfall-runoff model <click> and the whole story repeat it selves <click> until the river model has reached the time for which the trigger initially asked for data and the controle is returned to the trigger <click>.All the configuration editor now need to do is to invoke the finish and the <click> dispose method in all components, allowing these to save output, close files, de-allocate memory and so on.
In the rainfall-runoff model river model example only one value needed to be passed between the models, so let’s take a look at a more complex example.For this I will use a river model and a ground water model, where the river model will provide the leakage to the ground water model <click>In order to calculate the leakage the river model needs information about the ground water level, so ground water level must be passed from the ground water model to the river model. <click>This can be achieved by creating two links so the GetValues method will be called in both directions during the calculations <click>Another thing is that the ground water model is using a grid for the calculations <click> so the ground water model will need the a leakage value for each grid cell.The river model will use a polygon with calculation nodes and branches for it numerical schematization. <click> and in order to calculate the leakage the river model will need information about the ground water level at the location of each individual branch. The OpenMI exchange items have standards for representing geometries such as those showed on the slide. So you can actually link one entire schematization to another schematization. <click>Because the information about both geometries are included in the link object that is passed to both models during the configuration of the system, the model that delivers the data is able to transform the values from being represented on it’s own schematization to be represented on schematization of the accepting component. One of the fundamental concepts of OpenMI is that when a component use the GetValues method to get values from another component it basically asks for data at the desired time and locations. It is the responsibility of the delivering component to take care do whatever temporal and spatial interpolations and extrapolations needed in order to deliver the data.
Just a few words about model migration. As you could see from the previous slides OpenMI puts a lot of responsibilities on the compliant components. A compliant component must in principle be able to deliver it’s internal data at the requested time and the requested locations, so it may seem like a huge challenge to make a model OpenMI compliant.However, the OpenMI Association technical committee provides open source libraries that will assist the model developer in migrating models. These libraries are called the OpenMI software development kit – the SDK. <click>The SDK will take care of most things inside the OpenMI wrapper <click>The main task for the model developer is to reorganize the model engine so it has a separate section for initialization and it allows the wrapper to make the engine do single time steps.Migration of a model typically takes between a few days to a couple of man months, depending on how complex and well organized the model engine is.
Some final remarks<click>OpenMI is just a standard, which allows model developers to migrate their model engines in their preferred way.<click>One of the things that make OpenMI special is that there is no framework. OpenMI compliant models can be used in many different environments. In the demonstrations I used the configuration editor provided by the OpenMI Association, but you can use any other editor or you can build OpenMI configuration functionality into your own modeling environment if you like. <click>In this presentation I have focused on models. But OpenMI can be used to exchange data between any component that can deliver or accept data, such as data bases, web services or even flat files. <click>The fact that OpenMI compliant components can be accessed in a standardized way opens the possibilities to create decision support systems consisting of such components. Such system could have generic optimization, calibration or presentation modules that interacts with the OpenMI compliant components.<click>One of the frequently asked questions is how all the exchange of data will affect the overall performance. Experiences so far has shown that the performance hit from the OpenMI exchange of data is insignificant as compared to computational time that is spent inside the models for their normal calculations.<click>If you want to know more please visit the LicTek web side
Some final remarks<click>OpenMI is just a standard, which allows model developers to migrate their model engines in their preferred way.<click>One of the things that make OpenMI special is that there is no framework. OpenMI compliant models can be used in many different environments. In the demonstrations I used the configuration editor provided by the OpenMI Association, but you can use any other editor or you can build OpenMI configuration functionality into your own modeling environment if you like. <click>In this presentation I have focused on models. But OpenMI can be used to exchange data between any component that can deliver or accept data, such as data bases, web services or even flat files. <click>The fact that OpenMI compliant components can be accessed in a standardized way opens the possibilities to create decision support systems consisting of such components. Such system could have generic optimization, calibration or presentation modules that interacts with the OpenMI compliant components.<click>One of the frequently asked questions is how all the exchange of data will affect the overall performance. Experiences so far has shown that the performance hit from the OpenMI exchange of data is insignificant as compared to computational time that is spent inside the models for their normal calculations.<click>If you want to know more please visit the LicTek web side