export/interface Julia code to FMI/FMU standard .fmu

#1

Hi everyone,

I will start to build a modeling framework.
I have simulation models which are built with Modelica, some others with Simulink/Simscape Toolbox and finally I have a control system designs with Julia and package JuMP. The control system aims to regulates the behavior of systems models (the master piece of my case study).

I have seen the FMI standard [1] and .fmu which is suitable to co-simulate from different tools and I would like to use it. I haved uploaded a figure to illustrate it.

My question is :

Does a julia package exist to export julia code to .fmu standard ? Or does a FMU interface to my julia code exist?

Thanks for all your answers.
julialangpost|554x392

[1] https://fmi-standard.org/

#2

I haven’t run across anything. This post suggests interest in doing that, but I don’t see an followup work at Modelon. Julia is good at wrapping C code. You might have a look at wrapping FMILibrary. You could also try using PyFMI through Julia’s Python interface.

Maybe you could convert your Modelica models to Modia. You might also have a look at OMJulia, a Julia interface to OpenModelica.

#3

Thank for your answer and your links.

First of all, I have also a look here, where FMI import and export tools are listed. However according to the webpage, SimulatorToFMU is able to export pyhton script.

Second, I can convert the Modelica models to Modia, however I have also some models which are based on Simscape toolbox from Simulink. My constraint is to export julia script to .fmu, where the .fmu can be reutilised.

Third, I tried a different way. According to Dymola User Manuel page 407, external functions in orther languages is possible (C, C++, fortran and Java), and also link to DLL in this web page and of course Dymola user manuel page 412.

I tried to build a share library from my julia function with PackageCompiler.jl which it can be a external library in modelica/Dymola and, finaly export this modelica model with the external function in .fmu. It can be summarise as:

  1. Julia function : MyFunction.jl
  2. Build a share library from the julia function with build_shared_lib(".jl"): Myfunction.dll
  3. External functions linking with DLL inside one Modelica model: ModelicaModelWithExternalFunction.mo
  4. Export the modelica model with the linking DLL to .FMU: MyFMU.fmu

I have implemented the 4 steps. My trial julia function return the cab number:

Base.@ccallable function julia_main()::Cint
return 1729
end

Then, with REPL : build_shared_lib(“TaxiCabNumber.jl”). REPL wrote “All done”. The builddir is created, with the TaxiCabNumber.dll, however a large amount of other .dll are also there.

Then, I did my modelica.mo with external function. The modelica function is called add2bis (please note the julia_main) (I did like here case B):

function add2bis
output Real sum;
external “C” sum=julia_main() annotation (
LibraryDirectory=“modelica://TestFunctionExt2/Ressources/Library”,
Library=“TaxiCabNumber”);
end add2bis;

Then, I exported my modelica model (with add2bis call) to .fmu. My fmu is called TestfunctionsExt2.fmu. Dymola built the .fmu and I imported with simulink:
simulinkFMU

Then, I have run the simulation, and there was an error and simulation failed. I logged the FMU debug and I’ve got the following log:

Log From FMU: [category:, status:fmierror] Problem with loading TaxiCabNumber.dll

The .fmu is equiavalent to .zip, I have modified .fmu to .zip in order to have a look inside, and the two dll files are presents: TaxeCabNumber.dll and TestFunctionsExt2.dll.

I have the following questions:

  • Did I do some mistakes with the julia function according to PackageCompiler usage?
  • According to build_shared_lib, the generated library is called : buildir/libhello.{so,dylib,dll}. I do not understand the others files.dll from the buildir, what are their purpose? Also, what is the TaxiCabNumber.a?
  • Are there some limitations with the TaxiCabNumber.dll generated from build_shared_lib(“TaxiCabNumber.jl”)?

Thanks for all your answers. Warmest regards.

#4

Hi,

Faced with a similar problem (coupling a Python or Julia optimization-based control algorithm with a Modelica model), I’ve started exploring an alternative way: call the Python/Julia code from Modelica.
Since embedding the Python interpreter is complicated, I’ve used a client-server approach with a messaging between the two. The code is available at:

This code is certainly not finished, by I’ve a running demo of a simple Python thermal controller with a simple Modelica thermal model. In an ideal world, I would have finished this along with a nice descriptive article for Modelica 2019 conf, but this didn’t happen :frowning:

The Julia part is not started, but at least ZMQ.jl does exist (which is why I selected this messaging lib), while I had to do the low-level C code for the Modelica side (it would probably have been easy for somebody proficient in C, but this is not my case).

#5

Hello Pierre,

Thanks a lot for NumRPC.

I tried a different way from my last post. Instead of building a .dll file from my julia code, I used the build_executable("–.jl", “–”) from PackageCompiler.jl to build an exe file. The .exe file is called inside the Modelica external C function with: system("–.exe arg");

I did the same steps as discribed in last post with the exe file. It works, dymola allows external C function wich run the exe, and I can export my Modelica package to fmu. I simulated the fmu with Simulink and it works too.

Regards

#6

I wish a package for dealing with FMI/FMU for both import and import gets implemented someday also.

I think it would be a good selling point for Julia (in particular in industry -iaw fmi-standard.org it is supported by over 100 tools including Dymola, Modelica, Matlab and many others engineering tools-).

I have taken a look myself, but I feel I am not smart enough. :frowning:

At the end of the day, it looks like a zip file with a XML description file and the DLLs embedded. There seems to be C libraries for both import and export. So it looks like the blocks are nearly there.

Then just a stupid question just in case somebody knows (despite this is probably the wrong forum). Would it be a good idea to perform what fmi-standard tries to do in WebAssembly? I understand it is more “cross-platform” that FMU’s DLLs. Besides those “TaxicabNumber.a” and “TaxiCabNumber.dll” seem to be huge (>130Mb each) while exports to webassembly from julia seem to be tiny. Now even more when it looks like you don’t need to run it in a browser with things like life.