• View
• Edit
• History
• Print

Functional Mock Up (FMU) Interface (FMI)

This page contains notes about the Functional Mock Up interface

Getting Started

See the FMUImport javadoc for how to import a FMU into Ptolemy

See Also

• OpenModelica FMI
• JModelica FMI

JFMI

See JFMI for a Java interface to FMI

Debugging a Mac FMU

Debugging an FMU from Java is like fighting drunk polar bears in a snowstorm. Soo... a debugger is useful.

These instructions worked for me with Java 1.6.0_45 under Mac OS 10.7.5. Your mileage may vary.

Under Mac OS X, to create a shared library that includes the line information for debugging, you must include the .c file in the link line (See http://stackoverflow.com/questions/584825/dsym-directories-while-compiling-c-code-in-macos)

To compile the FMU, I used:

In Ptolemy, the fmus include a build script in the source directory. To build a FMU under Mac OS X:

The last step updates the FMU in ptolemy/actor/lib/fmi/test/auto, which is what the FMU we are going to run uses.

The next step is to invoke gdb. I used

The next step is to start up vergil from gdb. I used the following gdb command. You would need to adjust the classpath

The next step is to stop gdb with Control-C and set a breakpoint

Then, type cont to continue the process and run the model. The gdb process will stop at your breakpoint:

Use the typical gdb commands to step through the model and print variables:

Running a Win-32 bit FMU

Dymola and OpenModelica produce 32-bit dlls, so we need to use a 32-bit JVM.

1. Get an account on joule.eecs.berkeley.edu. See How do I get to use the joule.eecs.berkeley.edu machine? 2. Use Windows Remote Desktop to connect to joule.eecs.berkeley.edu. Most users will connect using the EECS domain, not the @@Joule domain. 3. Ptolemy is invoked from MinGW (Minimalist GNU for Windows), which is installed on Joule. Start the MinGW Shell via Start -> MinGW -> MinGW Shell

4. Use Christopher's tree, (or http://chess.eecs.berkeley.edu/ptexternal/ check out your own, be sure to use a 32-bit JVM, see below)

5. Dymola and OpenModelica produce 32-bit dlls, so we need to use a 32-bit JVM.

6. Put $PTII/lib in your PATH

7. cd to the demo and run it. Unfortunately, the scripts in $PTII/bin do not work under MinGW because MinGW does not understand Cygwin symbolic links and MinGW does not run .bat scripts. So, we run by hand

Problem: IncrementalFMU_wrap.dll: Can't find dependent libraries

I used Dependency Walker from http://www.dependencywalker.com/

LIBEXPAT-1.dll and LIBSTDC++.dll were missing.

Solution: Be sure that you are running inside the MinGW Shell and not Cygwin. /mingw/bin should be in your PATH

Linux Symbol Problems.

Summary: Loading two different FMUs into Ptolemy II causes the JVM to crash if the shared libraries of the FMU files have functions with the same name.

This is very odd, and points to a problem possibly with JNA.

The fix is to 1. edit the .c file that defines the FMU and, before fmuTemplate.h is included,

2. For each method in the .c file, preface it with a #define:

See $PTII/ptolemy/actor/lib/fmi/fmus/inc20RC1pt/src/sources/inc20RC1pt.c

The FMI2.0RC2 standard says:

Solution to the Linux Multiple FMUs problme

The solution was to properly define the export. See Incorrect setting of FMU_Export in fmiFunctions.h for FMI2.0rc1, which states that fmiFunctions.h should be changed from

to

Also, it seems necessary to compile with, -fvisibility=hidden, see Controlling the Exported Symbols of Shared Libraries.

Complications with Linux Symbols

In a nutshell, the problem is that if, under Linux, two FMUs are loaded, and they have functions with the same name, then there can be problems about which function is invoked.

This indicates that it is best if the functions are not changed for the different FMUs. This also points out possible problems with using multiple FMUs from different versions of the FMU standard.

Details

We had two FMUs:

• tankOpen.fmu, a hand-written ModelExchange FMU that had implementations for only the necessary methods. In particular fmiSetString() was a no-op
• values20RC1.fmu, an FMI2.0RC1 FMUSDK2 FMU

If a Ptolemy model containing the tankOpen FMU was run first, then when the Ptolemy model containing the values20RC1 FMU would fail:

 Caused by: ptolemy.kernel.util.IllegalActionException: Test fails in iteration 0.
 Value was: "". Should have been: "jan"

Adding a fprintf to tankOpen.c indicates that the fmiSetString() method in tankOpen.c is being called

This can be seen in the output:

What's happening here is that values20RC1.c has:

The copy() lines are macros, defined in fmuTemplate.h:

fmuTemplate.h has the definition of setString():

What is happening here is we properly invoke the correct setStartValues() function because JNA has a handle to the values20RC1 shared library and (presumably) calls dlsym() to get a pointer to the function. However, while executing the method, the copy() macro was expanded to the setString() call, which is found in the values20RC1 shared library. However, the call to fmiSetString ends up invoking code from the tankOpen shared library!

This probably occurs because tankOpen was loaded with dlopen(RTLD_LAZY|RTLD_GLOBAL)

A few best practices for writing FMUs

1. Do not modify the standard functions in fmuTemplate.c. The reason is that these may be invoked by other FMUs.
2. Be very careful about calling FMU API functions from within your FMU. The reason is that these calls might invoke methods from other shared libraries
3. The functions in fmuTemplate.c should not probably not use FMU-specific #defines. For example: fmiGetString() has:
   if (vrOutOfRange(comp, "fmiGetString", vr[i], NUMBER_OF_STRINGS))
   return fmiError
   

   [$[Get Code]]
   This is probably not that robust because if the code was compiled for one FMU with a value of NUMBER_OF_STRINGS and then another FMU invokes that method and the FMU has a different value of NUMBER_OF_STRINGS then the incorrect results would occur. Note that there are various methods that use #defines, in particular fmiInstantiate(). However, we are sure to get the correct fmiInstantiate because we call dlopen(), get a handle and then call dlsym() on that handle.

8-Dec-2014: Ok, Incorrect behavior loading multi librarys has a similar problem and suggests:

FMI++

• http://sourceforge.net/p/fmipp/wiki/Home/ FMI++ sources

Building FMI++ under Windows

Mingw

Install Mingw from http://sourceforge.net/projects/mingw/files/MinGW/ When installing, be sure to select c++. I also selected the full development environment

Boost

Install Boost in c:/Tools

See https://code.google.com/p/pcxprj/wiki/BoostCompiledByMinGW

Start up the mingw shell, and in the boost sources:

libexpat

Download libexpat*-dev.tar.gz from http://sourceforge.net/projects/mingw/files/MinGW/Extension/expat/expat-2.0.1-1/

and then tar -zxf the downloaded

Building FMI++ under Mac OS X

Get the FMI++ source:

Get Boost, which contains odeint

Under Mac OS X, versions of Boost after 1.53 will include odeint. If /opt/local/include/boost/numeric/odeint exists, then odeint is present and need not be installed.

If /opt/local/include/boost/numeric/odeint is not present, then install Boost.

If you have MacPorts installed, then use:

If you don't have Mac Ports installed, then download boost from http://sourceforge.net/projects/boost/files/boost/1.53.0/

BTW - there are no instructions on how to build odeint? That's because it uses C++ templates and there is nothing to compile in advance.

Building Boost Under Linux

Under Linux, I did:

However, that didn't work, there were missing files.

As root:

As yourself:

Download from http://boost.org and untar, then run

Build Swig

Under Mac OS X

Building Swig from source

Under Mac OS X, this is probably wrong, try mac ports instead. Under Linux, I had to build Swig Under Linux: download from http://www.swig.org/download.html

Under Linux as root:

Building fmipp

Edit makefile.linux

At the top:

Add a build.macos rule

To build the Java/FMI++ interface, add the following rule:

Running examples under FMI++

It looks like the example requirea installing OpenModelica.

How to test a FMU

There is a compatibility test on the FMU svn, but one quick test is to install FMU SDK and try loading the .fmu file that way.

Another trick is to unzip the .fmu file and the use ldd under Linux or Mac OS X or use a dependency checker under Windows. (

• http://www.dependencywalker.com/
• See Stackoverflow how to check for dll dependency

If you are getting missing symbols, try using the nm command.

Invoking a 32-bit Java

If you are using JFMI to invoke a FMU, then you will need to run a 32-bit JVM to invoke a 32-bit FMU or run a 64-bit JVM to invoke a 64-bit FMU.

This only matters under Linux and Windows. Modern Mac OS X JVMs are typically 64-bit.

To see what binaries are in your .fmu, unzip it.

To run a 32-bit FMU, it is usually necessary to install a 32-bit JVM. Most platforms have the 64-bit JVM installed.

To install a 32-bit JVM, go to the Oracle site and select a 32-bit JVM and install it. Locally, we have installed 32-bit JVMs in c:/Program Files (x86)/Java and /usr/lib/jvm

Set your path to include the 32-bit JVM and then reconfigure Ptolemy II.

32-bit JVM under Linux

This is 64-bit JVM:

This is a 32-bit JVM:

32-bit JVM under Windows with Cygwin

This is a 64-bit JVM:

This is a 32-bit JVM

What does causuality local mean?

One issue that is bothering me is that it is hard to know when something is an input or not.

For example, ptolemy/actor/lib/fmi/fmus/dqME20/src/modelDescription.xml defines these ModelVariables

Here, I think x is an input and der(x) is an output. The notion of causality=local is defined in the spec as:

"local": Local variable that is calculated from other variables or is a continuoustime state (see section 2.2.8). It is not allowed to use the variable value in another model or slave.

and

"[causality = "calculatedParameter" and causality = "local" with variability = "fixed" or "tunable" are similar. The difference is that a calculatedParameter can be used in another model or slave, whereas a local variable cannot. For example, when importing an FMU in a Modelica environment, a "calculatedParameter" should be imported in a public section as final parameter, whereas a "local" variable should be imported in a protected section of the model.]"