The root user has no password

The vagrant user has sudo privileges (vagrant password).

I will try to add sudo group to future VM builds.

r23444 should fix this.

https://test.openmodelica.org/libraries … rsive.html
https://test.openmodelica.org/libraries … ptions.err has 2404 states, around 4000 equations.Takes 1 minute to compile the C-code with -O0, and runs in 13 seconds.

https://test.openmodelica.org/libraries … rsive.html
https://test.openmodelica.org/libraries … yAdder.err on the other hand has 324 states, 1649 equations (some which are torn non-linear systems). 1m18s to compile the C-code with -O0, and runs into a timeout (on the same machine it would take around 9 minutes or so to finish). But the slowness here is that the non-linear solvers take long to converge. They are already optimized.

So... It depends a lot on other structures in your model.

Set env.var MODELICAUSERCFLAGS=-O3 or use setCFlags(getCFlags() + " -O3")
Or better yet, use -Os or -O2. That runs faster than O3 in most cases. Usually, the overall time is slower though (the simulation runtime is already optimized and it takes a lot of extra effort to optimize all of the generated code, some which is never run).

https://build.openmodelica.org/omc/buil … /releases/ has the releases only. The beta versions are not stored there.

https://trac.openmodelica.org/OpenModel … eset/23192 should do what you require

An a-file is just a set of object-files stored in the ar file format. As long as you generate the objects using the MinGW gcc, it should work just fine. ld.exe will look for any a-file in the given directories. For some reason the -LPath/To/Document/Clibaries is not added though. This usually happens if omc cannot find the directory. The base path it will look in is based on the location of the mo-file.
So if you have the .a-file as C:/OpenModelica1.9.1Beta2/tmp/Test_interp/Clibraries/Document.a and LibraryDirectory="modelica://Interpolate/Clibraries", you should have Interpolate.mo at C:/OpenModelica1.9.1Beta2/tmp/Test_interp/Interpolate.mo

The Windows version of OpenModelica will not load dll's since it uses MinGW. It will link a-files just fine; these are static libraries.

"Ps : I need to get the local path (get with constant String [:,2] glibraries := OpenModelica.Scripting.getLoadedLibraries()current/wink in order to send this path to the c function which read the file "tab.txt". This part works and the c function read the good path."

No, you don't https://build.openmodelica.org/Document … ource.html translates from modelica://.../Something.txt into an absolute filename.

You didn't create an a-file though. You created an o-file with .a extension. An a-file is created by running something like "ar -ru libmylib.a mylib1.o mylib2.o mylib3.o". Not that the when specifying -lX, the linker searches for "libX.a", "libX.so", etc.

It is very much optional

First of all, I would not use the OpenModelica.Scripting functions within a model. Second, the Library annotation only works for string literals or array of string literals. It does not lookup any constants in the code.

You do not need to use the scripting function to refer to the resources directory. Simplify use LibraryDirectory="modelica://MyLibrary/Clibraries/". An object-file is not really a linkable library (needs absolute paths to the o-file, which is not a portable option).

Create an a-file or lib-file instead, name it something like: libMyLibrary.a and add Library="MyLibrary", and OpenModelica will add the magic compiler flags: -L /path/to/MyLibrary/Clibraries -lMyLibrary, which makes the project compile fine.

Need to have /usr/bin/libsundials_nvecserial.so installed in order to build the cppruntime, I guess.

You are building using /usr/bin/omc, which is outdated. configure --without-omc would work.

Yes

No without the dash, you have parallel build issues with conflicts in all and cpp. The C++ run-time is mostly if you use Bosch Rexroth products.

You're just missing the c++ runtime. It's not used by default, and I wouldn't recommend using it. But if you want a complete install, all-runtimeCPPinstall should do the trick.

Because make all does not build everything

The simulation flags only affect the simulation executable. Tools->Options->Simulation->OMC Flags can set specific flags. A little odd the simulation setup can't...

Previously (1.9.1 release and earlier), it was not required since it was possible to compile using rml-mmc.
Bootstrapping is the process of the compiler compiling itself. In OpenModelica, we store a set of generated C-files that you create a Modelica compiler from. This compiler is then used to compile the MetaModelica source code, which creates a new compiler. This compiler is then used to compile MetaModelica sources again. And the result is a working compiler. This process makes it easier for us to create new language features that the compiler itself uses, and allows us to use all of the features we implemented in Modelica in order to implement the OpenModelica compiler itself.
This means for example that in order to implement a built-in operator like "String()" in the compiler, we could just call "String()" in the source code and it would do the same thing.

You can play with what little does work using +std=3.3

There is no point doing that now. OpenModelica can no longer be compiled using rml-mmc (1.9.1 is the last version we use rml-mmc).

You need revision 280

You need to specify the svn revision number since you need the very latest one.

Are you using the latest version of rml-mmc?

There is no such latest version with MSL 3.x corrections. The latest one is the one in github, and it is for MSL 2.x with Modelica 1.x annotations. If you want an MSL 3.x version, you need to open the library in Dymola and convert it to MSL 3.x. It is as far as I know the only Modelica tool that supports conversion scripts.

OpenModelica ships with the following version: https://github.com/modelica-3rdparty/Wa … ee/master. If you want it fixed, you will need to submit pull requests there.
Note that this is the MSL 2.x version, so you need to use command-line omc or OMShell to use it. If there is an MSL 3.x branch created on github, OpenModelica can also ship with this one.

Because omc is usually run as a TCP server. Running as root has security problems.

No, you can not build omc as root.

https://build.openmodelica.org/apt/pool … rig.tar.gz

You have: checking for omc... /usr/bin/omc
Which is an old omc version. You need to use configure --without-omc to force bootstrapping to be performed if you have omc installed.

Note that the version number svn190812 corresponds to just the hhmmdd part of the libraries package.

You need to have compiled omniidl with python support. It could possibly be part of an omniidl-python package.

We don't have any repository called "testing": https://build.openmodelica.org/apt/dists/
We also do not have jessie if that is what you were after.

The code is not a full svn checkout:

/bin/sh: line 0: cd: libraries/Modelica 3.1/Modelica: No such file or directory

make[3]: *** [omlibrary-31] Error 1

make[3]: *** Waiting for unfinished jobs....

If you are compiling using the tarballs, note that you need to use the same make sequence as in the debian builds:
        $(MAKE) $(MAKEFLAGS) NOLIBRARIES=Yes

Or if you want all the libraries and have git, python, and some etc modules installed:
        $(MAKE) $(MAKEFLAGS) GITLIBRARIES=Yes

It is also possible to download the full library collection here (put the libraries under build/lib/omlibrary or ~/.openmodelica/libraries):
https://build.openmodelica.org/libraries/

Only the version that requires g++-4.4 works with OpenModelica, so that one... Else use --without-paradiseo (just disabled OMOptim).

That's again a problem with omoptim:
OMOPTIM_CC='gcc'
OMOPTIM_CXX='g++'

But your version of gcc/g++ is not compatible with paradiseo (requires g++-4.4 since paradiseo uses non-standard c++; the configure script automatically looks for /usr/bin/g++-4.4).

For fixing old libraries, most of them are hosted on https://github.com/modelica-3rdParty so fixing them is as easy as making a pull request in some cases. I know a lot of people who say some library is working in OpenModelica, but will not even go through the parser (loadFile). So a lot of libraries you don't even need to know the domain in order to fix...

As for larger tutorials, http://book.xogeny.com/ is not really a tutorial, but it does teach you most things you should know about Modelica

There is a more recent (short) Modelica tutorial here: http://tour.xogeny.com

It should work in r22729. There were some generated omniorb files checked into svn because of silly Windows developers (I assume). This made omniORB choke since you use a different version of omniORB than the one we use (it should work fine now though).

The error-message is not shown. If you make a parallel make, it may be megabytes above the end of the message.

You need to post the error-message for support. Right now I can't tell if it fails to build omc or one of the graphical clients.

Note that OpenModelica supports parallel make (make -j4 is reasonable for 4-core machines; we use make -j40 on the build servers)

We keep the source version of the deb-packages (which is pretty much the svn version minus the testsuite): https://build.openmodelica.org/apt/pool/contrib/

Yeah. It doesn't hurt.

The memory consumption and performance is different. RML does not have a parallel garbage collector, but usually uses less memory.
We will not support rml-mmc in the future, and don't support it on OSX. For most use cases the resulting omc is pretty much the same.

I've been thinking about this a bit. Documentation in OpenModelica is lacking a bit (some old, unsupported things are documented, and new things are not).

But one thing that really would help is to update old libraries. Every now and then someone will try to use an old Modelica 1.x or 2.x library with OpenModelica and it will just fail. Because so many things are just wrong in the old libraries. This is a lot of work in some cases (there are "Modelica" libraries out there that should not even pass a Modelica lexer).

Fixed in r22707

Do you have a small model for this so I don't need to figure out how to use the block? It should be an easy fix.

In OMPlot, you can save an image which is the same as the displayed widget (sizes and so on).

For high-quality plot images, use an external tool like gnuplot. No one was interested in the ticket I created regarding a specific gnuplot API in OpenModelica; maybe because it is so easy to write the files yourself when you know how... https://trac.openmodelica.org/OpenModelica/ticket/2549

Well. rising1.y is an instantaneous change (dirac impulse). It is never true in the continuous sense. Maybe it would make sense to keep it as such in the result-file; I am unsure why we don't do so.

You can still use it as a condition in a when-equation, which is the primary use of the edge function:

model tmp1

  Modelica.Blocks.Sources.Sine sine1(amplitude = 2, freqHz = 1, offset = 0) annotation(Placement(visible = true, transformation(origin = {-60, 60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

  Modelica.Blocks.Logical.LessEqualThreshold lessequalthreshold1 annotation(Placement(visible = true, transformation(origin = {-20, 60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

  Modelica.Blocks.MathBoolean.RisingEdge rising1 annotation(Placement(visible = true, transformation(origin = {20, 60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

  Real r(fixed=true);

equation

  when rising1.y then

    r = pre(r) + 1;

  end when;

  connect(rising1.u, lessequalthreshold1.y) annotation(Line(points = {{6, 60}, {-8.4724, 60}, {-8.4724, 60}, {-9, 60}}, color = {255, 0, 255}));

  connect(lessequalthreshold1.u, sine1.y) annotation(Line(points = {{-32, 60}, {-49.5507, 60}, {-49.5507, 60.077}, {-49.5507, 60.077}}, color = {0, 0, 127}));

  annotation(Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2, 2})), Diagram(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 5, Tolerance = 1e-06, Interval = 0.01));

end tmp1;

So it works fine. You just can't tell if it does or not from plotting it.

Can you run the following in a mos-script? (Put in file a.mos, in some working directory you can easily clean)

loadModel(Modelica);getErrorString();

buildModel(Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum);getErrorString();

Then run command omc a.mos.

You could also do the same with OMShell and see if it works. If it does, it is OMEdit that is broken (it does not seem to work for me either; must be a regression).

What is the output of:

$ dpkg -l omc omlib-modelica-3.2.1 omlib-complex-3.2.1 omlib-modelicaservices-3.2.1

What problems do you have with the library? Which model does not simulate?

OpenModelica cannot perform automatic tests on the library because there are no example marked in it. The library loads fine with +std=2.x set. You would need to use command-line omc since OMEdit will not handle these libraries.

I think you would be better off with the nightly build since you need a patched version of MSL 3.2.1 in order to run the older stable releases. This mainly affects MultiBody.World, which previously has been patched in OpenModelica.

For DCPM/AIMC it generates errors but still works.

The Solenoid actuator is not an example. It is an example package (contains examples).

Yeah. I would just compile without OMShell-terminal. It's not even part of the Windows distribution. It is sort of useful if you want to ssh to a server with OpenModelica installed (no GUI).

You have the following in the log:

configure:5097: gcc -o conftest -g -O2 -fno-tree-ch -fno-tree-vrp -fno-tree-pre -fno-stack-protector   conftest.c -lreadline   >&5

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tputs'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tgoto'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tgetflag'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `UP'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tgetent'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tgetnum'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `PC'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `tgetstr'

/usr/lib/gcc/i486-slackware-linux/4.8.3/../../../libreadline.so: undefined reference to `BC'

These files are part of libtinfo.so, which your libreadline needs to link in or the so-file is not complete. The following is on Ubuntu:

$ ldd /usr/lib/x86_64-linux-gnu/libreadline.so 

    linux-vdso.so.1 =>  (0x00007fff507fe000)

    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f28541dd000)

    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2853e17000)

    /lib64/ld-linux-x86-64.so.2 (0x00007f2854680000)

Upload the config.log somewhere, then. It contains all the yummy information.

None of the nightly builds will work for you, then. Only the virtual machine.

Which operating system? Linux? The deb-packages reference the required packages (if you run Debian/Ubuntu). The virtual machine images are self-contained.

You need to have a file installed that is /usr/lib/libreadline.so, or create a symlink /usr/lib/libreadline.so to libreadline.so.5.2. Or read the configure.log to find out what error the linker gave when trying to link in libreadline.a

You will need to have libreadline.a or libreadline.so somewhere as well. If they are not available directly in /usr/lib, you may need to add LDFLAGS to search for it.

Are you sure that the readline headers are installed? Where are they located (readline/history.h in particular)? You can also configure with --disable-omshell-terminal to skip readline.

By hand

Use the regular translation commands you will get a file test_init.xml and test_info.xml. This contains the causalized, index-reduced system on ODE form. There is also the dumpXMLDAE command.

A non-linear system is not a single equation, which is why it cannot highlight a single line of code. Click the little plus sign and equations 41..54 (?) will all line up. The residual equations are solved as a NLS, and the assignments are solved as normal (it is a torn NLS).

What version of OpenModelica are you using? More recent ones will have a link "Debug more" that will open the debugger for you.

You are not doing anything wrong. The library is wrong, but it works fine anyway (except some documentation strings will show question marks). You could also add a file package.encoding to silence it:

[martin@mega Thermocycle-library]$ echo ISO-8859-1 > ThermoCycle/package.encoding

[martin@mega Thermocycle-library]$ OMShell-terminal 

OMShell Copyright 1997-2014, Open Source Modelica Consortium (OSMC)

Distributed under OMSC-PL and GPL, see www.openmodelica.org



To get help on using OMShell and OpenModelica, type "help()" and press enter

Started server using:omc +d=interactive > /tmp/omshell.log 2>&1 &

>>> loadFile("ThermoCycle/package.mo")

true

>>> getErrorString()

""

Try this one for example: https://build.openmodelica.org/Document … ica3D.html

Stupid forums think : is part of the URL

[martin@mega Thermocycle-library]$ git checkout master

Already on 'master'

Your branch is up-to-date with 'origin/master'.

[martin@mega Thermocycle-library]$ OMShell-terminal 

OMShell Copyright 1997-2014, Open Source Modelica Consortium (OSMC)

Distributed under OMSC-PL and GPL, see www.openmodelica.org



To get help on using OMShell and OpenModelica, type "help()" and press enter

Started server using:omc +d=interactive > /tmp/omshell.log 2>&1 &

>>> loadFile("ThermoCycle/package.mo")

false

>>> getErrorString()

"[/home/martin/dev/Thermocycle-library/ThermoCycle/Obsolete/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Media/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Interfaces/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Interfaces/Fluid/Flange.mo:16:17-16:58:writable] Warning: The file was not encoded in UTF-8:

  "<html> University of Li?ge, November 2012".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Icons/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Functions/package.mo:12:32-12:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Examples/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Examples/TestFunctions/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Examples/TestFluid/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Examples/TestComponents/package.mo:6:32-6:104:writable] Warning: The file was not encoded in UTF-8:

  "<HTML> <p><big><dl><dt><b>Main Authors:</b> <br/></dt> <dd>Sylvain Quoil...".

  Defaulting to 7-bit ASCII with unknown characters replaced by '?'.

  To change encoding when loading a file: loadFile(encoding="ISO-XXXX-YY").

  To change it in a package: add a file package.encoding at the top-level.

  Note: The Modelica Language Specification only allows files encoded in UTF-8.

[/home/martin/dev/Thermocycle-library/ThermoCycle/Examples/TestComponents/package.mo:2:1-18:19:writable] Error: Test_Flow1Dinc_CP was referenced in the package.order file, but was not found in package.mo, Test_Flow1Dinc_CP/package.mo or Test_Flow1Dinc_CP.mo.

"

Fix by following instructions in https://trac.openmodelica.org/OpenModel … tLibraries

find . -name package.order -exec rm {} ";"

Then it works:

[martin@mega Thermocycle-library]$ OMShell-terminal 

OMShell Copyright 1997-2014, Open Source Modelica Consortium (OSMC)

Distributed under OMSC-PL and GPL, see www.openmodelica.org



To get help on using OMShell and OpenModelica, type "help()" and press enter

Started server using:omc +d=interactive > /tmp/omshell.log 2>&1 &

>>> loadFile("ThermoCycle/package.mo")

true

You can try to simulate for a shorter time and enable performance profiling to see which blocks are slow to solve. You could also try a different solver to see if it is dassl that found a stiff system and decreases the step size.

You just need to download the library from github (https://github.com/modelica-3rdparty/Th … e-library) and manually fix the errors in the packaging of the library (remove package.order files since the shipped ones are broken).

If it is an XML-file and the functionality can be reproduced by Modelica, I would suggest using an XSL transform from XMILE to Modelica. It would then work in any Modelica tool.

You need to follow all the steps to also search OpenModelica's port repository. The default one does not have it.

You could always add the MSL components as protected components.

Modelica.Electrical.Spice3.Examples.CoupledInductors should work without warnings. Nand and Nor should work with some of those warnings/errors added. But it will still run fine.

That's just a notification telling you the library is bad, and how openmodelica ignored the errors. You will not be able to use omedit though. It does not handle MSL 2.2

That's just a notification telling you the library is bad, and how openmodelica ignored the errors. You will not be able to use omedit though. It does not handle MSL 2.2

Yes, BondLib is shipped with openmodelica. At least with the latest nightly builds. If you run Linux you need to install package omlib-bondlib-2.3 or something like that.

OpenModelica does not support HideResult. So adding it does nothing. Even if a variable is protected, OpenModelica will sometimes allow you to change its start value (which is what is shown in the variables browser).
Parameters are always output to the result-file since they are so small. Alias variables are also always output if the main variable is. So:

model HideResult

protected

  parameter Real param = 1;

  Real var;

equation

  var = 3 * param;

end HideResult;

If you only have var = param, param does not take up space in the mat file and is output anyway.

Use the version shipped with OpenModelica. It loads fine. Note that it depends on Modelica 2.2, which OMEdit does not support.

I already did fix some issues in the bootstrapped version. It works for n=2000 now. n=9000 causes the garbage collector to abort due to trying to allocate a too large block.
The RML version will be discontinued after the next release though. One of the changes in that version is that it uses the regular C stack for local frames. The RML version manages local frames explicitly on the heap. So the implementation is quite different; but it is possible to use "ulimit -s 16384" or even higher in the bootstrapped compiler if you need more stack space.
Another difference is that if you compile the bootstrapped version without optimizations (-O0), for example for debugging... You will get a different limit for recursive function calls since each stack frame will use more memory

Anyway, if you find more functions that are not tail recursive and trigger stack overflows, post them at https://trac.openmodelica.org/OpenModelica/newticket. Many of them are easy to fix.

It might be that your model triggers omc to crash. A segmentation fault or so.

Exit python and run killall omc should clean up enough.

Oh, and if it is a stack overflow, post the whole trace, like:

[bt] #4            /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_BackendEquation_traverseBackendDAEExpsEqn+0xc8d) [0x7f251358124d]

[bt] #5            /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_SynchronousFeatures_getVariableLists2+0x17d9) [0x7f25133f92e9]

[bt] #6..15868     /home/martin/trunk/build/bin/../lib/omc/libOpenModelicaCompiler.so(omc_SynchronousFeatures_getVariableLists2+0x180c) [0x7f25133f931c]

The function with over 15000 iterations would be the culprit, not the functions higher up.

Did you use good optimization flags (same as the desktop)? The simulation could crash in these functions if you trigger a stack overflow (which is likely if no variables were optimized away from the stack). Are you using omc-bootstrapped on both machines or omc-rml on one of them?

Did you mix compiler versions without make clean in-between? Or did you perhaps run out of memory? Is this a 32-bit or 64-bit system? What model are you simulating? Big/small?

gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-8ubuntu1) works fine for us.

You can try to disable optimization modules, but the model might not translate if you do:

omc +help=optModules

+preOptModules=
+postOptModules=
+indexReductionMethod=uode
+tearingMethod=noTearing

You can see all operations performed by the compiler by using the debugger. Translate a model with debug information available (Tools->Options->Simulation->Generate operations). Then either click to always open the transformational debugger, or go to file->open and find the generated ModelName_info.xml and view the transformations performed.

Not all equations are kept, but I would expect in this case the two equations are kept as is since you would anyway need to solve for A in most cases (A output to result-file).

Oh. And simplifications refers to simplifications done within an expression. The optimizations performed on multiple equations are done by the preOpt and postOpt modules (which in turn call simplify a lot, so +noSimplify can have an impact on performance).

+noSimplify is a misnomer. The flag disables the most expensive simplifications (which are rare and only sometimes results in better code).

Real Pup(start=x, fixed=true) ;

Your code fragment works fine for me. You would need to post a complete model.

This is flattening or instantiation. instantiateModel(ModelName) will list the flattened model.

You can do something like this:

model M

  Real t1=15,t2=if time < 20 then -time else (if time < 21 then time else -time),td=t1-t2;

  Real timer(start=20);

  Boolean timerEnabled;

equation

  der(timer) = if timerEnabled then -1.0 else 0.0;

  assert(timer > 0.0 or not timerEnabled, "...");

  when td > 20 then

    timerEnabled = true;

    reinit(timer, 20);

  elsewhen td < 20 then

    timerEnabled = false;

  end when;

end M;

Yes. The oldest compiler we use to compile is gcc 4.4. GCC 4.1 is from 2006,

It is something related to the dependency analysis of function calls: unused functions are removed from the C-code. Probably the partially evaluated function call is forgotten.

The # is an internal thing for handling calls to function pointers (all values are passed as a void*). The unbox() operation is the inverse.

Can you create a ticket at https://trac.openmodelica.org/OpenModelica/newticket? The problem seems to be related to checkModel() only. Instantiation and simulation works...

Use the latest nightly build instead; it has many fixes regarding function partial application.

What OpenModelica revision did you run this in? The following works fine for me using r21721:

model M

  import SI = Modelica.SIunits;

  record State

    SI.Temperature T;

    SI.AbsolutePressure p;

    Real omega;

  end State;



replaceable function equilibriumPressureAdsorption

    input State s;

    output SI.Pressure p_eq;

  end equilibriumPressureAdsorption;



  function equilibriumLoadingAdsorption "Uses modelica's root finding algorithm to calculate the equilibrium loading based on the equilibrium pressure function"

    input State s;

    output Real omega_eq;

  algorithm

    omega_eq:=Modelica.Math.Nonlinear.solveOneNonlinearEquation(function equilibriumLoadingAdsorptionDummy(s = s), 0, 0.02, 1e-006);

  end equilibriumLoadingAdsorption;



  function equilibriumLoadingAdsorptionDummy

    extends Modelica.Math.Nonlinear.Interfaces.partialScalarFunction;

    input State s;

  algorithm

    y:=equilibriumPressureAdsorption(State(T = s.T, p = s.p, omega = u)) - s.p;

  end equilibriumLoadingAdsorptionDummy;



  Real r = equilibriumLoadingAdsorption(State(time,2,3));

  annotation(uses(Modelica(version="3.2.1")));

end M;

Just run the generated executable.

You can call cd() to change the working directory of omc in OMPython.

https://build.openmodelica.org/Document … aPath.html
https://build.openmodelica.org/Document … aPath.html

It's not an error; just a notification that two different nominal values were set for an alias (nominal values are not as important as start-values, but nominal values do affect some simulation results):

model M

  Real a(start=0),b(start=1);

equation

  a = b;

  der(a) = 1.0;

end M;

(Here, omc picks b.start=1.0 in my version as it is ambiguous)

It's the same interface as regular omc, so read the documentation for those

I would guess simulate(Buildings.Airflow.Multizone.Examples.Validation3Rooms) ...

So in OMEdit. I don't think the plotting view will show the full digits. You can always simulate (or open a result-file) using omc and query the value at a specific point in time: https://build.openmodelica.org/Document … g.val.html (it will print the full 15 digits or so that double precision floating point can store).

In which view do you need to show more digits? Double precision is limited and the solver tolerance you set affects the precision even further.

Same way you do it in OMShell. Send the -override or -overrideFile flag to the simulation executable.

Run checkSettings(); it will tell you the paths you need to install libraries into. apt-get install omlib-buildings-latest should install a working Buildings version. Run getErrorString() after the loadFile command to find out why you could not load it. You wanted to run loadFile("/home/ubuntu/miglu/Buildings/package.mo").

It is also possible to just do "pip install ompython". Although that will not be the latest sources, OMPython rarely changes.
apt-get install ompython should also do the trick.

MSL3 = Modelica Standard Library 3.x
https://test.openmodelica.org/libraries … rsive.html contains a list of classes that are ready to be simulated. To get graphs, click on the signals to select the signals you want to plot. Probably the most interesting variables are the state variables: https://test.openmodelica.org/libraries … ario_9.err

There are various ways to get the equations. The easiest is the ModelName_info.xml generated in the working directory. Or use https://build.openmodelica.org/Document … MLDAE.html (translation levels are flat, optimiser, backEnd, or stateSpace). Otherwise, look through the debug options using "omc +help=debug" or help("debug") in OMShell to see some intermediate representations of the model.

Usually someone will answer questions. I get email notification for all posts to these forums.

Probably because OpenModelica does not know the inverse of log10. If you give tk2 a start-value of 36.4, it finds the solution using a non-linear solver.

Ascold wrote:

sjoelund.se wrote:

(Note that complex solutions are not solutions in Modelica; the equation should not be possible to solve)

I didn't understand what do you want to say me.

Your equation has four solutions; for example:
x = 0.5389-1.4934 i

Modelica Real numbers are not imaginary. So your model should be unsolvable. And OpenModelica says it was unable to find a solution; so it did the right thing telling you that.

Same thing. Just an older omc version. Exit code -1 is the same as 255 (because on Linux the exit code is an unsigned char).

(Note that complex solutions are not solutions in Modelica; the equation should not be possible to solve)

Look closer. You also got another error-message:

LOG_NLS        | warning     | nonlinear system 2 fails: at t=0 Debug more

|        | |     | | proper start-values for some of the following iteration variables might help

|        | |     | | [1] Real x(start=0, nominal=1)

assert        | debug     | Solving non-linear system failed at time=0.

For more information please use -lv LOG_NLS. Debug more

Simulation process exited with code 255

You can change Boolean variables during simulation, but not Boolean parameters.

I would create a bug report: https://trac.openmodelica.org/OpenModelica/newticket
The model triggers a stack overflow in the compiler. You can see it if you run the following mos-script using omc-bootstrapped:

loadModel(Buildings,{"latest"});getErrorString();

translateModel(Buildings.Examples.Tutorial.SpaceCooling.System3);getErrorString();

You are only supposed to be able to use ":=" for bindings in functions (and then only use ":="). In all other cases "=". In the OpenModelica, we cannot distinguish between the two so both are accepted. Try for example:

loadString("model M

  Real r := time;

end M;");

list();

Why do you use listAppend(inStrCR,{selectCR})? This is a very slow operation; selectCR :: inStrCR is much faster.

You would need to add URL's as Strings. The usual way to add URL's to Modelica models is through the documentation annotation: Documentation(info="<html><a href=\"...\">...</a></html>")

If you want a new annotation, you should make it a vendor-specific annotation:
annotation(__MyPrefix_MyNewAnnotation = "http://...")
or
annotation(__MyPrefix(MyNewAnnotation = "http://..."))

Is there anything OpenModelica uses that actually needs the PATH? Maybe try unsetting it in cmd.exe before calling omc.

model Test 

    import SI = Modelica.SIunits; 

  parameter SI.Temperature T; 

initial equation 

    T = (300+400)/2; 

end Test;

is basically transformed into:

model Test 

    import SI = Modelica.SIunits; 

  parameter SI.Temperature T(fixed=false); 

initial equation

    T = T.start;

    T = (300+400)/2; 

end Test;

The variables browser will show the start-value because that is all that is available to it (the information before simulation starts).

In Modelica, variables will have fixed=false by default. But parameters have fixed=true.

If you don't have OMDev installed and updated, unset the environment variable and reboot windows.

Does the text-box with simulation output give you any messages? Like:
/tmp/OpenModelica_marsj/OMEdit/Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_DOL -port=34027 -logFormat=xml -w -lv=LOG_STATS
LOG_STATS        | info     | ### STATISTICS ###
...

There are 3 AIMC_DOL examples; which one are you having trouble with?

You can ignore them

It's been in Modelica language spec since 3.2 (March 2010), and OpenModelica earlier than that.

The dot in front of a name means "do lookup from the root", which gives faster translation times if a Modelica tool does lookup as described by the specification in addition to looking outside encapsulation, etc.

Try:

model N

  Real r;

end N;



model M

  type N = Real;

  .N  n;

end M;

Or actually (because you should not connect two connectors that are both in the same model):

connector ConnOutModif

  flow Modelica.SIunits.VolumeFlowRate Q;

  Modelica.SIunits.MassConcentration So;

end ConnOutModif;



model M

  ConnOutModif c;

end M;



model SimplePump "modified pump"

  parameter Modelica.SIunits.VolumeFlowRate Q_min = 1.0 "minimum pump capacity";

  parameter Modelica.SIunits.VolumeFlowRate Q_max = 10.0 "maximum pump capacity";

  Real H(start = 1.0);

  M In,Out;

  Modelica.Blocks.Interfaces.RealInput u;

equation

  H = 0.5 * ((-Q_min) + Q_max) + u * 0.5 * ((-Q_min) + Q_max) + Q_min;

  Out.c.Q = -(if H > Q_max then Q_max else if H < Q_min then Q_min else H);

  connect(In.c,Out.c);

 end SimplePump;

And you realise you miss an equation for .So.

The problem here is that if you have two unconnected connectors, they will each generate one flow equation. You added:
  Out.So = In.So;
  Out.Q + In.Q = 0;
Which would be automatically generated by connecting the two connectors. You could change the connector to a model and the flow to nothing. Or better:

connector ConnOutModif

  flow Modelica.SIunits.VolumeFlowRate Q;

  Modelica.SIunits.MassConcentration So;

end ConnOutModif;



model SimplePump "modified pump"

  import ConnInModif = ConnOutModif;

  import ConnOutModif;

  parameter Modelica.SIunits.VolumeFlowRate Q_min = 1.0 "minimum pump capacity";

  parameter Modelica.SIunits.VolumeFlowRate Q_max = 10.0 "maximum pump capacity";

  Real H(start = 1.0);

  ConnInModif In;

  ConnOutModif Out;

  Modelica.Blocks.Interfaces.RealInput u;

equation

  H = 0.5 * ((-Q_min) + Q_max) + u * 0.5 * ((-Q_min) + Q_max) + Q_min;

  Out.Q = -(if H > Q_max then Q_max else if H < Q_min then Q_min else H);

  connect(In,Out);

 end SimplePump;

This is still unbalanced because you forgot an equation:
OpenModelica says: Error: Internal error Found Equation without time dependent variables In.Q = 0.0

Hard to know without ConnInModif

Does buildModel work? Maybe it is not counting the external object. The checkModel count is different from the one used when actually trying to compile a model.

You have a top-level input variable "u", which as far as I know is special and might not count (is ignored for counting). And source.w has a binding equation (which is your 11th equation).

Which of the revisions of each specification? We have 3.2 3.2r1 3.3 3.2r2 and soon 3.3r1. https://modelica.org/documents has versions with changemarks.

Is this on a clean checkout with the latest OMDev version?

The .mof file is not intended to be usable for re-compilation. It is only for diagnostics.

Should be fixed in r21083. New nightly builds appear in around 12 hours if nothing breaks them.

It seems we need to make some fixes for modelica3d again... I added a check for an illegal feature used by the library:

[/home/marsj/trunk/build/lib/omlibrary/ModelicaServices 3.2.1 modelica3d/Modelica3D/package.mo:455:5-505:23:writable] Error: Function Modelica.Mechanics.MultiBody.Visualizers.Advanced.Shape.shapeDescrTo3D returns an external object, but the only function allowed to return this object is ModelicaServices.modcount.HeapString.constructor.

The warning in functions is because some variables in those functions are not defined properly (there is no default=0 in Modelica). As such, some inputs of those functions give undefined results. The functions in question were copy-pasted from an earlier MSL version. Current MSL fixed all those warnings.

Chattering is a state event switching rapidly. Like
model M
  Real r(start=1,fixed=true);
equation
  der(r) = if r>0 then -1 else 1;
end M;
It is pretty much impossible to get numerical accuracy for that model...

You should have the files in: D:/users/Lewis/Modelica/001_OpenModelica/lib/omlibrary/ModelicaServices 3.2.1 modelica3d/Resources/Include/
If you don't, it might have been fixed in the nightly build.

Then do not load the Internal.mo. It is only for MSL 3.1. Skip that or simply call: loadModelica3D()

Do you have MSL 3.1 or 3.2.1 loaded? getVersion(Modelica) should tell.

Not yet. A few parts of 3.3 will work. The synchronous features do not.

The splitting into ordered and known variables is done by various optimizations in the backend. Pretty much all of them are essential for getting a working simulation. So you might want to dump an earlier stage in the compilation if you want to keep more structure as it used to be.

You should be able to use http://www.mathworks.se/help/pdf_doc/ma … format.pdf (the last pages)
We use our own C implementation (which has a BSD-license option): https://openmodelica.org/svn/OpenModeli … _matlab4.c

You need to use Dymola; StateGraph2 is not really a Modelica library: https://trac.modelica.org/Modelica/ticket/984

First hits in google: https://openmodelica.org/index.php/forum/topic?id=434
The dataInfo matrix corresponds to names and descriptions. It contains the data_n matrix, column number, interpolation and something else (Dymola knows; probably discrete variables). The dataClass matrix contains some info if the data_2 matrix is transposed or not, some version number for Dymola features.

Well, the modulo function is a discrete function that even triggers events when the output changes. Since it is not a continuous function, you can not take the derivative of such a signal. Use der(x) instead - it is continuous and nice.

I am assuming the "false" before the simulate command is a loadFile command or similar. You probably want to insert a getErrorString() command there to get the parser error since simulate() clears the errors.

Sort of. You can call:
/opt/dymola/bin/dymola.sh -NoWindow someFile.mos

But you will not get any log-file output unless you call such a function from the script. And unless you call exit(), the process will keep running (and mos-scripts stop running on failure, so just adding an exit() at the end does not help).

I am sure there are some ways that work better. I just don't know them.

The red/green is the diff from the substitution evaporation to gastemp. Probably from a connection. If the component did not exist in one of them: is it an expandable connection? You might be able to tell some from instantiateModel and looking at the flat Modelica code.

Read the Fluid documentation:
https://build.openmodelica.org/Document … onent.html

Basically, just drag a Fluid.System object into the model you want to simulate. Take a model like Examples.DrumBoiler. It has a component:
inner Modelica.Fluid.System system annotation(Placement(transformation(extent = {{-90, 70}, {-70, 90}})));

So you do need it

$ port variant openmodelica-devel

openmodelica-devel has the variants:

   ...

   libraries: installs the complete Modelica library collection

Or just port install openmodelicalibraries. The dependency omlib-complex-3.2.1 should contain /opt/local/lib/omlibrary/Complex 3.2.1.mo

You can get these types of error-messages because OpenModelica checkModel does not check local balance of models. Consider for example:

model M

  Real x,y,d;

equation

  d = 0;

  x = time + y*d;

  x = sin(time);

end M;

checkModel will tell you this system is fine because it has 3 equations and 3 variables.

But if you try to simulate the model, the compiler tells you it cannot solve for y. (Or that it could not sort for x and y).

I would guess an optimization module transformed your model into something that looks like this and the sanity check caught it.

+d=optdaedump can be used to debug the optimizations when running omc from command-line.

configure --without-paradiseo

Check anyStringWork in https://openmodelica.org/svn/OpenModeli … modelica.c if you are using the bootstrapped OpenModelica compiler (libomparse.a). All data is stored in the data of a void*. Integers are stored in memory, with one bit lost to tag the data as integer.
Otherwise, the data is boxed and the header tells you what datatype it is. Use the meta_modelica.h macros to walk the AST since the format may change (we have some #ifdefs that changes the layout slightly, for example which bit decides if the data is Integer or not).

Since you use C0 as a start-value, it is required to be a parameter expression. Parameter expressions can never change, so what you try to do is impossible.

unzip

It would be complicated, slow, and cost too much maintenance on our side to transfer ASTs. If you take something simple like:

model M

  Real r = 11.2;

end M;

The AST for that is:

Absyn.Program.PROGRAM(classes = {Absyn.Class.CLASS(name = M, partialPrefix = 0, finalPrefix = 0, encapsulatedPrefix = 0, restriction = Absyn.Restriction.R_MODEL(), body = Absyn.ClassDef.PARTS(typeVars = {NIL}, classAttrs = {NIL}, classParts = {Absyn.ClassPart.PUBLIC(contents = {Absyn.ElementItem.ELEMENTITEM(element = Absyn.Element.ELEMENT(finalPrefix = 0, redeclareKeywords = NONE(), innerOuter = Absyn.InnerOuter.NOT_INNER_OUTER(), specification = Absyn.ElementSpec.COMPONENTS(attributes = Absyn.ElementAttributes.ATTR(flowPrefix = 0, streamPrefix = 0, parallelism = Absyn.Parallelism.NON_PARALLEL(), variability = Absyn.Variability.VAR(), direction = Absyn.Direction.BIDIR(), arrayDim = {NIL}), typeSpec = Absyn.TypeSpec.TPATH(path = Absyn.Path.IDENT(name = Real), arrayDim = NONE()), components = {Absyn.ComponentItem.COMPONENTITEM(component = Absyn.Component.COMPONENT(name = r, arrayDim = {NIL}, modification = SOME(Absyn.Modification.CLASSMOD(elementArgLst = {NIL}, eqMod = Absyn.EqMod.EQMOD(exp = Absyn.Exp.REAL(value = 11.2), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 2, columnNumberStart = 10, lineNumberEnd = 2, columnNumberEnd = 16, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)))))), condition = NONE(), comment = NONE())}), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 2, columnNumberStart = 3, lineNumberEnd = 2, columnNumberEnd = 16, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)), constrainClass = NONE()))})}, ann = {NIL}, comment = NONE()), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 1, columnNumberStart = 1, lineNumberEnd = 3, columnNumberEnd = 6, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)))}, within_ = Absyn.Within.TOP(), globalBuildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09))

In addition, the AST used by OpenModelica changes while Modelica concrete syntax stays the same. Guess which one is easier to translate a DSL into? If you translate into Modelica code you also have the benefit of only having to learn Modelica. With OpenModelica abstract syntax you also need to learn some things about the compiler infrastructure (the AST is not only Modelica; it includes MetaModelica, ParModelica, parts of Optimica, and experimental/future versions of Modelica).

The working parts of the Java interface is pretty much the CORBA communication. Which is text-based. There probably exists a way to communicate using CORBA from Perl. You would just lose the parsing of the omc output into nicer data types.
Regardless, you would need to transform your DSL into Modelica textual code somewhere.

I think it is also still possible to use the Java interface to parse Modelica text into an AST in Java. But there is no way to go back, and it seems much too complicated. Even if the interface could unparse the Java classes back to Modelica text, I believe it would be simpler to just transform the DSL into Modelica text.

The only thing that might be tricky is pretty-printing the generated Modelica code. But if it is just generated code, do you need to look at it and need it to be perfectly formatted? If you do need that, it is always possible to do:
loadFile("uglyCode.mo");
writeFile("prettyCode.mo",list());

Just ignore those warnings. They occur because the function contains only one statement: assert(false, ...); These functions are not defined for R134a.

Alias variables appear because you have code like "a = b", usually from making connections. The mat format uses them to compress output files.

loadString("model M

  Real x = time;

  Real y = x;

end M;");getErrorString();

buildModel(M);getErrorString();

system("./M -override outputFormat=csv");

system("./M -override outputFormat=mat");

readSimulationResultVars("M_res.mat");

readSimulationResultVars("M_res.csv");



system("./M -override outputFormat=csv,variableFilter=x");

system("./M -override outputFormat=mat,variableFilter=x");

readSimulationResultVars("M_res.mat");

readSimulationResultVars("M_res.csv");



system("./M -override outputFormat=csv,variableFilter=y");

system("./M -override outputFormat=mat,variableFilter=y");

readSimulationResultVars("M_res.mat");

readSimulationResultVars("M_res.csv");

Above, you can see that filtering on x will cause x and the main variable y is output. If y is requested, only y is output. For csv-files you get at most twice as many variables as you intended to filter.

If you use the mat4 format, aliases of the filtered variables might still appear in the result-file. They don't take up any extra space anyway.

Perhaps the following works for you:

model M

  discrete Real r(start=0, fixed=true);

equation

  when time>0.5 then

    terminate("end");

  end when;

  when terminal() then

    r = time;

  end when;

end M;

I get the expected output:

$ ./M -output=r

[/home/martin/tmp/a.mo:5:5-5:21:writable]

stdout            | info    | Simulation call terminate() at time 0.500000

|                 | |       | Message : end

time=0.50000000015000567455,r=0.50000000015000567455

regex is common to very many applications (for example searching for text in most text editors): http://en.wikipedia.org/wiki/Regular_expression

The pipe (|) is the or operator

It's a regular expression (full match). The default is ".*"

Yes. It's the source of the library, so it's the logical place to make changes. We don't patch libraries except ModelicaServices and some old versions of MSL because it is better if it is fixed at the source so we don't need to patch the next release and the one after that. And the one where only whitespace changed and broke the patch, etc.

You either make a pull request (very simple; just do fork the repository, do git clone, git checkout -b nameOfMyTopicBranch, edit the files, git commit, git push, go to your repository, select the topic branch and choose to make a pull request). Or you can open an issue: https://github.com/modelica/PowerSystems/issues. But opening tickets without a pull request means someone needs to understand exactly what you want done, find the time to do it, and so on. With a pull request he just needs to verify that your changes are sane and then accept them.

https://github.com/modelica/PowerSystems - pull requests are welcome and once accepted become part of the version shipped with OM.

Did you run the getErrorString() command?

Why would negative time not make sense? Let's say you want to simulate a civilization from 500 BC to 1800 AD and select time=1 year, with positive values as AD

JoakimSandin wrote:

I have a continuous Real variable h and I need to use the previous value of that variable in an equation.

It does not have any such value unless you declare the variable "discrete Real". But those cannot change continuously (cannot be a state, etc).

Using the simulate() command.

Judging by how old the library, I would guess it is using Modelica 1.x annotations, which are ancient. OMEdit requires Modelica 3.x graphical annotations. You would probably fail to simulate any models in it using OMEdit since it also uses an old MSL version. Command-line omc might work.

The matching part of translation might be sped up about 10 times. If you run the simulate command you see a bunch of times. Matching is a small part of timeBackend.

No space. That adds a new argument.
-override=var1=val1,var2=val2 or -override var1=val1,var2=val2

Trust me, you never want to use "time" directly to model physical behaviour. Physics really is about relative time. You should probably do:

model M

  parameter Real startPos = 100;

  Real x(fixed=true,start=startPos);

  Real distance = startPos-x;

equation

  der(x) = -1.0;

  when x < 0 then

    terminate("drop hit the ground");

  end when;

end M;

You get something like:

stdout            | info    | Simulation call terminate() at time 100.000000

|                 | |       | Message : drop hit the ground

Yes. Not writing code that triggers division by zero... Using limits and rewriting the expression I suppose. Infinity is not a valid real value in Modelica.

atan may be able to evaluate any real value. But division does not.

By using loadFile("myLibrary.mo") or loadModel(myLibrary) if it is on your getModelicaPath()

There is. The default on Linux and OSX is 64-bit builds. And a 64-bit Windows build is in the works.

Sample program+output:
http://dev.openmodelica.org/~marsj/forums/vanderpol.png

Of course. That's the whole point of it.

It's an error estimate of derivatives only. The code does not specify how the local error is estimated. You can check http://www.netlib.no/netlib/ode/ddasrt.f

It's the integrator error tolerance. If you use dassl with a low (1e-3) tolerance you get faster simulation but a bigger allowed error.
Note that some models simulate faster with a higher tolerance (1e-6 or 1e-7) because it helps getting better guesses for non-linear systems.

Note that the error is accumulated. If you want a maximum error of 1e-3 you might have to use a tolerance of 1e-5, etc.

You are not allowed to assign to an external object except in the declaration binding. You can never change an external object pointer or alias one external object to another.

It should be enough to post the model and say that code generation for Modelica.Math.Matrices.LAPACK.dorgqr is broken in WSM, but working in omc.

I created a more complete example, which works fine (at least compiles fine) in current omc. The Wolfram backend and code generation is different from the omc one though. You should try contacting them.

model M

  import Modelica.Math.Matrices; 

  Real A[3,2];   Real b[3]; 



  Real Q [3,2];   Real QT [2,3];   Real R [2,2]; 

  



  Real gammalyp[2](each start=1.0); 

  

  Integer i(start=0); 

  parameter Real stime = 0.2;

  Real pcon1 = 1;

  Real pcon2 = 1;

  Real pcon3 = 1;

  Real errsamp1 = 1;

  Real errsamp2 = 1;

  Real errsamp3 = 1;

algorithm 

  when sample(0, stime) then 

      i:=i + 1; 

    if noEvent(i >= 4) then 

      A:=[pcon1,1;pcon2,1;pcon3,1]; 

      b:={errsamp1,errsamp2,errsamp3}; 

      (Q,R):=Matrices.QR(A); 

      QT:=transpose(Q); 

     gammalyp:=Matrices.solve(R, QT*b);

   end if;

  end when;

end M;

https://build.openmodelica.org/Document … arize.html should help with the state-space description if I am not mistaken.

We use ODE solvers to simulate, so it should always be a (hybrid) ODE that you get out of OpenModelica at the final step of translation.

https://trac.openmodelica.org/OpenModelica/newticket - Component Frontend, set CC to "perost". It should be a quick fix for him.

It means some models will work.

It won't simulate in any version of OpenModelica. You can see the status of models in the standard library here:
https://test.openmodelica.org/libraries … rsive.html

Setting the override only sets their start-values; it does not make them into constants.

Only start-values of fixed variables are actually used. If you want to set a particular start-value, you need to set fixed=true.
The overrides only change given start-values. They cannot change the warning you get since this is a warning from buildModel, which will not consider values you try to set later on. At simulation-time, the start-values to use have been chosen - you can change the values but not which variables are used for the initial system.

Consider for example:

model M

  Real x(start=3.0),y(start=4.0);

equation

  x = y;

  der(x) = 1.0;

end M;

It gives the following output:

$ ./M -output x,y -override stopTime=0

time=0,x=4,y=4

$ ./M -output x,y -override stopTime=0,x=5

time=0,x=5,y=5

$ ./M -output x,y -override stopTime=0,y=7

time=0,x=4,y=4

And the following warnings:

Warning: Alias set with several free start values

 * candidate: x(start = 3.0)

 * candidate: y(start = 4.0)

=> select value from y(start = 4.0)

   because its component reference (or its binding component reference) is closer to the top level scope with depth: 1.

   If we have equal component reference depth for several components choose the one with non zero binding.

Warning: Assuming fixed start value for the following 1 variables:

         x:VARIABLE(start = 4.0 ) .M, .Real type: Real 

In OpenModelica, we never do unit checking.
Some other tools also does not do unit checking by default (checkModel() command or similar in these tools will do unit checking).

https://trac.openmodelica.org/OpenModelica/newticket - create one for OMEdit. The results in the files are identical. I suspect the csv-parsing routines in OMPlot don't handle variable names with commas in them...