Oatc.OpenMI.Sdk.*
- the dlls and executables Oatc.OpenMI.Gui.* for running OpenMI

 in the configuration editor with GUIs or from command line. 

 
h1. 2. Technical prerequisites

h3. 2.1. Machine and OS of the test system

- workstation with an Intel Xeon processor

- 64bit openSUSE 11.0

h3. 2.2. Mono

- Mono v. 1.9.1. for openSUSE 11.0 in 64 bit mode. V. 1.9.1. is also referred to as Mono 2.0.

- The standard and the sdk sources should be compilable with previous versions. But the GUIs require Windows.Forms, which has been shipped with v. 1.9.1. in Oct. 2009

.


2. How to compile and execute a Mono application

Used command for generating a dll:
{code:java}
gmcs -target:library -out:<target>.dll -r<linkedlib_1>.pc -pkg:<linkedlib_1>.pc;...;<linkedlib_m>.pc <source_1>.cs ... <source_n>.cs 
{code} 
gmcs -target:library -out:<target>.dll -pkg:<linkedlib_1>.pc;...;<linkedlib_m>.pc <source_1>.cs ... <source_n>.cs 
<linkedlib_?>.pc are ASCII files that refer to the linked libraries <linkedlib_?>.dll. They contain the path and the version of the dll. Example for the standard dll:
prefix=/net/themis2/system/akprog/CS/OATC/AthenTraining/xe64/src/OpenMI.Standard
exec_prefix=${prefix}
libdir=${exec_prefix}
Name: OpenMIStandard
Description: OpenMI Standard
Version: 1.4
Libs: -r:${libdir}/OpenMI.Standard.dll
Used command for generating an exe file:
gmcs -out:<target>.<postfix> -pkg:<linkedlib_1>.pc;...;<linkedlib_m>.pc <source_1>.cs ... <source_n>.cs 
Further compile information for resources is given in section 3.3..
Applications compiled with Mono do not run directly on the linux system, they are interpreted on a runtime engine, comparable to the virtual machine in java. Thus, the command in the terminal window command line has to start with mono, e.g.:
mono Oatc.OpenMI.GUI.ConfigurationEditor.<postfix>


{include:1 Introduction}


{include:2 Planning the migration}


{include:3 Wrapping}



4. Migration - step by step


The best strategy when migrating a model is to split the process into a number of steps; at the end of each step you can compile your code and run a small test.

The steps needed for migration are described in this chapter.


{include:4.1 Step 1 - Changing your engine core}


{include:4.2 Step 2 - Creating the .Net assemblies}


{include:4.3 Step 3 - Accessing the functions in the engine core}


{include:4.4 Step 4 - Implementing the MyEngineDotNetAccess}


{include:4.5 Step 5 - Implementing the MyEngineWrapper class}


{include:4.6 Step 6 - Implementing the MyModelLinkablComponent}


{include:4.7 Step 7 - Implementation of the remaining IEngine methods}



5. Migration of the Simple River


The previous chapter described the steps involved in migrating a model to the OpenMI.

This chapter shows how the migrated code is developed for the Simple River example.


5.1 The Simple River Wrapper


The Simple River model uses the migration pattern shown in Figure 12. Figure 13 gives a detailed explanation of how the Simple River wrapper works in terms of the wrapper classes.



Fig. 13 Simple River wrapper classes



{include: 5.2 Implementation of the Initialize method}


{include: 5.3 Implementing the SetValues method}


{include: 5.4 Implementing the GetValues method}


{include: 5.5 Implementation of the remaining methods}



6. Testing the component


It is important to test the component to check that it is working correctly. Traditionally, the procedure has been to complete implementation and then run the engine to see if it produces the correct results. However, in recent years new methodologies have been developed for testing. The dominant testing method for object oriented programs is unit testing. Unit testing is done in parallel with the implementation. This means that you will be able to find errors earlier and thus save time on debugging your code later.

This chapter discusses the testing of migrated components.
{include: 6.1 Unit testing}


{include: 7. Implementing IManageState}


{include: 8. The OMI file}


{include: 9. The OpenMICompliancyInfo file}