• View
• Edit
• History
• Print

OpenModelicaFMI

This page has information about Functional Mock-up Units (FMI) and Open Modelica

References

• OpenModelica - notes about how to install OpenModelica
• iCyPhy FMI Wiki (Internal use only)
• Son of Energy Plus (SoEP) (Internal use only)

Issues

Generating a fmu fails because share/omc/runtime/c is not present

12/20/2015

Under both Mac OS X and RHEL 6.7, when building just omc, share/omc/runtime/c is not present.

Indeed, /usr/local/openmodelica/share/omc/ does not exist

The solution is to copy the directory:

2/20/2015 OpenModelica FMI Issues

• 3171 BouncingBall modelDescription.xml is not valid for trivial reasons
• 3170 Under Mac OS X, BouncingBall FMU segfaults in fmuCheck
• 3169 Under Mac OS X, FMU binaries directory should be darwin64, not x86_64-apple-darwin13.2.0 (fixed, then broken again)

Running an OpenModelica FMU crashes Java

At run time, it fails with:

However, running make test, which runs the HeatConductorComplex.fmu with CoSimulation using JFMI works.

Running make test_me, which runs HeatConductorComplex.fmu with model exchange using JFMI also works.

BouncingBall log messages

The error message below is unusual:

This error message occurs if I run a bouncingBall FMU from FMUSDK-2.0:

Editing FMULog.java and reverting to the old logger gets rid of the messages but does not fix the crash.

Note that running with FMUs from FMUSDK also produces the same odd message:

Possible solution is to port the JNA variadic code.

2/20/2015 Adding printfs

I added fprintf(stderr to the FMU.

With vergil, it crashes after:

  HeatConductorComplex_FMU.c start setDefaultStartValues()
  HeatConductorComplex_FMU.c end setDefaultStartValues()

When I run fmuChecker, which works, I get:

  [INFO][FMILIB] Loading 'linux64' binary with 'default' platform types
  [INFO][FMUCHK] Version returned from ME FMU: '2.0'

  HeatConductorComplex_FMU.c start setDefaultStartValues()
  HeatConductorComplex_FMU.c end setDefaultStartValues()
  HeatConductorComplex_FMU.c setReal(4, 270)
  HeatConductorComplex_FMU.c setStartValues()
  HeatConductorComplex_FMU.c getReal(0)
  HeatConductorComplex_FMU.c getReal(1)

Adding printlns to OpenModelica generated FMUs.

The fmi2* methods are defined in /usr/local/openmodelica/include/omc/c/fmi2/fmu2_model_interface.c

To create a .c file that has the fmi2* methods:

  gcc  -fPIC -O0 -falign-functions -march=native    -I"/usr/local/openmodelica/include/omc/c" -I"/usr/local/openmodelica/include/omc/c/fmi2" -I.   -E -o /tmp/H.c HeatConductorComplex_FMU.c

Then:

  cp /tmp/H.c HeatConductorComplex_FMU.c

To enable debugging, edit HeatConductorComplex_FMU.c and add a call to fmi2SetDebugLogging():

     static fmi2String logCategoriesNamesAll[] = {"logEvents", "logSingularLinearSystems", "logNonlinearSystems", "logDynamicStateSelection",
          "logStatusWarning", "logStatusDiscard", "logStatusError", "logStatusFatal", "logStatusPending", "logAll", "logFmi2Call"};

    // Set values for all variables that define a start value                                                                                     
    void setDefaultStartValues(ModelInstance *comp) {
        fprintf(stderr, "HeatConductorComplex_FMU.c start setDefaultStartValues() \n");
        fflush(stderr);

	fprintf(stderr, "HeatConductorComplex_FMU.c  calling fmi2SetDebugLoggin() \n");
        fflush(stderr);
        fmi2SetDebugLogging(comp, 1, 11, logCategoriesNamesAll);

If $PTII/bin/ptinvoke ptolemy.moml.MoMLSimpleApplication HeatConductorComplex.xml is run, then:

 FMU for model exchange or co-simulation: about to call HeatConductorComplex_fmiInstantiate
 HeatConductorComplex_FMU.c start setDefaultStartValues()
 HeatConductorComplex_FMU.c end setDefaultStartValues()
 FMULogger: status: 0 message: fmi2Instantiate: GUID=%s
 H.c end fmi2Instantiate()
 Done with fmi instantiate
 Warning, _debugListeners was null, which means that _debugging was set to true, but no listeners were added?
 Done with fmi instantiate
 Warning, _debugListeners was null, which means that _debugging was set to true, but no listeners were added?
 Called initialize()
 FMIImport.initialize() method called.
 Warning, _debugListeners was null, which means that _debugging was set to true, but no listeners were added?
 FMIImport.initialize() method called.
 H.c fmi2SetReal(): 1000,
 FMULogger: status: 0 message: fmi2SetReal: nvr = %d
 FMULogger: status: 0 message: fmi2SetReal: #r.16g
 HeatConductorComplex_FMU.c setReal(19, 1000)

However, we vergil is invoked on the same model:

 FMU for model exchange or co-simulation: about to call HeatConductorComplex_fmiInstantiate
 HeatConductorComplex_FMU.c start setDefaultStartValues()
 HeatConductorComplex_FMU.c end setDefaultStartValues()
 FMULogger: status: 0 message: fmi2Instantiate: GUID=%s
 H.c end fmi2Instantiate()
 Done with fmi instantiate
 Warning, _debugListeners was null, which means that _debugging was set to true, but no listeners were added?
 Done with fmi instantiate
 #
 # A fatal error has been detected by the Java Runtime Environment:

Where "Done with fmi instantiate" is from the end of FMUImport.preinitialize().

How to build an FMU from within OpenModelica

There are several ways to create a .fmu

The simplest way is to create a .mos file like exportFMU.mos:

  loadModel(Modelica, {"3.2.1"});
   getErrorString();
  loadModel(HeatConductor); getErrorString();
  OpenModelica.Scripting.translateModelFMU(
    className=HeatConductor,
    version="2.0");
   getErrorString();

and then invoke

  omc exportFMU.mos

To use the tearingMethod, use:

  omc +tearingMethod=noTearing exportFMU.mos

To use sparse:

  omc +s +simCodeTarget=sfmi exportFMU.mos

Using omc creates the modelDescription.xml file and binaries for one platform.

Using omc is the most reliable method, though the fmu that is produced will not work on other platforms.

Ptolemy II has an extension that builds a fmu at runtime. This extension runs "make platformName", where platformName is the fmu platform such as linux64 or darwin64.

Unfortunately, the location of the OpenModelica platform varies between installations. Under Linux, OpenModelica tends to be located in /usr/local/openmodelica. Under Mac OS X, when installed using MacPorts, /opt/local.

Thus, building OpenModelica fmus from within Ptolemy is fragile.

HeatConductor example.

Here's a full example

HeatConductor.mo contains:

Under RHEL 6, to create HeatConductor.fmu

fmuCheck

fmuCheck.csv contains:

Running fmuCheck -i fmuCheck.csv HeatConductor.fmu

2/20/2015 Note that this was fixed at some point

And it repeats.

This is what is similar to what Michael got with fmusdk_me

Using the OpenModelica test fmus

openmodelica/testsuite/openmodelica/fmi/ModelExchange/2.0 contains various .mos files that generate fmus and then import them.

  BouncingBall.mos        HelloFMIWorld.mos  testAssert.mos   testInitialEquationsFMI.mos
  HelloFMIWorldEvent.mos  Makefile           testBug2764.mos

The Makefile runs ../../../../rtest -v on each .mos file. It looks like rtest looks for directives in the comments of the .mos file and does set up and tear down.

Here's BouncingBall.mos:

If I run omc BouncingBall.mos, then BouncingBallFMI20.fmu is created and then imported, which creates BouncingBallFMI20_me_FMU.mo.

The BouncingBallFMI20.fmu can be loaded and run using BouncingBallFMI20_me_FMU.mo, see above for BouncingBall.mos

Noncompliance

2/19/20 - This was fixed at some point in the past

However, running fmuCheck on BouncingBallFMI20.fmu goes into the loop:

        [FMU][logFmi2Call][FMU status:OK] fmi2EventUpdate: Start Event Update! Next Sample Event 0
        [FMU][logFmi2Call][FMU status:OK] fmi2EventUpdate: Checked for Sample Events! Next Sample Event 0

So, it seems like the OpenModelica FMI-2.0 Model Exchange fmus are no compliant.

I tried fixing the possible bug involving eventInfo->newDiscreteStatesNeeded = fmi2False; but that did not change much.

I created a HeatConductor.mos that was similar:

and it reproduced the error message that Michael got:

OpenModelica VanDerPol crash

At some point the OpenModelica VanDerPol demo started failing.

To replicate:

Below is a sample crash, from 2015-04-01:

• 2015-03-29
  • HeatConductor was compiled and ran
  • LorenzAttractor ran very quickly
  • VanDerPol was not present, but copying from 2015-03-29 and running all three demos passed.
  • Running $PTII/bin/ptinvoke ptolemy.actor.gui.PtolemyApplication -run20x auto/VanDerPol.xml eventually crashes
• 2015-03-21
  • HeatConductor was compiled and ran
  • LorenzAttractor ran very quickly
  • VanDerPol crashed:
    # J 522 java.io.UnixFileSystem.getBooleanAttributes0(Ljava/io/File;)I (0 bytes) @ 0x00007f0098fc71a0 [0x00007f0098fc70c0+0xe0]
    

    [$[Get Code]]
  • Running $PTII/bin/ptinvoke ptolemy.actor.gui.PtolemyApplication -run20x auto/VanDerPol.xml eventually crashes
• 2015-03-29
  • HeatConductor was compiled and ran
  • Lorenz stopped in iteration 1 because the results changed
  • VanDerPol passed.
  • Interestingly, setting the trainingMode in LorenzAttractor to true and re-running then caused VanDerPol to crash. This points to a memory problem.
• 2015-04-01
  • HeatConductor was compiled
  • LorenzAttractor had training mode set to false
  • VanDerPol crashed in the second run

VanDerPol

Looking at the above analysis, it seems like VanDerPol.fmu has a problem.

1. Download and install fmusdk2:
   git clone https://github.com/cxbrooks/fmusdk2.git
   cd fmusdk2
   make
   cd fmu20/bin

   [$[Get Code]]
2. Run gdb
   [cxh@terra bin]$ gdb ./fmusim_me
   GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
   Copyright (C) 2010 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
   and "show warranty" for details.
   This GDB was configured as "x86_64-redhat-linux-gnu".
   For bug reporting instructions, please see:
   <http://www.gnu.org/software/gdb/bugs/>...
   Reading symbols from /home/cxh/src/fmi/fmusdk2/fmu20/bin/fmusim_me...done.
   (gdb) r /home/cxh/src/ptII2015-03-29/ptolemy/actor/lib/fmi/fmus/omc/test/auto/VanDerPol.fmu
   Starting program: /home/cxh/src/fmi/fmusdk2/fmu20/bin/fmusim_me /home/cxh/src/ptII2015-03-2\
   9/ptolemy/actor/lib/fmi/fmus/omc/test/auto/VanDerPol.fmu
   warning: File "/usr/local/gcc-4.9.2/lib64/libstdc++.so.6.0.20-gdb.py" auto-loading has been\
    declined by your `auto-load safe-path' set to "/usr/share/gdb/auto-load:/usr/lib/debug:/us\
   r/bin/mono-gdb.py".
   To enable execution of this file add
           add-auto-load-safe-path /usr/local/gcc-4.9.2/lib64/libstdc++.so.6.0.20-gdb.py
   line to your configuration file "/home/cxh/.gdbinit".
   To completely disable this security protection add
           set auto-load safe-path /
   line to your configuration file "/home/cxh/.gdbinit".
   For more information about this security protection see the
   "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
           info "(gdb)Auto-loading safe path"
   [Thread debugging using libthread_db enabled]
   cmd='unzip -o -d fmuTmpCTMcHr/ "/home/cxh/src/ptII2015-03-29/ptolemy/actor/lib/fmi/fmus/omc\
   /test/auto/VanDerPol.fmu" > /dev/null'
   Detaching after fork from child process 47182.
   fmiModelDescription
     fmiVersion=2.0
     modelName=VanDerPol
     guid={8c4e810f-3df3-4a00-8276-176fa3c9f9e0}
     description=Van der Pol oscillator model
   ModelExchange
     modelIdentifier=VanDerPol
   dllPath = fmuTmpCTMcHr/binaries/linux64/VanDerPol.so
   FMU Simulator: run '/home/cxh/src/ptII2015-03-29/ptolemy/actor/lib/fmi/fmus/omc/test/auto/V\
   anDerPol.fmu' from t=0..1 with step size h=0.1, loggingOn=0, csv separator=',' log categori\
   es={ }
   
   Program received signal SIGSEGV, Segmentation fault.
   0x00007ffff65267e2 in GC_find_limit_with_bound ()
      from /usr/local/openmodelica/lib/omc/libgc.so.1
   Missing separate debuginfos, use: debuginfo-install atlas-3.8.4-2.el6.x86_64 blas-3.2.1-4.e\
   l6.x86_64 glibc-2.12-1.149.el6_6.7.x86_64 libxml2-2.7.6-17.el6_6.1.x86_64 zlib-1.2.3-29.el6\
   .x86_64
   (gdb) where
   #0  0x00007ffff65267e2 in GC_find_limit_with_bound ()
      from /usr/local/openmodelica/lib/omc/libgc.so.1
   #1  0x00007ffff65268e2 in GC_init_linux_data_start ()
      from /usr/local/openmodelica/lib/omc/libgc.so.1
   #2  0x00007ffff6525352 in GC_init () from /usr/local/openmodelica/lib/omc/libgc.so.1
   #3  0x00007ffff651f809 in GC_generic_malloc_inner ()
      from /usr/local/openmodelica/lib/omc/libgc.so.1
   #4  0x00007ffff651f8ce in GC_generic_malloc ()
      from /usr/local/openmodelica/lib/omc/libgc.so.1
   #5  0x00007ffff767c40b in fmi2Instantiate ()
      from fmuTmpCTMcHr/binaries/linux64/VanDerPol.so
   #6  0x00000000004024ae in simulate (fmu=0x616a60, tEnd=1, h=0.10000000000000001,
       loggingOn=0, separator=44 ',', nCategories=0, categories=0x0)
       at model_exchange/main.c:75
   #7  0x0000000000403139 in main (argc=2, argv=0x7fffffffe578) at model_exchange/main.c:275
   (gdb)

   [$[Get Code]]

The same issue happens with the most recent VanDerPol.fmu in the ptII tree.

The next step is to update OpenModelica and try again.