I found some hints in the ChangeLog for Release 1.9.3:

* commit 38887f3d8797613c8a7dd6d096f8124597182d4a
| Author: hudson <openmodelica@ida.liu.se>
| Date:   Mon Jun 29 15:44:34 2015 +0200
|
|     * OMCompiler 48def8b...e234aa1 (4):
|       > Fixed FMU2-Errors. Static member FMU2Wrapper::logCategory is now FMU2Wrapper::LogCategoryFMU
|       > Logger for CPP-Runtime updated
|       > - added boost::atomic to windows cpp-runtime-build
|       > - replaced boost_log with logger-class of cpp-runtime - moved the implementation of StaticNonLinSolver-, StaticLinSolver- and StaticSolverOMCFactory to code files (because otherwise we are not able to disable cvode and kinsol for FMU export, easily) - FMU is now using Newton instead of Kinsol by default - FMU has no dependencies to sundials anymore

Later posts in the Changelog give the hint that there are some switches that can be passed to the FMU generation process:

* commit 78fbad2b7b5b97a97717ee4ce6a7551f914123aa
| Author: Marcus Walther <marcus.walther@tu-dresden.de>
| Date:   Mon Jul 27 14:14:23 2015 +0200
|
|     * OMCompiler 810476f...d9b26e6 (1):
|       > - Kinsol can now be used for FMUs, by passing a parameter to cmake - added some logger output to the kinsol and newton solver


Can anyone please give me advice where to pass the parameters to the generation process.

Hi,

What version of OpenModelica are you using?
If you take the latest nightly-build this should be fixed:
https://build.openmodelica.org/omc/buil … ly-builds/

Note that some of the commits comments are for the CPP runtime that you can activate with +simCodeTarget=Cpp.
By default we use the C runtime in which we fixed this issue.

Cheers,
Adrian Pop/

Hello Adrian,

thank you for the quick reply. I just tried out the latest nightly build. Now the Export seems to work. At least the FMUChecker doesn't throw any errors. Unfortunately the import into Simulink doesn't work. Now the toolbox gets the error of "forbidden access to memory area". Maybe a have to search for the next link in the chain...

Best regards
Andreas

Unfortunately I have no access to Simulink with FMI Toolbox to test this.
The import doesn't work or the actual simulation?
Is it the 64bit version of Simulink?

I got the same behavior with Matlab 2013b and FMI Toolbox from Modelon as well as Matlab 2015a an the Pilot Support Package from Mathworks (the planned native FMI support from Simulink). Both were the 32-bit versions. That would lead to the next question about the 64-bit support for the windows. But this is perhaps better done in a separate thread.

The error occurs when I start the simulation. Importing the FMU is no problem. I have not tested importing my FMU into Dymola. I hope I can get a copy in the next days. Maybe there is a similar problem as you mention in the Makefile that Dymola is not yet supported.

Hey Andreas,

I think there is a dependency issue in OpenModelica-exported fmus. Could you try replacing the libgfortran-3.dll (zipped in the FMU) with this one:
http://sourceforge.net/projects/scrpg/f … irror=iweb

-dchneric

Hello dchneric,

thank you for your answer. This solved my problem. The import of the generated FMU in Simulink works. Is this a known problem and is this fixed in newer builds of OpenModelica? I'm currently using OpenModelica v1.9.4-dev-111-g56804f2.

Is there a way to exchange the libgfortran-3.dll to make this workaround a permanent solution to the problem?

Best regards
Andreas

I just changed libgfortran-3.dll in the subfolders /bin and /MinGW/bin with the version dchneric supposed and FMU export works out of teh box now.

Very weird that  libgfortran-3.dll is to blame.
The library is copied from the mingw gcc 4.4.0 suite that we have.
dchneric, do you have more details about what dependency issues are there?

In the meantime we worked on reducing the FMU dependencies and we can now build a source code FMU that can be compiled on mostly any platform that has a C compiler. This is not yet integrated with OMEdit but we will do that soon.
You can use this with the latest nightly-build:
https://build.openmodelica.org/omc/buil … ly-builds/
via a script.mos containing:

setCommandLineOptions("-d=buildStaticSourceFMU"); getErrorString();

loadModel(YourLibrary); getErrorString(); // load the library needed

loadFile("Model.mo"); getErrorString(); // load the .mo file with the model if needed

translateModelFMU(Model); getErrorString(); // generate the FMU

Then call omc on the script.mos

C:\OpenModelica\bin\omc.exe script.mos

Cheers,
Adrian Pop/

Hello Adrian,

the FMU Export works for the latest nightly build (v1.9.4-dev-337-g300f04e) with OMEdit. Your effort in reducing the dependencies for the generated FMU is very useful when including the generated FMU on realtime platforms like dSpace. Is this also one step towards support of 64bit Windows FMU target?

Unfortunately I can't get to work your solution for generating FMUs via the scripting engine. There are only few file generated (FMUTest.libs, FMUTest_FMU.libs, FMUTest_FMU.log, FMUTest_FMU.makefile, FMUTest_info.json). Some of them are empty.

Best regards,
Andreas

I suspect buildStaticSourceFMU doesn't work on Windows even though the tests says it works (could be that one of the Windows tests doesn't clean everything up, and then the source test works even though it is using files from the non-source test).

Hi Adrian,

http://pedump.me would be helpful to see the difference between these two DLLs.
I suspect simulink links against a different msvcrt.dll (or something alike) than the one libgfortran-3.dll was compiled with in mingw. (dll hell deja-vu?)

-dchneric

We're now supporting 64 and 32 bit OpenModelica and FMUs in the latest nightly-builds:
https://build.openmodelica.org/omc/buil … ly-builds/

Hi,

sorry for the intrusion. I'm a new user of OpenModelica. I read that you use Modelon to make co-simulation with Simulink. I'm very interested to do it and I would like to have from you some advise.Do FMU files generate from OpenModelica work well into Simulink? Do you recommend I use Modelon?

Thank you,

Best regards,

Giuseppe

Hello Giuseppe,

I just made some tests with the Modelon FMI Toolbox to do model exchange (not Co-Simulation). Because of the unavailability of a 64-bit Version of OpenModelica at that time I used Dymola with the Dymola block in Simulink. My tests with the 32-bit Version were successful. First there were some problems with DLL dependencies (that's why I created this thread) but they are fixed now. Since Matlab 2015a you can use a so called Pilot Support Package from Mathworks to use FMUs in Simulink. You have to ask the Mathworks support for the download link. This package also worked in my tests.

Best regards,
Andreas

Hi Andreas,

Thank you for your reply. I will evaluate which solution is better.

Best regards,
Giuseppe

Hi,

I've installed the latest nightly-builds, but it still gives me dll problems in the Modelon checker. I'm using the 64-bit version. I'd like to know how to solve this problem.

Best regards,

Giuseppe

Hi,

I've noted that the problem arise when I use OpenHydraulics library. In particular the checker gives me a system error and it says: impossible to run the program because libhdf5-0.dll is not in the computer. If I don't use this library the checker does not give me any error. I hope you can help me.

Thanks,
Best regards

Giuseppe

Maybe we could add libhdf5-0.dll to the fmu. Which example from the OpenHydraulics library gives you trouble? Or you have your own model based on that library?

If you use the "source" export instead of "dynamic", there should be no dll dependencies for the FMU.

Thank you for the quick reply. Where I can set it? In "Strument" I don't found it.

adrpo, I've done a simple hydraulic circuit with two tanks and one checkvalve and it dows not work, but the development tests work.

@sjoelund.se, I don't think that building from source works on Windows, I have to check that.

@Giusto: you can try to include libhdf5-0.dll in the FMU yourself and see if is working.
The fmu is basically just a zip, you unzip it, you add these libraries to the binaries\win64 folder, then you zip it back again.
You need to add these libraries in the fmu:
OpenModelica\tools\msys\mingw64\bin\libhdf5-0.dll
OpenModelica\tools\msys\mingw64\bin\zlib1.dll
OpenModelica\tools\msys\mingw64\bin\libszip-0.dll

If you have a 32 bit FMU then you add to binaries\win32 folder:
OpenModelica\tools\msys\mingw32\bin\libhdf5-0.dll
OpenModelica\tools\msys\mingw32\bin\zlib1.dll
OpenModelica\tools\msys\mingw32\bin\libszip-0.dll

Cheers,
Adrian Pop/

adrpo wrote:

@sjoelund.se, I don't think that building from source works on Windows, I have to check that.

If it doesn't work, the Linux version can export 64-bit Windows FMUs without dependencies (and also without support for ModelicaExternalC, ModelicaStandardTables).

@adrpo: as you said I've included libhdf5-0.dll in the FMU. Now there is no error about dll, but there is another error: "Error in FMU version detection".
I've done some proof and I found out that the problem is the CheckValve block, in fact the fmu file generated by the DevelopmentTests, CheckValveTest, has exactly this problem. Moreover if I eliminate the CheckValve from my project, it works.

Thanks for your help!

Hi,

I've noted that the problem in really is in the "CombiTable1D" block. Moreover, when I include libhdf5-0.dll in the FMU, I have this error: "Unpacking of FMU d:\users\.... into d:\users\.... failed". Can you help me please?

You could try the latest nightly build:
https://build.openmodelica.org/omc/buil … lds/64bit/
as we now include the dlls I talked about above in the Windows FMUs.
See also ticket:
https://trac.openmodelica.org/OpenModelica/ticket/3946

Cheers,
Adrian Pop/

Now it works.

Thank you. I'm very grateful.

Kind regards,
Giuseppe

Hello, I am also having problems with dependencies exporting fmu from OpenModelica.

I have exported a fairly simple model that uses a 2D lookup table, using OMEdit, with the options fmi 2.0, Model Exchange and Co-Simulation, static; in order to use it in a Cpp project with the fmi-library.

First I tried with the release version 1.13, but I got somme libraries dependencies. I can run the fmu in a computer with OpenModelica installed, but I need to do it in an other one, so I should fix those dependencies.

I read they migth have been improved in the nigthly build 1.16, and even it is true that I didn't get the dependencies, I still get undefined symbols when I try to load the .so.

Using 'ldd -r mdl.so' to check the dependencies I got the following message:

    linux-vdso.so.1 (0x00002aaaaaaae000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaaaad5c000)
    /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
undefined symbol: ceil    (./Pwp_fmu.so)
undefined symbol: pthread_getspecific    (./Pwp_fmu.so)
undefined symbol: ModelicaStandardTables_CombiTable2D_close    (./Pwp_fmu.so)
undefined symbol: pthread_key_create    (./Pwp_fmu.so)
undefined symbol: ModelicaStandardTables_CombiTable2D_getValue    (./Pwp_fmu.so)
undefined symbol: ModelicaStandardTables_CombiTable2D_maximumAbscissa    (./Pwp_fmu.so)
undefined symbol: ModelicaStandardTables_CombiTable2D_minimumAbscissa    (./Pwp_fmu.so)
undefined symbol: pthread_setspecific    (./Pwp_fmu.so)
undefined symbol: trunc    (./Pwp_fmu.so)
undefined symbol: ModelicaStrings_skipWhiteSpace    (./Pwp_fmu.so)
undefined symbol: ModelicaStrings_length    (./Pwp_fmu.so)
undefined symbol: fmax    (./Pwp_fmu.so)
undefined symbol: pow    (./Pwp_fmu.so)
undefined symbol: sqrt    (./Pwp_fmu.so)
undefined symbol: ModelicaStandardTables_CombiTable2D_init2    (./Pwp_fmu.so)
undefined symbol: floor    (./Pwp_fmu.so)

Any clue on how to solve this problem?

Thank you in advance!

This is a known bug: https://trac.openmodelica.org/OpenModelica/ticket/5263
and we don't have a fix for it yet. On Windows we compile a static version of ModelicaExternalC, but not on Linux.
So if you have tables in your model, you will have this issue.

You could try to select the C++ runtime, maybe that one can compile a static version of the FMU without any dependencies but it might not work.