The compiler can't find the class `Ground` in scope.
That means there is no Modelica model / class named `Ground` loaded.

There are two ways to fix this:

- Create a new model named `Ground` with a connector for the pin (you are connecting to `G.n`) and the equation describing what ground should do (pin.v = 0).
Take a look at `Modelica.Electrical.Analog.Basic.Ground` from the Modelica Standard Library (MSL) how it is done in that case.

- Use a library that provides electrical components, e.g. from the MSL (4.0.0) `Modelica.Electrical.Analog`.

You will have the same issue for every other model/class you are using in your class `Simplecircuit1`. If you are using MSL you also have some typos in the connect equations

[...]

  connect(AC.p,R1.p);

[...]

The book "Modelica by Example" by by Dr. Michael M. Tiller gives a nice introduction to Modelica and also provides examples on object oriented modeling and simple electric examples similar to what oyu are trying to do in your model: https://mbe.modelica.university/

Check your working directory. The executable is (usually) not removed, so restarting the computer shouldn't matter. But I'm not super sure about what OMPython is removing after finishing simulating.

The other way would be to export an FMU and use a FMU simulation tool. See https://fmi-standard.org/

You can call the generatd simulation executable directly and just overwrite values / parameters or change other simulation options.

Assuming you have a model named `A` you have A.exe (on Windows) in your working directory. You can find simulation flags in the User's Guide: https://openmodelica.org/doc/OpenModeli … flags.html

I guess `-override=value` or `-overrideFile=value` is what you are looking for.

If you want to stick to the scripting API (callable from OMPython) you can use `buildModel(A)` to build the model once and then call the executable via subprocess package in Python.

OpenModelica is not yet at 100% coverage of the Modelica Standard Library (MSL).

For MSL v3.2.3 we currently are at 405 of 425 passing the verification, see https://libraries.openmodelica.org/bran … 3.2.3.html
Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation is one of the failing ones: https://libraries.openmodelica.org/bran … lation.sim

For  MSL v4.0.0 it's the same issue.

There exist a ticket about this on our GitHub. It seems that OpenModelica can't solve the initial system that uses the homotopy operator. But the ticket doesn't indicate why OpenModelica isn't able to do so.

Without seeing the log it is hard to tell what exactly went wrong. Can you include it here (run make with an additional `--output-sync` to have the log file readable).
What OS and version are you using?
What version (commit) of OpenModelica are you trying to build?

In the build-deps for openmodelica `qttools5-dev-tools` is listed, at least on my Ubuntu Focal. So you should have all needed QT libs and headers.

You could try to checkout all submodules to the version saved in the master branch:

git submodule update --force --init --recursive

Or pull the latest version of the master branch and all submodules.

The graph in the plot window of OMEdit is a interactive representation of the result file.
There the results are stored for each interval specified during simulation setup. Is this what you are after?

When simulating a model the result file location will be printed to the output log:

C:/Users/USERNAME/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/Filter.exe -port=58283 -logFormat=xmltcp -override=startTime=0,stopTime=0.9,stepSize=0.0018,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/Users/USERNAME/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/Filter_res.mat -w -lv=LOG_STATS -inputPath=C:/Users/USERNAME/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter -outputPath=C:/Users/USERNAME/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter

The initialization finished successfully without homotopy method.

So for my example above it is in "C:/Users/USERNAME/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/Filter_res.mat".
You can open the OMEdit working directory with Tools->Open Working Directory and then you'll find the result file in the directory named the same as your model.

By default the result file is a *mat file, but you can change it to csv as well. You can change this in the Simulation Setup Output tab under "Output Format".

Hey shunfan2,

Use a shell that has omc (OpenModelica compiler) in it's PATH to run the executable. You can start cmd with that from OMEdit->Tools->OpenModelica Command Prompt. If you want to re-compile it best to use OMDev (see https://github.com/OpenModelica/OpenMod … -MINGW.md), basically a Linux-like shell with all tools needed to compile.

Change directory to the place where your executable was generated. There are local files the executable needs.

Only use the simulation flags you need. You can find them in the User's Guide. In your example above you don't need the -port and -logFormat=xmltcp. The default values are okay, so dumping the log to stdout.

For example if I have simulated Modelica.Blocks.Examples.Filter from OMEdit I can change into the directory and run it again:

Start OpenModelica Command Prompt from OMEdit and run:

C:\Users\Username\AppData\Local\Temp\OpenModelica\OMEdit> cd C:/Users/Username/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/

C:\Users\Username\AppData\Local\Temp\OpenModelica\OMEdit\Modelica.Blocks.Examples.Filter> Filter.exe

LOG_SUCCESS       | info    | The initialization finished successfully without homotopy method.

LOG_SUCCESS       | info    | The simulation finished successfully.

Hey AndreasTh,

It's correct that our modelDescription.xml doesn't contain all source files. We should fix this at some point. I've created a ticket for it: https://github.com/OpenModelica/OpenMod … ssues/8524

From your error messages it seems that the FMU is compiling fine. A few errors are normal (we should really fix them though...)
Problem seems to be executing the FMU binaries.

You could you try a few things:

1) Try out the nightly build of OpenModelica (https://openmodelica.org/download/download-windows). I recently fixed a bug where source files for source-code FMUs where missing. But since your model compiles fine that's probably not the solution. (If you get errors for undefined `_hybrid` set `NEED_CMINPACK=1`

2) Use logging from Matlab. There should be an option to log each fmi function call. Then we can get at least a rough idea where it crashes.

3) Try a different FMU importing tool to simulate the freshly compiled FMU. E.g. OMSimulator which comes with OpenModelica. I guess it is a FMU problem, but with that we can be sure.

4) You can try to run the FMI Importing tool with a debugger. To enable debugging for the generated FMU you need to have `-g` or even better `-g -O0` in your `CFLAGS` when compiling. Then run e.g. OMSimulator with gdb. Probably works with Matlab as well, but I never tried and having all of a GUI through gdb is extremely slow.

$ gdb OMSimulator

r myFMU.fmu

But you should open an issue on our GitHub about this: https://github.com/OpenModelica/OpenModelica/issues/
If we can find the function (and line) that causes the issue we have a chance to fix it.
If your FMU is not a secret you can upload it to the issue as well. When it's not a Matlab issue I can run it through gdb.

It is the default setting anyway. In older versions no CVODE CS-FMU export is available.

But at least OpenModelica v1.18.1 (or newer) has this option to choose between Euler and CVODE.

pierreh wrote:

This post is just a pointer about the January 2022 situation of installing OpenModelica (e.g. OMEdit) on Ubuntu 21.10. I didn't see a Github issue to track this, should I create one?

Yes, please go ahead and open a ticket on our GitHub about this: https://github.com/OpenModelica/OpenModelica/issues

That sounds like a problem we want to fix before it affects a lot of users.
Your links are not working, can you post them again?

I added an issue for this on our GitHub: https://github.com/OpenModelica/OpenMod … ssues/8443

If you use a "normal" FMU you can change parameters with some fmi2SetXXX function. I'm not sure what is changeable in a black-box fmu, I guess basically nothing besides inputs.

I think it is possible for parameters to be inputs as well. At least OpenModelica doesn't issue a warning about it.

Maybe that works for you:

  parameter Real X1 = 200;

  parameter input Real R_ic = YY * 1 / X1;

  parameter Real YY;

  Modelica.Blocks.Continuous.FirstOrder firstOrder(T = 5, k = 1, y_start = R_ic);

A final parameter can't be modified. Because `RealInput YY` is of higher variability (it is allowed to change at simulation time) the value of `R_ic` would need to change if `YY` would change and that contradicts the final keyword.

Make `Component R_ic` and `YY` parameters and let the compiler handle it. You can still change the parameter `YY` from outside.
If variable `YY` is only needed at initialication the compiler will figure that out,use it only at the initialization system and remove it from the simulation system.

  parameter Real X1 = 200;

  parameter Real R_ic = YY * 1 / X1;

  parameter Real YY;

  Modelica.Blocks.Continuous.FirstOrder firstOrder(T = 5, k = 1, y_start = R_ic);

You can set "outputFormat" while calling simulate.

Here is a complete example:

>>> from OMPython import OMCSessionZMQ

>>> omc = OMCSessionZMQ()

>>> omc.sendExpression("getVersion()")

>>> omc.sendExpression("loadModel(Modelica)")

>>> omc.sendExpression("simulate(Modelica.Blocks.Examples.PID_Controller, outputFormat=\"csv\")")

Well that is correct, with DASSL/ IDA you can use the so called DAE mode. So it is possible to solve an differential-algebraic equation with index 1 instead of an ODE system.
In OpenModelica this is not the default behavior, but can be achieved that by using the compiler flag `--daeMode`. The simulation executables (generated equations) and the solver are different in DAE-mode. So adding those to FMUs would be an additional step.

I'm not sure if the FMI standard (2.0.3) allows DAEs at all. At least for model exchanges it is not:

The FMI for Model Exchange is for ordinary differential equations (ODEs) in state space form. It is
not for a general differential-algebraic equation system

Both DASSL/IDA and CVODE are variable-order, variable-coefficient BDF methods (for non-stiff systems CVODE can actually use a  Adams-Moulton formula).
I think for non-stiff problems CVODE could be the better approach and because of that CVODE is the default for our C++ runtime.

So there could be use cases where one method outperforms the other, but I don't think you say that one is better then the other in general. Searching for some publication could give some answer to that question.

But as I said, the work to implement IDA with daeMode into FMUs would be quiet high because the OpenModelica compiler needs to be changed in multiple places and we don't event support CVODE FMUs at 100%.

If all you need is execution speed and some specific solver for robustness I would ditch FMUs completely and use OpenModelica scripting, e.g. mos-scripts, OMPython or OMJulia. Then you have the more sophisticated runtimes, no FMI-overhead and it get's way way easier to debug.

Hey Lukas,

Currently there are two solvers available in CS-FMUS: Explicit Euler (default) and Sundials CVODE.

It would be possible to add more solvers to CS-FMUs. But what would be the benefit of Dassl / IDA(same algorithm, newer implementation) over CVODE?

It is a lot of work to add external solvers to FMUs because we want to support source-code FMUs as well and therefore need to add parts of our "normal" runtime to the FMU runtime and create new solver routines because our integrator works differently then a FMU simulator.

Hey @lucas_luo

For someone to be able to help you answer your questions more details are needed:

What does your Matlab model look like?
How did you export the FMU (which settings, which target, what FMI version, ME or CS, ....)?
How did you import the FMU in OpenModelica?
What version of OpenModelica are you using?
Did you try to import the FMU in other tools?

In addition a minimal working example is always great, so others can replicate your problem with a few clicks and check what the error could be.

I'm not sure, you might want to check your PATH variable. Or maybe OMSimulator wasn't installed/updated. Reinstalling could be an option. If that doesn't work as well you should open a ticket about it.

Hard to tell what exactly went wrong without seeing your model.

I would suggest to try simulating your Model.ssp with OMSimulator directly (without the Python layer in-between). Could be that the error is somewhere in OMSimulatorPython3 or that my Jupyter Notebook is no longer working (issues with CVODE FMUs or MSL4 vs MSL 3).

So use your shell and run

cd /tmp/OpenModelica_philgun/OMEdit/

OMSimulator Model.ssp

Source-Code FMUs with SUNDIALS are a nightmare to get to run on different OS and what and how to include into the FMU are not obvious.
I would suggest you create a new issue on GitHub and cc me in it (AnHeuermann). Then we can work on it there.

If possible we can improve OpenModelica to generate CVODE FMUs that are usable out of the box.

Arinomo23 wrote:

But on the init_fmu_c the solver mowthod is still defined as dassl. I will try if this work for my use case, since the FMU will be compiled from the source code by the tool to create real-time app for HiL test.

Of course in the importing tool you need to use CoSimualtion. OpenMoelica FMUs usually offer CS and ME.
You can verify that everything is running correctly by running the FMU you created with OMSimulator.

The output of the FMU should look something like for this random example:

OMSimulator QuarterCarModel.QuarterCarModel.fmu --mode=cs

LOG_SOLVER        | info    | CVODE linear multistep method CV_BDF

LOG_SOLVER        | info    | CVODE maximum integration order CV_ITER_NEWTON

LOG_SOLVER        | info    | CVODE use equidistant time grid YES

LOG_SOLVER        | info    | CVODE Using relative error tolerance 1.000000e-06

LOG_SOLVER        | info    | CVODE Using dense internal linear solver SUNLinSol_Dense.

LOG_SOLVER        | info    | CVODE Use internal dense numeric jacobian method.

LOG_SOLVER        | info    | CVODE uses internal root finding method NO

LOG_SOLVER        | info    | CVODE maximum absolut step size 0

LOG_SOLVER        | info    | CVODE initial step size is set automatically

LOG_SOLVER        | info    | CVODE maximum integration order 5

LOG_SOLVER        | info    | CVODE maximum number of nonlinear convergence failures permitted during one step 10

LOG_SOLVER        | info    | CVODE BDF stability limit detection algorithm OFF

info:    Result file: model_res.mat (bufferSize=10)

Arinomo23 wrote:

Another question, why is the fmu flag has to be set globally? it seems the like the export function does not look into model translation flag. I've mention it regarding the missing fmu attributes that also define in translation flag.

Yes that is not perfect. When implementing CVODE FMUs I only did it for the compiler via the scripting API, so it is not fully integrated in OMEdit yet.
I opened a ticket about this: https://github.com/OpenModelica/OpenMod … ssues/7920
Also note that the other

Check out the User's Guide on FMI Export. There is an example explaining how to export an Co-Simulation FMU with CVODE using the scripting API.

Basically you need to use the compiler flag

--fmiFlags=s:cvode

In OMEdit you can activate this by adding the translation flag in "Tools->Options", then navigate to "Simulation" and add "--fmiFlags=s:cvode" in the text field of "Additional Translation Flags".

I don't think that is currently possible. There is a simulation flag doing exactly that for log flags, but not for the results: -lv-time

I guess the best solution is to save all results in a CSV file and remove everything you don't need with your favorite tool, maybe Python scripting or something.

If you really need to have a flag similar to `-lvl-time` implementing it wouldn't be that hard, but you probably would need to do it yourself. (And the OpenModelica compiler and its runtime isn't that easy to get into).

If you are using Modelica Standard Library (MSL) version 3.2.3 the model is called `Modelica.SIunits.HeatFlowRate`, so it is the Model HeatFlowRate in package SIunits. That's probably the MSL version used in the video.
But you are probably using MSL version 4.0.0 (current default) where the SIunits package was renamed/moved to `Units.SI`. In that case you'll need to use `Modelica.Units.SI.HeatFlowRate`.

One way to find moved models while following the video would be to use the library browser to search for models in the loaded libraries. Another option is to use MSL 3.2.3. In OMEdit you'll need to open the options at `Tools->Options`, go to `Libraries ` and edit the system library `Modelica` to use version `3.2.3`.

Hey nimoror,

I'm not sure if you are mixing up Modelica (a programming language) and OpenModelica (a tool simulating models written in the Modelica language). But anyway, to answer your question:

OpenModelica itself is an open-source software project with a lot of different people working on it. So naturally one needs some tool to track changes and git is one of the most popular ones and really good at doing this. So our OpenModelica project is hosted on GitHub, one of several different platforms hosting git managed repositories.
If you or anyone is wanting to contribute to OpenModelica check out our contribution guidelines. But because OpenModelica is open-source anyone can contribute and not everyone needs to be an expert programmer. Finding and reporting bugs helps as well!

On the other hand there is the Modelica language and libraries written in Modelica. For example the Modelica Standard Library is quiet a big library that is developed by a lot of people, so they are using git and GitHub as well. You can browse through the files and check out how they are structuring the repository.

So for developing your own library you can save libraries in multiple files (In OMEdit: File->New->New Modelica Class; a dialog opens where you choose package and uncheck "Save contents in one file"), have packages in packages and with that getting a well structured system of .mo-files you can work with.
Together with git (hosted on GitHub or GitLab) and a working CI (GitHub Actions, GitLab CI, Jenkins, ...) you'll get a really nice repository you can work with a lot of people to develop a new awesome Modelica library.

And I would argue that this kind of development is more or less standard for software development nowadays.

Can you post a minimal working example of a model that worked under v1.14 and is not working under v1.18 any more?
Could be that is is just the difference between old and new frontend or that it is a bug.

Also the new description on graphical modeling with SSP in OMEdit is now life (at least in the OMSimualtor User's Guide): https://openmodelica.org/doc/OMSimulato … MEdit.html

Oh and by the way we created a tutorial on how to export/ import FMUs with OpenModelica and OMSimulator.
It can be found in our OpenModelica/OMTeaching GitHub repository.

Maybe a bit more then what you currently want to do, but could be a good starting point to get going. The tutorial was written using OpenModelica v1.17 but should work with the latest v1.19.dev as well.

I'm not sure how it worked in OpenModelica v1.14.2, but would suggest to use a recent version of OpenModelica, e.g. v1.18.0. At least if there are no reasons why you stick with v1.14.
The way you can import FMUs changed in recent versions.

For v1.18 / v1.19.dev there are two ways to import FMUs in OMEdit:

1) Import FMU via importFMU.
That is what is happening in OMEdit when you run `File->Import->FMU`.
It basically creates a new Modelica model that wraps the FMU. Problem is that this is not always working and the generated Modelica model is not legal Modelica code and OpenModelica will issue errors in some cases.
So yes, there is a serious bug in OpenModelica and it is not fixed yet.

2) Import FMU via OMSimulator through SSP.
Sadly the documentation isn't up to date there. I'll fix it, but it will take a day or so until the documentation online will be updated.

I would recommend the second way, even though it is more complicated to do at the moment, but at least it should work for most composite models.

Hey hopperj!

Yes, your are correct, new versions of OpenModelica will no longer support OSX.
And yes, compiling OpenModelica by yourself can be a pain, especially on OSX. Because that and that we don't have many OSX users the amount of time and resources needed to keep OpenModelica working on OSX is to high for us developers.

If an VM is not an option for you, you could try OpenModelica version 1.16. To be honest, I'm not sure if that version runs on recent macs.

Hey TimSchim2!

What tool are you using to simulate the FMU and what size are your communication intervals?
Is time=1 the stopTime for the simulation? The error suggests that `communicationStepSize` for fmi2DoStep is so small that CVODE is complaining. But you should get an error message if the step size is below 1e-13. Can you post the complete error message?

By default the Sundials packed with OpenModelica (v1.17.0) is used and compiled/copied into the FMU, which is version 5.4.0.
Maybe (but I hope unlikely) the simulation is using the wrong CVODE from your OS. You could try to run the the FMU on a system without sundials installed or in a docker image or by uninstalling sundials. But maybe messing with your system is not my best idea.

Are you able to share the Modelica model and the FMU that shows this problem? If not public you can send them to us via email: OpenModelica@ida.liu.se

Best
Andreas

My first guess:
You need to declare what `SI` is by using

import SI=Modelica.Units.SI;

This could be done in some other place in the MSL example.

If that is not the problem where did you copy the code from?
The error you are describing could be related to the version of the Modelica Standard Library (MSL). Maybe the version where you copied from doesn't match the version you have in OpenModelica, which is using MSL 4.0.0 in your case.

In MSL 4.0.0 the SI units are in

Units.SI

while in the previous MSL 3.2.3 they where in

SIunits

I've tried it with your example and when you enable event logging (LOG_EVENTS) you can see that combiTImeTable introduces events. And for each event a result before and after the event (at the same time point) is stored. If you want to suppress this use the simulation flag -noEventEmit.

I guess that the last row is duplicated is because at the end of the simulation an event iteration is done. So OpenModelica will store the values previously and after that event iteration. If nothing changes one could of course store only one time point.

Can you provide a minimal working example for the second case you are describing? I think that could be considered a bug, so opening an issue about it should be a way to get this changed: https://github.com/OpenModelica/OpenMod … new/choose

I would suggest to use OMSimulator to simulate a FMU. To do this from OMEdit check the user's guide for documentation: https://openmodelica.org/doc/OpenModeli … -modelling
Scripting is available as well, e.g. from Python, Julia or OMShell, see https://openmodelica.org/doc/OpenModeli … scripting.

The FMI import importFMU() from OpenModelica is kinda wonky.

Also there are different ways to export an FMU. Can you tell us how you generated the FMU? The modelDescription.xml in your FMU is very short and missing stuff I would expect to find there. Maybe because it is an 1.0 FMU(?), so then I would strongly comment to use FMI 2.0 for export.

You can generate source code FMUs that can be compiled on any system, at least in theory. When using more features of OpenModelica it get's more complicated.

The C source files generated by OpenModelica will need some dynamic or static libraries to work. If you want to link some SUNDIALS libraries into the executable to use CVODE you will need either a dynamic/static library for the target system or add all sources of SUNDIALS to compile it on your target system. There are some configure and makefiles in the source directory of the FMU you would need to adapt.

I guess the best way to use FMUs with CVODE on a system you can't generate binaries from the generating OS, is to compile/install CVODE on the target system and link dynamically. But in any case it is not straight forward and only applies to you if you need source code FMUs.

What step size is your FMU simulation tool using? My guess: It is bigger then 0.01.

Be aware that the internal integrator for a Co-Simulation FMU defaults to an explicit Euler method, which could be a non-optimal choice for this model, it appears to be stiff. Because of that every explicit method for this example is a bad choice:
Compare what happens for an explicit and implicit Euler method for step sizes = 0.005, 0.01 and 0.015. The implicit methods are stabilizing, while the explizit method will explode for too big step sizes. This bad behavior should be visible for every explicit method when the step size is above some critical value.

So you have two options:
1) Export an Co-Simulation FMU with a better (implicit) integrator. You can use Sundials CVODE for OpenModelica FMUs, see the user's guide on fmi-export.
2) Export an ModelExchange FMU and implement a decent integration method in the FMU simulation tool (e.g. CVODE as in OMSimulator or IDA as in OMEdit).

You can call the functions for getting and setting variable values, see FMI Standard 2.0.2 section 2.1.7 Getting and Setting Variable Values. I guess most FMI simulation tools will have a similar function to use the fmi2GetXXX functions.

If you are using OMSimulator with the Python interface you can do something similar to this example:

from OMSimulator import OMSimulator



oms = OMSimulator()

oms.setTempDirectory("./temp/")

oms.newModel("model")

oms.addSystem("model.root", oms.system_sc)



# instantiate FMUs

oms.addSubModel("model.root.system1", "FMUs/System1.fmu")

oms.addSubModel("model.root.system2", "FMUs/System2.fmu")



# add connections

oms.addConnection("model.root.system1.y", "model.root.system2.u")

oms.addConnection("model.root.system2.y", "model.root.system1.u")



# simulation settings

oms.setResultFile("model", "results.mat")

oms.setStopTime("model", 0.1)

oms.setFixedStepSize("model.root", 1e-4)



oms.instantiate("model")

value, status = oms.getReal("model.root.system1.x_start")



oms.initialize("model")

oms.simulate("model")

oms.terminate("model")

oms.delete("model")

Compare with the documentation of OMSimulatorPython.

Not really. You should open a ticket about it https://github.com/OpenModelica/OpenMod … new/choose and ask for it to be implemented. Add me (AnHeuermann) to the ticket. I'll probably be the one to implement it, but I can't promise to do it anytime soon.

There are ways to hack something into the FMU but I would not advise in doing that. It would be faster to update fmu_read_flags.c.inc to parse more simulation flags (e.g. initialStepSize in this case) anyway.
So the fastest solution would be to do it yourself (and create a pull request), but I know that's not very helpful.

marcelot wrote:

[CVODE ERROR]  CVode tout too close to t0 to start integration.

That's an error message from SUNDIALS CVODE.
What the CVODE documentation says about it:

CV_TOO_CLOSE The initial time t0 and the output time tout are too close to each other and the user did not specify an initial step size.

marcelot wrote:

So, is there a way to pass additional arguments to CVODE solver at the moment we generate the FMU? For example, an argument for enabling the internal root finding method?

Currently not. It was planned to do that at some point but there is no one working on it at the moment.


By the way:

--fmiFlags=nls:hybrid

isn't doing anything. The documentation is not very good on that.
So

--fmiFlags=s:cvode

is enough.

You can use your normal OpenModelica if you have Docker installed.

If you want to create a 32bit Linux FMU you need to set

platforms={"i686-linux-gnu docker run docker.openmodelica.org/build-deps:v1.13-i386"}

This will download the latest docker image docker.openmodelica.org/build-deps:v1.13-i386 and compile the binaries for the FMU inside the container.

Currently there is no dialog option for this in OMEdit though, see ticket https://trac.openmodelica.org/OpenModelica/ticket/6009.
You can create a mos script exportFMU.mos to generate your FMU, something like

loadModel(Modelica,{3.2.3}); getErrorString();

loadFile("path/To/Your/File.mo"); getErrorString();

translateModelFMU(ModelName, version="2.0", fmuType="me", platforms={"i686-linux-gnu docker run docker.openmodelica.org/build-deps:v1.13-i386"}); getErrorString();

and execute it with omc

$omc exportFMU.mos

Hey thomaskurz,

this thread is already 5 years old and somewhat off-topic. You should probably start a new one.

But while we are here:
We will drop support for FMI 1.0 for OpenModelica because:
a) It never worked as intended in OpenModelica
and
b) It is out of date and not supported by that many tools. FMI 2.0 is the current standard supported by more tools and FMI 3.0 is already available in an alpha release.

Also, as you noticed, the FMI import changed in OMEdit. It is not longer possible to import FMUs as Modelica models. They were no legal model and the new Frontend doesn't work with them. We want to add some way so users can link FMUs with Modelica models, but at the moment you have to export your other Modelica models as FMUs and link those up in a composite model (SSP).

So my advise:
Targeting FMI 2.0 (or even 3.0?) could be a better plan for your go FMU. If your model works as a 2.0 CS FMUs with OMSimulator you should stick with that, we will keep supporting FMI 2.0 for a while.

See for example the Dockerfile we generate for OpenModelica + Jupyter Notebook: https://github.com/OpenModelica/jupyter … Dockerfile

But basically you do exactly the same as when installing OpenModelica inside your Linux. To get a feeling just start to run a docker container like ubuntu:focal with a shell and follow the Linux install instructions for OpenModelica (https://openmodelica.org/download/download-linux).

$docker run --rm -it ubuntu:focal bash

If you want GUI support inside your docker container you have to hack a bit more (hint: ENV DISPLAY=host.docker.internal:0.0 and a configured XServer on your host system).

You seem to be quite new with Modelica and OpenModelica. The book Modelica by Example from Dr. Michael M. Tiller gives a good introduction to Modelica and answers most questions you may have.

Hej lisboalex02,

There are multiple ways of exporting Modelica models as FMU from OMEdit. I will restrict myself to the C FMUs here, but you can do most of this (but not all) for C++ FMUs as well.

If you just go File->Export->FMU you will get a 2.0 FMU with ModelExchange (ME) and Co-Simulation(CS) an an explicit Euler as integrator.
If you want to change some FMU export settings you can use the Options from Tools->Options->FMI to export e.g. only a CS FMU and for a specific platform.

When you use the scripting commands `buildModelFMU` or`translateModelFMU`, seeOpenModelica Scripting API, with the OpenModelica Compiler CLI from OMEdit you have more options.

But if you want to change the internal integrator for a CS FMU you have to use the Compiler Flag `--fmiFlags=s:cvode`. Please note that this feature is very new and currently the only setting you can change is the internal integrator used for `fmi2DoStep`.
You can pass it with the CLI

>setCommandLineOptions("-d=newInst --fmiFlags=s:cvode")

true

>buildModelFMU(Modelica.Electrical.Analog.Examples.CauerLowPassSC,"2.0","cs")

"C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Electrical.Analog.Examples.CauerLowPassSC.fmu"

You will get outputs from the FMU if you simulate if with CVODE to hint that it worked. Of course only if PyFMI will display outputs from the FMU that are displayed in stdout. They should look like this:

# OMSimulator Modelica.Electrical.Analog.Examples.CauerLowPassSC.fmu

[...]

LOG_SOLVER        | info    | CVODE linear multistep method CV_BDF

LOG_SOLVER        | info    | CVODE maximum integration order CV_ITER_NEWTON

LOG_SOLVER        | info    | CVODE use equidistant time grid YES

LOG_SOLVER        | info    | CVODE Using relative error tolerance 1.000000e-06

LOG_SOLVER        | info    | CVODE Using dense internal linear solver SUNLinSol_Dense.

LOG_SOLVER        | info    | CVODE Use internal dense numeric jacobian method.

LOG_SOLVER        | info    | CVODE uses internal root finding method NO

LOG_SOLVER        | info    | CVODE maximum absolut step size 0

LOG_SOLVER        | info    | CVODE initial step size is set automatically

LOG_SOLVER        | info    | CVODE maximum integration order 5

LOG_SOLVER        | info    | CVODE maximum number of nonlinear convergence failures permitted during one step 10

LOG_SOLVER        | info    | CVODE BDF stability limit detection algorithm OFF

[...]

By the way, the Integrator method only applies to a CS FMU. ME FMUs don't have one, since the master algorithm has the integrator, in your case PyFMI.

DASSL is also an integrator method, but only available for Modelica model simulations. The linear and non-linear solvers on the other hand are used to solve internal algebraic equation systems. Currently you can't change them.

But since I don't have your FMU I can only guess why it is not working for you, but I guess a step size of `dt = 0.5 #simulation step` is a bit to big. Try reducing it. Since you only used the default CS FMU you have an explicit Euler step that is very large for a problem that could be hard to solve.

> Is it OK to work with  OMCompiler v1.17.0-dev.224+g4c291412fa ??
Well, it's a nightly build, so there can always be some bugs introduced in that specific version.

But I doubt that the problem you are describing is specific to that commit. We will see what will happen with the example.

hanshell, I need more info to reproduce your issue.
I can't reproduce the segmentation fault. Can you provide a minimal working example?
Please add it to the ticket https://trac.openmodelica.org/OpenModelica/ticket/6275

Thanks for finding this bug. We are always happy to get bugs reported, so we can fix them.
You can report bus in our OpenModelica GitHub or on Trac (but the Trac will be depreacted soon).

We updated SUNDIALS to a newer version and a lot of API calls changed. And apparently the daeMode didn't got tested enough to find all problems.
I broke it, so I guess I have to fix that as soon as possible.

I opened a ticket on Trac for this one: ticket#6275

Otherwise make sure you have the Modelica library loaded. It should be visible in the left side in OMEdit in the Libraries Browser.
When you start OMEdit you should see something like

[1] 16:33:59 Scripting Notification

Automatically loaded package Complex 3.2.3 due to uses annotation.



[2] 16:33:59 Scripting Notification

Automatically loaded package ModelicaServices 3.2.3 due to uses annotation.

in the message browser in the bottom part of OMEdit.

Oh and for MSL 4.0.0 SIunits got renamed:

Modelica.Units.SI.Mass

You have a typo in the name, its

Modelica.SIunits.Mass

Usually the names of models are starting with a capital letter.

See chapter 3.10.3 Naming Conventions of Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems by Peter Fritzson about naming conventions.

• Type and class names (but usually not functions) always start with an uppercase letter, e.g., Voltage.
• Variable names start with a lowercase letter, e.g., body, with the exception of some one-letter names such
as T for temperature.
• Names consisting of several words have each word capitalised, with the initial word subject to the above
rules, e.g., ElectricCurrent and bodyPart.
• The underscore character is only used at the end of a name, or at the end of a word within a name, often to
characterise lower or upper indices, e.g., body_low_up.
• Preferred names for connector instances in (partial) models are p and n for positive and negative connectors
in electrical components, and name variants containing a and b, e.g., flange_a and flange_b, for other kinds
of otherwise-identical connectors often occurring in two-sided components.

Just add

apt-get install -qy openmodelica omlib-modelica-3.2.3 omlib-modelicareference

to your Dockerfile.

For comparison you can find my image on DockerHub: /hub.docker.com/repository/docker/anheuermann/openmodelica/general

Really cool! I did a similar thing some time ago without the webhost using an XServer. So you can actually use copy&paste in OMEdit, resize the Window and so on and there is no difference to a normal app started.

Your image is working fine on Windows with WSL2, but apparently ModelicaReference is missing.

Also you can probably reduce the size of your image by removing var/lib/apt/lists and do a apt-get clean.
This Code is for Ubuntu, but is probably working for Xubuntu as well.

RUN rm -rf /var/lib/apt/lists/* \

  && apt-get clean

Are you on a Windows OS?
I remember, that the last time I tried system didn't return any output on Windows, at least from mingw shell.

You have to add an output file to get the output of the system command.
See system from the Scripting API.

Similar to system(3). Executes the given command in the system shell.

impure function system
  input String callStr "String to call: sh -c $callStr";
  input String outputFile = "" "The output is redirected to this file (unless already done by callStr)";
  output Integer retval "Return value of the system call; usually 0 on success";
end system;

For your example you probably want to do something like:

system("./model", "outPutFile.log"); getErrorString();

PS: There is a function to read files called readFile.