You typed wget -0- (zero), but should have used wget -O- (the letter O as in output).

C identifiers may not start with numbers. Neither may Modelica identifiers, but I guess you set a custom fileNamePrefix? Please report the bug at https://trac.openmodelica.org/OpenModelica/newticket

https://openmodelica.org/doc/OpenModeli … eter-sweep

I don't really know thermal modeling, but these are all physical connectors with potential and flow. So if you want to make the flow different to the different components, don't you simply add the equivalent of a resistor to do this? Then the temperature will naturally flow towards the least resistance.

You need to use connect-statements on connectors. If you manually set them equals, zero-flow equations will automatically be generated for unconnected components.

Note that if you do not use connect() statements, you get implicit flow=0.0 added. So always connect connectors instead of manually adding equations for them.

Did you try to simulate the model? That should give the following message:

Error: Too many equations, over-determined system. The model has 116 equation(s) and 114 variable(s).

[/home/marsj/tmp/a.mo:45:3-45:39:writable] Warning: Equation 93 (size: 1) flange.f = p1.flange.f - p2.flange.f is not big enough to solve for enough variables.

  Remaining unsolved variables are: 

  Already solved: flange.f, p1.flange.f, p2.flange.f

  Equations used to solve those variables:

    Equation 94 (size: 1): flange.f = 0.0

    Equation 97 (size: 1): p1.flange.f = 0.0

    Equation 104 (size: 1): p2.flange.f = 0.0

I created a ticket at the Buildings github repository for this: https://github.com/lbl-srg/modelica-bui … ssues/1171

https://openmodelica.org/doc/OpenModeli … ile-format

You can also choose CSV output if you prefer a textual format. Or you can use the OM API to read result-files, for example using:
https://openmodelica.org/doc/OpenModeli … tionresult

You start the simulation by writing to the step or run variables in the OPC interface.

OpenModelica can only simulate with time as the x-axis. You can plot with another variable on the x-axis using "New parametric plot windows" in OMEdit though.

You can find the libraries here: https://build.openmodelica.org/apt/pool/libraries/

You can build your own deb-files from https://github.com/OpenModelica/OMLibraries (`make debian` once you setup the locations of the deb-packages and files for apt-ftparchive).

This is because some newer Java versions fail to compile the files. The latest nightly build does not have this problem and you can resolve the issue by removing the offending line from omc-java.install (you usually don't need the jar-file and you could use https://github.com/OpenModelica/OMJava instead if you do need it)

You should just need to install the latest nightly build. Otherwise you can do File->Open and browse to /usr/lib/omlibrary/XXX/package.mo and open that to load the library (it's only the libraries entries that are a bit broken with newer Qt; before the fix).

This is fixed in https://github.com/OpenModelica/OMEdit/pull/165 (broke due to change in the Qt library)

Undefined symbols for architecture x86_64:
  "_ATL_dger", referenced from:
      _ATL_dgetf2 in liblapack.a(ATL_dgetf2.o)
  "_ATL_xerbla", referenced from:
      _atl_f77wrap_dgesv_ in liblapack.a(ATL_f77wrap_dgesv.o)

You have libatlas installed and not lapack. Atlas doesn't link with the standard lapack flags.

There are many expected errors in the config.log. I would need to see the whole file (preferably uploaded somewhere like on https://gist.github.com/)

OMPython and OMShell are the same. You use the same commands with them.

murrayE wrote:

What would the actual name of that log be?

OMCompiler/config.log

If you don't want to use buildModel and run the simulation yourself (or ModelicaSystem to wrap around that):

omc.sendExpression('simulate(HelloWorld, simflags="-override a=3.0")'

(Or using -overrideFile if you have many overrides, especially on Windows)

https://github.com/OpenModelica/OMSimulator - it's an external tool for FMI co-simulation

The OMCompiler config.log probably contains the linker error for lapack/blas

If you're not using the TLM method, you are probably better off using Adams- and OpenModelica-generated FMI 2.0 FMUs with OMSimulator.

https://github.com/OpenModelica/OMCompi … full-guide always worked for me

I suppose the error might be higher up in the logs (try with git clean in 3rdPartyand then make  -j1 ipopt). I had no problems with Ubuntu 17.10 myself.

You could try the older OMC versions using the older repositories: https://openmodelica.org/download/download-linux (Installing older releases or using a specific OpenModelica version). Or changing the CFLAGS (https://openmodelica.org/doc/OpenModeli … etcflags).

I will see if I can remove the march=native flag (it anyway does not make much sense for FMUs), but it seems slightly odd that on the build system clang does support -march=native and on your system it doesn't. Anyway, that would only change OM 1.13 and not 1.11 or 1.12.

I suppose OMEdit doesn't add the found library directories to the PATH? Alternatively, OMC doesn't copy dll dependencies from the library directory to the directory of the executable?

For OpenModelica scripting: https://openmodelica.org/doc/OpenModeli … l#loadfile
For OMEdit: no

The model should work fine with -d=noscodeDep, but I would avoid such unorthodox naming. I added a ticket for this problem: https://trac.openmodelica.org/OpenModelica/ticket/4791

It's also possible in Options->Libraries, but then Buildings latest would be loaded every time OMEdit starts

The configure script is usually called when cross-compiling (on the machine generating the FMU) automatically by OMC. But if you don't have a cross-compilation toolchain, it would be done manually by the user who wants to compile the FMU on a different machine before trying to import the FMU in some other tool.

If you don't have an ARM compiler installed on your computer, the easy solution is to install the toolchain. On Ubuntu, "sudo apt install gcc-arm-linux-gnueabihf". The other alternative is to only export source-code (or static), and just send the FMU to the other machine. Then do:

unzip M.fmu -d M.fmutmp
cd M.fmutmp/sources
./configure CFLAGS=MYCFLAGS ETC=ETC
make -j4

This should overwrite the original FMU with an FMU that supports both machines. No OpenModelica necessary on the second machine.

64-bit Windows OM exports 64-bit MINGW FMUs. 32-bit Windows OM exports 32-bit MINGW FMUs. Linux OM can export MSVC-compatible FMUs. If possible export using FMI for Model Exchange 2.0 as it works a lot better than Co-simulation or FMI 1.0.

What Operating System are you using? As far as I know this works on Linux and OSX.

No. Conditional components use structural parameters which cannot be changed after model translation.

The OpenModelica installer tells you to not install into a path containing a space for good reason; it doesn't work if you do that.

The code can be compiled without pthreads; use the define OMC_MINIMAL_RUNTIME. You might want to check https://github.com/OpenModelica/OMCompi … nfigure.ac for how the Unix systems configure and/or cross-compile the FMU.

Modelica.Blocks.Math.MinMax: Output the minimum and the maximum element of the input vector

Dealing with CSV/Excel files is easiest done by converting them to mat-files and using Modelica.Blocks.Tables to read them.

libOpenModelicaSimulationRuntimeC.so calls these files; note that you could simply run OpenModelica on a raspberry pi or similar; the entire compiler runs on ARM. You can also create ARM FMUs directly from OpenModelica; see for example https://github.com/OpenModelica/OpenMod … ompile.mos which generates the FMU in https://test.openmodelica.org/hudson/jo … MUs.tar.xz

OpenModelica uses its own version of Sundials.

Unlikely. The co-simulation interface sucks for co-simulation and we focus on model exchange instead. Only forward Euler is supported in the co-simulation FMUs. Luckily, it is much easier to use the solver you want with ME FMUs.

You need to make a recursive clone or initialize and update all the submodules.

Adding such a change to the portfile would break it for anyone who did not install atlas (most users)

Try asking your Dymola support (it's a commercial product so I assume you get support)

You are changing the values according to 11.1.2 Execution of an algorithm in a model And the rules for initialization only apply before the first step.

Your links are broken

I think you're a bit confused about how Modelica connections work. If your pump is sending 9 l/min from pump.C.Q, then from the cylinder's perspective, cylinder.C1.Q must be -9 l/min (it is receiving 9 l/min from some other component); because connections are zero-sum. If you check for example a simple electrical circuit in the standard library, and connect a constant source of 1V to a 1Ohm resistor, then one port of the resistor will be -1A and the other port will be 1A; but the component will also calculate an internal parameter i which is 1A and is the actual flow through the resistor. You could naturally calculate such a flow for the component itself if you'd like and think that's more natural than "+ is outgoing, - is incoming".

Yes, if an algorithm section assigns to a variable, this variable is always re-initialized at every entry of the algorithm section according to the Modelica specification. For non-discrete variables this is the start-value, for discrete variables it is pre(v). If you simply declare "discrete Modelica.SIunits.Time timeVar(start = 0);" I think you get the behavior that you are after (or perhaps some more variables need to be declared discrete).

zmq would probably work better than CORBA. There are many things you cannot do with the TCP interface such as sending multi-line models or strings. The interface is also unsafe as it listens for incoming non-local connections: anyone can connect to the port and run any command on your computer when using the interface.

Do some research on FMI: then you can control each step yourself and intergrate multiple tools. Or use the Modelica_DeviceDrivers library to communicate via some protocol in the simulation itself. Or simply use external "C" functions to communicate with the other process.

If you run a Linux copy of OpenModelica, it is possible to cross-compile for RPi. There are also packages available so you can run OpenModelica on your RPi 2+ (which is much simpler).

https://build.openmodelica.org/Document … ceive.html and
https://build.openmodelica.org/Document … tSend.html might be easier to use, but as far as I remember, they require sending data packets of the same size all the time and just keep the last received packet in the buffer (or some other odd behavior).

So you want a simulation using OMEdit to send some data to the Arduino? If you just send data on the serial port, you would trigger the interrupt on the Arduino and the other way around...

I'm a bit unsure exactly what you want to accomplish, but you could certainly setup an interrupt handler using external "C" in Modelica; as far as I know the DeviceDrivers library does not expose interrupts to the user.

Not really. We need a libgc compiled with specific flags and we need to link some of the other libraries against specific versions because they either changed licenses or API.

The Modelica tool decides which parameters it needs to evaluate. The only thing you can do if you want to be able to change a parameter value is to make sure this value is not propagated to any array dimension, etc Evaluate=false is a hint that the compiler should not evaluate the parameter if possible. But if it is used in array dimensions, it will be evaluated anyway.

"After translation you can only set literal start-values and non-evaluated parameters. " implies this parameter was evaluated by the tool (perhaps it is the dimension of an array or needed for a condition in an if-equation). You cannot change all parameters in a Modelica model after translation (a design limitation that there is no concept of structural parameters or requiring constants to define array sizes).

OK, what errors do you get from ExternData? I guess that's your only choice, but since OpenModelica is MinGW-based on Windows, you might need to compile some libraries yourself to match MinGW rather than visual studio...

Can't you just export the time series from Excel as csv and use the CombiTimeTables from MSL or something similar?

You need to enable code generation of functions (slow, may cause crashes) if you want to call custom C-code in scripts:

>>> loadModel(Modelica)

true

>>> Modelica.Utilities.Files.exist("C:") 



>>> setCommandLineOptions("-d=gen")

true

>>> Modelica.Utilities.Files.exist("C:") 

false

Modelica_LinearSystems2 is a partially Dymola-specific library which is why some parts of it don't work in OpenModelica.

omlib-modelicareference needed or just remove the package from your OMEdit config. The translation error is just a warning for MSL 3.2.1; the Electrical.Digital icon contained an error and won't be rendered correctly. It's fixed in MSL 3.2.2.

So you should be able to "dnf install omlib-systemdynamics" and "dnf install omlib-modelica-3.2.2" rather than downloading them manually (don't know what you could have gotten wrong or which standard library version you are using). Is it the 32 or 64-bit version?

How did you install OpenModelica? OM version? 32-bit or 64-bit?

Modelica native visualization is rather limited (you mostly visualize the position of simulated objects, and this might skip visualizing terrain, etc; or being simplified). Most people doing nicer looking visualization use external tools to augment the simulated data (as far as I know). The OpenModelica license is free of charge.

You need to create a library to call it, use the Library annotation to choose a name and compile the library as a .lib or .dll file. Make sure the file is mingw-compatible and uses the same integer/etc lengths as OpenModelica expects (as well as calling convention).

Does it work if you use the equivalent "reboiler.mixMolFrac := {0, 0}"? If so it's probably just an internal error and OMC can't handle the model and it would be good to have the model attached to a new ticket at https://trac.openmodelica.org/OpenModelica/newticket.

cryogenic wrote:

omc_embedded_server_init done, state=0x8315550, server=0x8312f28. Pause run=0 step=0

What went wrong? User, server or both?

Debug message in an older release is all.

Read up on either OPC-UA or FMI.

If it's large nonlinear equations, performance should be expected to be slow in the backend. It means many equations are related to each other, which means any sort of dependency analysis or change in an equation will affect many other equations. What can sometimes improve performance is if common subexpression elimination can move parts of the nonlinear system outside of the algebraic loop. You can try it with some of: --preOptModules+=introduceDerAlias --postOptModules+=wrapFunctionCalls.

Otherwise, sending the model to us via a ticket (or openmodelica@ida.liu.se, or directly to a developer encrypted if it's sensitive information) and we could perform a more detailed profiling of the model and see if any support function can be improved to get better performance for some detail in the model.

I would recomment that OpenModelica participates at the FMI Cross Check (https://www.fmi-standard.org/tools) by submitting FMUs, then such porblems would be detected. What I see there currenty: only OpenModelica reports successful simulation of FMUs exported by OpenModelica (FMI 1.0)

It's not only OpenModelica able to import the OM 1.9.1 win32 FMUs, but 14 different tools...

We have test FMUs for: win32, win64, linux32, linux64, arm-linux-gnueabi, darwin64 and C-code for FMI 2.0 ME and CS using OpenModelica 1.11. As far as I know, no other vendor tested any of them (and we didn't upload new FMUs for FMI 1.0 since FMI 1.0 doesn't really work for numerical integration).

You don't get entries in the main page unless people actually test things, and why would a commercial vendor test a free software and thus give advertisement to it if they only need to test against 3 tools to get their "import" stamp? (We mainly do linux64 export and no import in OpenModelica itself; only 3 tools tested linux64 import and none of them on a recent OM FMU..).

When the OM FMI simulator is available, it will be a separate tool in the list and we'll setup scripts to try it against many tools.

You wouldn't want to do it in OpenModelica, but a Modelica library. The standard library comes with lookup tables capable of linear interpolation, such as: https://build.openmodelica.org/Document … Table.html

For Ubuntu, you do the same as in Windows, except the executable does not have the .exe suffix and ./ is probably not on the PATH. So ./xxx ...

That's just a compiler warning, not an error.

I suggest https://trac.openmodelica.org/OpenModelica/newticket with more details on your simulation settings (the experiment annotation doesn't contain the settings). Default settings with stopTime=120e-6 simulates in 0.05s of wall time.

Works for me when not using className=className, just passing className using positional arguments.

So you use the default, which is platforms={"dynamic"} (depend on OM being installed). Using platforms={"static"} builds the same FMU as for cross-compilation (try to statically link as much as possible; this is much slower in general, but the FMU should work on more systems).

Yes, use the "static" target of the FMU. Also check the cross compilation options if you want to create FMUs that work on multiple platforms: https://github.com/OpenModelica/OpenMod … ompile.mos

Perhaps if you contribute to these tickets it will be added in the next MSL release:

https://github.com/modelica/Modelica/issues/477
https://github.com/modelica/Modelica/issues/2120

https://trac.openmodelica.org/OpenModelica/newticket

I assume you use a locale that uses comma instead of dots for the decimal separator? Might be that OMEdit puts some wrong characters in there...

You can, but not in the Ubuntu/Debian packages shipped by us. You can unzip all files into a single directory and call /path/to/openmodelica32/usr/bin/omc. But you need the 386 dependencies for that and Ubuntu doesn't allow lapack, sundials, etc non-native packages. So you need to provide them as well. Annoying

I usually use debootstrap / schroot to install a 32-bit Ubuntu on top of 64-bit Ubuntu when I want to play with the 32-bit OS. It's more light-weight than a virtual machine; essentially it is a second Ubuntu installation in some directory of your filesystem. So it's convenient; you can use the pre-built binaries and use the same home directory as your regular Linux installation.

You have misunderstood the documentation. You always get all messages. What warningsAsErrors does is similar to -Werror in gcc (it makes warnings into errors) if you want a more pedantic mode (we use this when developing OM). You can use countMessages or perhaps even getMessagesStringInternal if you want to do something similar to what OMEdit uses.

Post the model (mos-script, not onb) to https://trac.openmodelica.org/OpenModelica/newticket

It seems even with Inline=false, in this instance the function is inlined and this causes a bad equation to be generated:

x := $_signNoNull($TMP$VAR$3$0X$ABS) * abs(y ^ 0.5)

Should probably have been abs(y)^0.5 that should have been automatically generated...

No, there really is an error in your original post. You have x_to_y mapping y:=x and y_to_x mapping x:=-y. So it is not an inverse function.

When I try your other functions, OM also solves them just fine.

The inverse annotation is not used by OpenModelica. It solves the function numerically instead (your x_to_y function has the error; fix it and you get the expected result). If you use Inline=true, the generated code does not contain any non-linear system to solve at run-time.

The C++ runtime is requested using "--with-cppruntime". You should typically have a different line saying it failed to find omniidl if it doesn't find CORBA (but this has no impact on the tests).

Sundials is detected in the OMCompiler configure. It first looks for headers and then tries to link. If it says it fails to find sundials, read the config.log carefully to see what is missing. I think you need all of cvode, kinsol and the ida solver installed (which are separate packages on Ubuntu; don't know about Fedora).

./configure --without-cppruntime or figure out how to solve it manually with the newer Sundials version

Most (all?) of those are from optional dependencies. The C++ runtime is needed for cppruntime and hpcom tests. The sundials suite needs to be installed in order to run IDA / Radau / etc solvers (need to ./configure again after installing those packages).

(Or at least make clean in OMEdit; if your omc executable works fine there should be no need to clean that. Just make sure the same C++ compiler is used for OMEdit as for OMC)

I suspect you need a make clean and then re-compiling. The errors seem related to using different C++ compilers for different parts of the code.

It's a compiler debug-flag. If you use mos-scripts, you pass it when calling omc, so "omc -d=-noinlineFunctions script.mos". In OMShell, you can use setCommandLineOptions("-d=-noinlineFunctions"). In OMEdit, it is hidden under Options->Simulation->OMC Flags

The AdvancedNoise library contains the parts of the Noise library that didn't make it into MSL due to the above mentioned issues in OpenModelica (and some other issues in other tools).

As an alternative, you can File->Open /usr/lib/omlibrary/PowerSystems latest/package.mo and it will appear in the recent libraries list.

OMEdit is a bit stupid if you load libraries using the File menu (you can't choose which version to load there).

If you go to Options->Libraries, you can add PowerSystems and manually put latest as the version and it will load the correct PowerSystems (on every startup though).

This should already be fixed in the latest master: https://github.com/OpenModelica/OMCompi … 65c0e4761a

As far as I know, no FCSys version works with any OpenModelica version.

http://libraries.openmodelica.org/branc … FCSys.html says FCSys does not work in OpenModelica at the moment.

Yes, you have created an algebraic loop saying basically dio_out = not dio_out, which cannot be solved. Make dio_out a discrete variable:

when sample(0, 0.01) then

  dio_out = not pre(dio_out);

end when;

You cannot access variable attributes by dot-notation

We have a 100 Mbit/s connection and the OMC package is small. I would assume travis-ci fetches through an apt cacher (proxy) anyway (I do when building, and my build machine is connected to the same switch as the maching hosting the packages).

You need to check the output of the OMC commands and call exit(1) if you want an exit code. For example, this fails because loadString is commented out:

//loadString("model M end M;");getErrorString();

res:=simulate(M); getErrorString();

res:=res.resultFile;

if res=="" then

  exit(1);

end if;

The latest OMC release for 16.04 LTS is also 1.9.7... For 12.04, we will not build anything anymore. There were too many changes to Ubuntu to bother supporting it. 14.04 we still build the release tag (release), maintenance branch (stable) and master branch (nightly). Use "stable" instead of "release" if you want to use 1.11.0 beta and release candidates (there is no 1.10.0 release).

"in" is a keyword and cannot be used for identifiers.

I guess you don't have pkg-config installed

A better place to start is looking at the profiler output. Often it is a non-linear system that is the bottleneck, and not DASSL.

On Raspberry Pi 2/3, there are pre-built packages. Install them the same way you installed your Linux packages for x86 (Debian Jessie, Ubuntu trusty/xenial/yakkety have packages).

In order to follow the Modelica specification and define the variable to be an input (that can somehow be controlled externally):

model M

  InPutPort p(vi=r);

  input Real r;

end M;

Only inputs in the top-level model are kept. Any other input variables need to be connected. (This is a change from Modelica 2.x, in which some tools allowed these sort of models)

(Current) OMC generates FMI 2.0 by default as far as I remember. Look in your model closer and you see why vi is not assigned. As far as I can see, you have

// input vi

vo := vi;

inpu := vo;

The model is not very useful, but I suspect modelicac allowed input variables not on the top level class to count as inputs to the simulation. InPutPort1.vi lacks an equation in your model, which is not allowed in Modelica.

It might just be something that changed in the Modelica specification (modelicac does not follow recent standards). I can't really say without seeing the model in question, but you could try with --std=1.x or --std=2.x to see if that makes a difference.

Did you do a git clean of all repositories? The Windows build is working, so a git clean should solve the problem...

rm /e/OpenModelica.git/build/bin/omc.exe and try again (or do git clean). There was a change to the bootstrapping interface recently, which causes this issue if you have an old omc that you compile through.

That's not a Modelica file, but a "flat Modelica" file. They cannot be used as input to the compiler.

From command-line or OMEdit additional simulation flags (-overrideFile=...) or in OMShell simFlags="-overrideFile=...".

https://openmodelica.org/doc/OpenModeli … erridefile

Given that OpenModelica is also case-sensitive, can you check if you have a file HPcomponents.mo or HPcomponents/package.mo that contains a class HPComponents (could be that Windows OpenModelica ignores the error in that file and Dymola silently renames the class)? Otherwise, I am really unsure what could be wrong and would have liked to see a zip of the library...

https://openmodelica.org/doc/OpenModeli … mcflag-std

It is also possible to use the OPC-UA interface to control a simulation.

Did you try exporting a source-code FMU? It doesn't depend on any external libraries... https://github.com/OpenModelica/OpenMod … ompile.mos

Well, your functions starts the loop with n=1, so the n=0 case is undefined. You don't initialize y, so it gets random data (possibly 0). You then recursively call the function to multiply i by fac(i-1), which again ends with the undefined y (possibly 0).

You are mixing iterative and recursive styles. Choose one:

For a recursive factorial: https://github.com/OpenModelica/OpenMod … ctorial.mo

Or iterative: https://github.com/OpenModelica/OpenMod … on.mo#L235

Correct syntax is: if (n==0)

It's output to the console, which in OMShell's case is redirected to a log-file...

You can check env.vars using: https://openmodelica.org/doc/OpenModeli … ronmentvar

If you open OMEdit from a console window the env.vars might be preserved. It depends on where you set them as well (bashrc / /etc/profile, etc)

You can use OMShell, OMNotebook, mos-script or like me "omc -s" followed by make and running the executable yourself.

I don't use OMEdit

Call ModelicaMessage instead of printf (printf is displayed if you use a terminal, but not OMEdit).

You can either print the return code or make assertions, etc. To make sure that the exit code is 0.

See the simulation flags documentation for an explanation of what is done (just printing the final values of the calls to see the exit status; you can probably use the plotting functionality of OMEdit): https://openmodelica.org/doc/OpenModeli … tion-flags

Seems to be working fine for me (OpenModelica 1.11.0~dev-321-g5aa0206 Ubuntu 64-bit):

model SystemFunctionTest

  Real returnValue = Modelica.Utilities.System.command("/home/marsj/tmp/test");

end SystemFunctionTest;



marsj@Precision-5510:~/tmp$ cat test

#!/bin/sh



echo "ABC DEF"



marsj@Precision-5510:~/tmp$ ls -lh test

-rwxr-xr-x 1 marsj marsj 26 nov  4 08:12 test



$ ./SystemFunctionTest -output returnValue -override stepSize=0.5 -s euler

ABC DEF

ABC DEF

ABC DEF

ABC DEF

ABC DEF

time=1,returnValue=0

Make sure to check the return code from the system call.

I suggest going to https://github.com/modelica/PowerSystems/issues to discuss this. Rüdiger Franke is quite active on GitHub, but not on these forums.

You can just use the -override or -overrideFile flags to change values (changing the XML-file can break things). The JSON file should not be changed either.

For scripts, we usually just use a text editor and save as something.mos, then run omc something.mos. Just call getErrorString() a lot to see error-messages.

Something like:
https://github.com/OpenModelica/OpenMod … erter2.mos

You need to add a component "inner Modelica.Fluid.System system" somewhere. Probably in your BlowDown model. This system is then shared by all fluids in your model.

Modelica.Utilities.Streams.print(String(realNumber))  should work fine

My guess is because the function is declared to take only 3 inputs.

https://openmodelica.org/doc/OpenModeli … g_api.html

Save the state using an external object (see the specification on how to do this)

You need to install java and keep java.exe on your PATH

I guess it is due to the model having : as dimensions.

Or just call cd() to show the current directory, which is probably where the file will be generated.

The usual way would be to "cd OMCompiler && git pull && make -j4", especially if you have 2 copies of OMC around. One that you configure --without-omc and the other one you configure --with-omc=/path/to/first/omc. This makes full recompilation a lot faster (do not need to bootstrap in 3 stages) and a lot less messy if you somehow break OMC. Sometimes "git pull && make -j4" doesn't work, but it's quite fast to just try updating and compiling and see if it works.

Dymola was used for writing the StateGraph library.

OpenModelica does not support animation

The uses-annotation perhaps? I am not familiar with jmodelica though.

Yes, OpenModelica does not perform unit checking by default (and does not have a reliable unit checker anyway).

omc RLC.mo Modelica -s --preOptModules+=unitChecking

...

Warning: The following equation is INCONSISTENT due to specified unit information: i_R = V * R

The units of following sub-expressions need to be equal:

- sub-expression "V * R" has unit "Mm4.s-6.A-3.g2"

- sub-expression "i_R" has unit "A"

MDT itself is using CORBA to do all operations, but it is not supposed to replace OMEdit. OMEdit is designed to replace MDT.

All it does is call OpenModelica via CORBA. There are some maps in there and other data types that should be available in Java as well. OMEdit does it all in C++.

Yes, getting the icon annotation is how you draw the icon

You can also see https://github.com/OpenModelica/OMCompi … e_icons.py which requires OMPython installed to generate SVG icons.

Try opening OMEdit and see which commands it executes in order to query the icon information (Tools->OMC CLI).

Or perhaps is valgrind is too slow, after 0 seconds?

So what is the memory leaked after 100 seconds?

What is the stats of the model that you are simulating? (omc -d=backenddaeinfo model.mos; use getErrorString() to see the message)

For simpler models the amount of memory leaked is constant. But I suspect some non-linear solver or something could be causing the issue.

You don't really know until you try

Well, a triangular matrix is always preferred, but if you do have algebraic loops, tearing is often a good choice especially for very large algebraic loops provided you can find good tearing variables.

The default is to only output at the times given by the output interval (equidistant time grid). Perhaps you simply need to disable events and set the output interval you desired? https://openmodelica.org/doc/OpenModeli … oeventemit

It is also possible to resample the output file (but then you get a large file that you reduce in size which is not as efficient): https://openmodelica.org/doc/OpenModeli … ionresults

Which compilers did you try? OpenModelica claims to solve the model although it probably should not. The model is pretty bad (not all variables/parameters given initial values so compilers have to guess which variables are fixed).

The dangerous ones set to 0.0 by OpenModelica are:

nIst, w, EKinMax, PMax (which can cause division by zero / singularity)

w=2*pi*nIst actually says 0=2*3.14*0, which is what may cause tools to (rightfully) claim the model is singular. I believe OpenModelica just removed this equation as it was fulfilled and added an equation for w=0 according to the standard...

Try setting fixed=false for parameters that you want to set in INITIAL equations.

Either:

    parameter SIunits.AngularVelocity w(fixed=false); 

initial equation

  w=2*pi*nIst;

Or:

parameter SIunits.AngularVelocity w=2*pi*nIst;

Sometimes, NR is enough. Often it is not; especially when you have discontinuous signals (hybrid systems, events). By using tearing you have reduced the number of unknowns but the system is more sensitive to bad start-values. Are you able to solve the system without applying tearing? If you can do that you can try feeding start-values close to the true values and see if it converges better.

Efficiency reasons. Reading mat-files is easier than parsing csv, I promise. But yes, you can change output format to csv. Just specify -r outfile.csv when calling the simulation executable or choose csv from OMEdit or call https://openmodelica.org/doc/OpenModeli … ionresults to convert from mat to csv.

The mat4 format is very simple, the reader is quite short: https://github.com/OpenModelica/OMCompi … _matlab4.c

The Linux installer is about 20MB, so perhaps use that instead of the Windows installer

Did you install onniidl-python before pip install? If it's not available, it uses a pre-generated Python file which might not match your omniorb version.

That is probably by design in SystemDynamics. Try reading the documentation for Modelica.Math.Random which might provide better results.

http://www.ida.liu.se/~mohto/OO_Modelic … ctions.pdf

Rewrite your code to an algorithm-section (eqn 2.30 and the for-loop as an algorithm calculating Voc_real and iVoc_real). You are writing to the same scalar variable multiple times in a for-loop which will cause problems further down the line. Modelica enforces single-assignment for equations...

You can't write equations like that. It would basically be translated to either assigning to Voc_real or not assigning to anything, which means this if-equation is 0 or 1 scalar equations and the equation count will not work.

It sounds more like you want to use when/reinit or limiting Voc_real when it is calculated or you need to introduce some additional variable.

tmp = ... // What calculated Voc_real before

Voc_real = if ... then tmp else iVoc_real

Try the FMU SDK or FMI Library: https://fmi-standard.org/downloads

Go to fmi-standard.org and read the documentation very carefully. That + Google weird errors importing dll's should tell you everything you need to know.

FMI is a binary format specifying C linkage. So all FMUs regardless of language used will import in the way (unless you use source-code FMUs which we do not do for C#; we also do not do FMI export using C#). My guess is that you just need an FMI master written in C# and load the FMU from that at run-time.

As far as I know Nelder-Mead is no longer used to initialized simulations. It now uses a BLT sorting and symbolic pre-processing without this outer optimization phase.

1. See which variables are present in an equation
2. Try to solve for each of those variables
3. You now have a set of solvable variables

For example:

x=external_func("str",y,z);

Will say y and z cannot be solved for (since the external C function is not known what it returns and you cannot invert it). While:

x=sin(y);

Can probably be inverted to y=arcsin(x) so both x and y are solvable.

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).

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

1.9.{4,5,6} is the next major release after 1.9.3, so you may want to try it as well.

Or you should call the makefiles and build the shipped qwt version.

Yes, either making an approximation using a derivative block. Or by using a symbolic derivative annotation on the external function and providing the external derivative function to the model...

As far as I know, you can only abort a simulation with an error-message from external C (ModelicaError), which works similar to a failed assertion.

File->System Libraries->Physiomodel

It is listed in freeopcua-client, but I know that earlier versions did not support alias variables. So perhaps you just need to update your OMC. It is a new and experimental feature, so things may change quickly.

What output format and OMC version are you using? (Older versions or .plt output put the result-file in memory; use .mat format to save a lot of heap)

The latest version show Real and Boolean variables (states, inputs, continuous), but does not show parameters or constant variables (yet). Constants can be retrieved from the _init.xml file I believe.

By starting the executable with flag -embeddedServer=opc-ua, the OM OPC UA server is started,

Did you try https://github.com/modelica-3rdparty/PhysioLibrary ?

You can change inputs with OPC UA or by using Linux and the device drivers library (I suppose).

You get real-time plotting by implementing that plotting yourself. For example through the OPC UA interface. OMEdit does not have this support yet.

If you use the nightly builds, you can try the new real-time flags for OM simulations: https://openmodelica.org/doc/OpenModeli … mpiler-omc

Modelica does not allow to change public/protected on a boolean variable.

Because records are passed by reference, you need to pass it as an input to the function and not return in.

How about http://www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp ?

What's wrong with rsync on Windows? cygwin needed?

Or just shipping OM with rsync.exe? Then you could really script the update by just keeping a copy of the extracted files. There is no need to env.vars, etc anymore after all (and we could have 2~3 different directories; nightly, stable, release).

The missing inflate/deflate is because MSL 3.2.1 is missing the zlib dependency (MSL trunk has this). The hdf5 things I assume is because @adrpo installed hdf5 in msys2, but these dependencies are not automatically included. So possibly MSL should only include hdf5 support when dynamically linked (trac.modelica.org).

I guess the easiest way to solve the error would be to install Linux where OM is better tested. I cannot help any more than that without seeing the full error-message starting from the linker command, and getting the full version number of OMC and the version of MSL used.

The ball will typically fall through the ground if the velocity does not bounce it high enough, so you need a condition to just let the ball remain to 0 velocity when the numbers get too small.

CORBA is IPC: synchronous function calls over TCP/IP. If you want to fork, you could do something like:

loadString("function fork

  output Integer pid;

external \"C\" pid=fork() annotation(Include=\"#include <unistd.h>\");

end fork;");getErrorString();

loadModel(Modelica);getErrorString();

fork();getErrorString();

But I guess it would be inconvenient. Sockets still work if you like that better than CORBA. I guess PHP does not have CORBA bindings although Python does.

Support for named pipes, stdin, etc is a bit weak in OMC because it parses the full input before running any commands.

1.9.4 should be released sometime this week.

Did you see the readme that said the repository has moved to git?

(I think the 1.9.3 pre-release did not support preOptModules+=xxx.)

Yes, the branch works on Linux. And no, you won't get it pre-built from anywhere. rt_tick(1) is used if you use measureTime=true (it is the clock measuring the time for initialization). There won't be any spare timers when measureTime=true is given.

No, the specification only talks about binary and unary operations. The overloaded constructor is not used in equality-equations.

Complex 3.2.2 contains an overloaded '<>'. 3.2.1 does not.

Hard to tell what went wrong without seeing the code. Did you synchronize on events or in a regular equation? Anyway, the version after OMC 1.9.4 will probably do real-time synchronization on a flag. You can test it out from my branch: https://github.com/sjoelund/OMCompiler/tree/opc-da (passing -rt 1 to synchronize to real-time).

simulate(..., simflags="...")

See https://openmodelica.org/doc/OpenModeli … flags.html for options (or pass -?). Number of processors you set through omc -n 2 (else, it uses the number of physical cores by default).

Can you simulate any models with that setup? lib/omlibrary seems to be missing and includes ModelicaBuiltin.mo. Usually you would have MSL in the default MODELICAPATH and not try to export it yourself. Note that the env.var used for the MODELICAPATH is actually OPENMODELICALIBRARY in order to not conflict with other installed Modelica tools.

/usr/lib/omlibrary/ModelicaServices 3.2.1
/usr/lib/omlibrary/Modelica 3.2.1
/usr/lib/omlibrary/Complex 3.2.1

Or you could try https://build.openmodelica.org/librarie … 332.tar.xz (note that the version OM ships with is a patched MSL, especially so for ModelicaServices which is intended to be tool-specific).

I can confirm the interactive (TCP/IP) interface works on Linux. I am not sure about Windows.

FMI export

I know they exist since we make the nightly builds from them. They might however be missing from each named repo and just part of the odd nightly source repo...