The following tells me the files are the same...

loadModel(Modelica);getErrorString();

simulate(Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum,outputFormat="mat");getErrorString();

simulate(Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum,outputFormat="csv");getErrorString();

diffSimulationResults(

  "Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum_res.mat",

  "Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum_res.csv","diff",

  keepEqualResults=true);

getErrorString();

Which variables differ?

We don't keep statistics on test coverage on Windows. It's a too minor platform The Linux tests for both of them are 100% (of the tested models).

I recommend the nightly builds unless you need to use a stable version for education or similar.

These ones are more recent:
https://build.openmodelica.org/omc/buil … 9.1/beta1/
https://build.openmodelica.org/omc/buil … ly-builds/

You can add your email as CC to https://trac.openmodelica.org/OpenModelica/ticket/2079 or just spam the ticket so Adeel realizes people really, really want it

The builds should be working now

https://build.openmodelica.org/Document … pting.html or read the help-text through help() (basically telling you to open OpenModelica.Scripting in OMEdit).

Note that the silent plotting is usually not enabled. You have to explicitly do it yourself. For example by sharing a session with OMNotebook...

Yes, r19150 is broken on all platforms I hope to fix them soon. Else, the openmodelica or openmodelica-release packages should work at the moment.

http://trac.macports.org/

Check the log-file first and make sure XCode is setup correctly.

Did you install a custom shell that could mess with extensions not being auto-completed?

Run getErrorString() to get error-messages.

By default, fixed=false. This means you need to add an initial equation in order for the initial conditions to be fully specified.
Fixed=true means "use the start-value as initial condition".

setCommandLineOptions("+d=initialization") just adds more details to the warnings. Some working models have several thousand underspecified initial conditions, so they are hidden by default. It's good to fully specify the initial conditions since otherwise we might find another valid (unexpected) solution.

https://trac.openmodelica.org/OpenModelica/newticket select component OMNotebook.

And yes, models can have inputs. Blocks are specialized models that have only input/output public variables. (As opposed to models, which are more generic)

Yes, to pass balanced model checking (which OpenModelica does not yet perform), I believe some of the variables in Rocket would have to be marked "input".

OMNotebook and OMEdit settings are not linked together in any way.

You can use setCommandLineOptions("+d=initialization") in an OMNotebook cell and evaluate that.

Now it's easier to explain We don't build packages for 12.10 any longer. I intended to keep the repository working, but it seems the clean-up script removed some of the packages anyway...

This is a list of the currently built images:
precise-amd64
precise-i386
raring-amd64
raring-i386
saucy-amd64
saucy-i386
squeeze-amd64
squeeze-i386
trusty-amd64
trusty-i386
wheezy-amd64
wheezy-i386

Check your /etc/apt/sources.list.d/openmodelica.list - it should contain one of the entries. The nightly installs the latest.

Looking at the start of the thread... If you are using Ubuntu, why are you using the tar.xz instead of apt-get?

So where are you running it from? The rpath should find the shared library relative to the executable (uses rpath origin). For me it looks like:

$ ldd /usr/bin/omc

    libOpenModelicaRuntimeC.so => /usr/bin/../lib/omc/libOpenModelicaRuntimeC.so (0x00007fc71ad8a000)

    libfmilib_shared.so => /usr/bin/../lib/omc/libfmilib_shared.so (0x00007fc717db3000)

Try running /usr/bin/omc ++v. If it's not working OMEdit will not work either.

The new version doesn't include omc in the tar.xz directly. You need to symlink /usr/bin/omc-rml or /usr/bin/omc-bootstrapped to /usr/bin/omc for it to work.

runScript will not work during simulation runtime. And the time at which it is evaluated during translation is random as well... There is no way to specify in experiment annotation or similar that a script should be run before simulating.

To read files relative to the library, use modelica:// URLs, see https://build.openmodelica.org/Document … ource.html

Modelica has no concept of solver iteration and there is nothing like this you can do. No way to get the time and value of the previous step, and thus no way to for example write inline solvers in a nice way.

We already do build libf2c in the makefiles, and we create the arith executable, which generates arith.h. What did not work using that process. What did you change? Also, https://trac.openmodelica.org/OpenModelica/newticket is the correct forum for build processes (these forum threads get lost because they don't show up as open in trac).

The order of components matter for records and functions. Maybe connectors; I am not sure about those. In general order does not matter in Modelica. And this is why inheriting the same class twice works (as long as every modifier is the same; this is hard to guarantee so it is not recommended to abuse this pattern).

You cannot declare new variables inside an equation section (so skip the Real keyword). Also, you are always assigning element A[3,3] to all elements in the array. And the dimensions of B must be known (10 instead of : ). So something more like:

model fourD 

  Real A[3,3]={{1,0,0},{0,10,0},{0,0,1}}; //This is the matrix which will be the elements of the 4D array// 

  Real B[10,10,3,3];   //4D arrray

equation 

  for i in 1:10 loop

    for j in 1:10 loop

      if i==j then

        B[i,j] = A;

      else

        B[i,j] = zeros(3,3);

      end if;

    end for;

  end for; 

end fourD;

sorry, I meant to write max(ax+b,0)

No, it cannot be called a 3D array. 4D maybe... And I still don't know how you would put a 3x3 matrix diagonally into something else... I would suggest you put a table of:

B[0,0,0,0] = ...

B[0,0,0,1] = ...

To see what you really mean.

Do you mean something like:
B[0,0,:,:] = A1
B[1,1,:,:] = A2
B[2,2,:,:] = A3

Where A1..AN are 3x3 matrices?

See, I don't understand at all what you want the matrix to look like

{diagonal(1:3) for i in 1:10} maybe?

y=min(ax+b,0)

3x3x3 arrays are declared as such:

Real x[3,3,3];

Move the equation keyword up 2 lines. for-equations are equations and need to be in an equation sections.

You're missing an equation keyword I guess.

There is indeed a syntax error in your code.

You are supposed to write:

within WasteWater.ASM1.Interfaces;

partial model ASM1base

  // ...

https://openmodelica.org/svn/OpenModelica/trunk/doc/

Read the rest of the commands used: https://build.openmodelica.org/Document … ica3D.html
(In particular where you need to insert this inner component to make Modelica3D happy)

Maybe. I don't have any Windows machine to test it on

Isn't it python that needs it? I don't think OpenModelica needs it...

Copy that dll around to every single directory on your system so it can be found. That usually works for Windows

Or use Linux; works flawlessly there.

It's quite simple. You are trying to instantiate a function, which is impossible to do

Call the function from OMShell if you want to see the results. Or don't. Modelica_LinearSystems2 is not 100% pure Modelica. It uses Dymola-specific plotting extensions to Modelica and these parts of Modelica_LinearSystems2 will not work with OpenModelica.

Tools->OMC Logger would not have helped you. But you could have had a look in /tmp/OpenModelica/OMEdit/openmodelica.*.omc.output.OMEdit or anywhere in /tmp/OpenModelica/OMEdit

Bug reports go here: https://trac.openmodelica.org/OpenModelica/newticket. There is a segmentation fault in the model because it directly uses a constant data segment instead of copying it.

annotation(Library={"udaq","somethingusb"})

Keep in mind that the library also has to be compiled with mingw especially since it seems to use c++ stuff (it probably has to be the same gcc version as in the OpenModelica mingw).

Yes, you will need to create the .a-file and put it in the search path for the library.

annotation(Library="udaq")

Don't include anything (the C header is automatically generated by OpenModelica). Keep a library called libudaq.a libudaq.so udaq.lib (I guess, on Windows). Basically, something that "-L/path/to/lib/Resources/Library -ludaq" will find and link against.

Remove the ; after the class comment.

You probably didn't install the library:

$ apt-file find Modelica3D

omlib-modelicaservices-3.2.1-modelica3d: /usr/lib/omlibrary/ModelicaServices 3.2.1 modelica3d/Modelica3D/package.mo

There is no good way to use relative paths in Modelica. Instead, use a programmatic way to fetch the absolute path of your package. Instantiate the following model for example:

model MyPackage

  constant String mp = Modelica.Utilities.Files.loadResource("modelica://MyPackage");

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

end MyPackage;

Well, you have   Friction1.tau = 0;  Friction2.tau = 0; in the model, so I don't see what the problem is.

Allow connections from localhost to localhost?

Then you need to set the TMPDIR env.var because the tmp directory is not /tmp on OSX.

It should be /opt/openmodelica if anything (I'm unsure if the Java stuff includes workarounds to try and find omc anyway)

external Java support was deleted in like... 1.6 series. The manual is lying. But it's in a proprietary format, so I can't update it

Anyway, you could just write your own JNI wrapper. It's not that difficult.

I don't have access to any mac right now, but I am pretty sure the system version of lapack and blas are located under /usr/lib/liblapack.dylib... If you have installed broken lapack and blas, you will need to remedy it yourself
I have added a variant in the Portfile +openblas. That will compile a local lapack/blas for OpenModelica that should work better.

Did you install the XCode command/line tools and run xcode-select? lapack and blas are included in OSX

No, the default is modelica3d enabled. Why modify the configure script for -fPIC though? Just pass it through CFLAGS.

trayres wrote:

t if the user guide is built from a latex file, I could remove that portion and submit a patch for you if it is possible

I wish it was Stupid Word-document!

--without-omc just means it won't try to detect an already installed omc for bootstrapping. It will still compile omc.

You can install each of the dependencies except rml-mmc if you like:
apt-cache showsrc openmodelica | grep -i Build-Depends | tail -1

Then at ./configure, use bootstrapping:
./configure [...] --without-rml --without-omc

loadString("model A 

Integer aValue1(start=1); 

Integer aValue2(start=2); 

equation 

aValue1 = 2; 

aValue2 = aValue1 + 10; 

end A; 



model B 

Integer bValue1(start=1); 

Integer bValue2(start=2); 

A a; 

equation 

bValue1 = bValue2 + 1; 

a.aValue1 = bValue1; 

end B; 

");getErrorString();

simulate(A);

v:=val(aValue1,1.0 /* endTime */);

simulate(B, simflags = "-override bValue1=" + String(v));

plot(bValue1);

Or something like that

./ModelName -? gives a list of flags you can give the simulation executable. One of them is:

|                 | |       | | <-port=value> or <-port value>

|                 | |       | |   value specifies interactive simulation port

Just open a TCP port and listen. Try for example:

$ nc -l -p 12345

$ ./ModelName -p 12345

Return the progress as 1/10000 progress from startTime to stopTime (0.01% per unit)

The instructions use backticks: You should add the output of the command lsb_release -cs (in your case; precise).

Have you tried increasing the number of output points? The default is 500 points, and the plot utility doesn't know it is a sine wave so it may not look right even though it is.

Then don't use the +clang variant. It seems the macports version of clang passes -export_dynamic which the linker does not recognize.

Post the complete log-file of the last command (to a pastebin or something). The tail of the log is useless.

Create a ticket at https://trac.openmodelica.org/OpenModelica/newticket and someone will fix it. The code is valid and should work.

It used to be allowed, so OpenModelica automatically moves it to the end of the class:

[martin@mega tmp]$ omc +d=showStatement a.mos

Evaluating: loadString("model M annotation (); Real v; end M;")

true

Evaluating: list()

"model M

  Real v;

  annotation;

end M;



"

https://build.openmodelica.org/Documentation/ https://build.openmodelica.org/Document … ators.html

>>> loadString("model M Real r[2,3] = [1,2,3;4,5,6]; end M;")

true

>>> instantiateModel(M)

"class M

  Real r[1,1];

  Real r[1,2];

  Real r[1,3];

  Real r[2,1];

  Real r[2,2];

  Real r[2,3];

equation

  r = {{1.0, 2.0, 3.0}, {4.0, 5.0, 6.0}};

end M;

"

As you can see, it is also possible to nest the array constructor to create a matrix.

That is matrix syntax (2-dimensional). 1D-arrays use curly bracers:
Real r[3] ={1.1, 2.1, 3.1};

There is no InitType=3. Use Modelica.Blocks.Types.Init.InitialState or Modelica.Blocks.Types.InitPID.InitialState depending on if you use a PI or PID block.

Macports has lp_solve: port info lp_solve
lp_solve @5.5.2.0 (math)

And no, I do not have any OSX package more recent than December 2012.

You will not have much luck with the library using OpenModelica because it uses MSL 3.2 instead of 3.2.1. The two are slightly incompatible w.r.t. the Media interface (3.2 was broken and illegal which is why it was changed). Most notably, the library accesses through a partial package PartialMedium:

CoolProp2Modelica-library/CoolProp2Modelica/Test.mo:        ThermoStates=Modelica.Media.Interfaces.PartialMedium.Choices.IndependentVariables.ph);

I installed it quite simply:
git clone https://github.com/thermocycle/CoolProp … ca-library ~/dev/
ln -s ~/dev/CoolProp2Modelica-library/CoolProp2Modelica ~/.openmodelica/libraries

But as I said, it probably won't work (you also need to install the coolprop libraries after that, into ~/dev/CoolProp2Modelica-library/CoolProp2Modelica/Resources/Library if I remember correctly. But that comes after someone converts the library to MSL 3.2.1.

You are doing this configure in what revision of OpenModelica sources?

It is possible to compile without RML if you want to keep your sanity...

./configure --without-rml ...

It should be working again, update and upgrade, (the 7053 package was built twice by accident; if that happens apt-ftparchive does not regenerate the checksum).

runScript() works the same as running the commands in your mos-script one by one. So you could try seeing where the error occurs. I recommend putting getErrorString() after any command.

I do not know how Dymola sets parameters before running a simulation, but in OpenModelica you can use:

simulate(model_name, simflags = "-overrideFile=fileName")

Where fileName is a file:

variable=startValue

someOtherVariable=someOtherStartValue

Well, you do have to write such an input method yourself. You could probably see https://build.openmodelica.org/Document … ables.html for some ideas on how you could get a value from a file. Though as far as I know that is more used for reading data of a continuous signal.

You can define parameter input by reading a file during initalization:

parameter Real p = readFromInputFile("abc.txt", 13);

The difference between parameters and constants is that you can declare initial equations for parameters but not constants. Some Modelica tools (OpenModelica included) also allow you to compile a model and tune (certain) parameters before a simulation run. I prefer using constants.

Yes, you need to run Linux in order to handle large models. GCC on Windows cannot allocate more than 4GB of memory even if you have more memory installed.
You could also try to set the CFLAGS to -O0 or possibly, if you are not already using the latest nightly build try it (https://trac.openmodelica.org/OpenModel … eset/17653 has some changes that reduce memory consumption).

Flattening: https://test.openmodelica.org/hudson/jo … estReport/
Compilation: https://test.openmodelica.org/hudson/jo … estReport/
Simulation: https://test.openmodelica.org/hudson/jo … estReport/

And temporary location for the report (I might move it into hudson): https://test.openmodelica.org/libraries … rsive.html

I packaged powersystems for Linux and once modelica.org comes online again, I guess windows nightlies will also include them:
http://build.openmodelica.org/apt/pool/ … -1_all.deb
http://build.openmodelica.org/apt/pool/ … -1_all.deb

I can add it to the list of libraries to test (it's not the the modelica-3rdparty repository that I usually check for free libraries; it is even in the modelica association github repository!).

min and max are basically shortcuts for writing

assert(x <= maxValue, "...");

assert(x >= minValue, "...");

Start values are more complicated. I suggest reading some literature. Sometimes it is used as a guess value for the initial solver. And sometimes it is used as an initial equation (fixed=false vs. fixed=true).

The following is a nonsense start-value which is also ignored because it is not used to calculate the start-value of a state or initial value. x is always 25

Real x(start = 15) = 25;

apt-get install libdbus-1-dev maybe? Tell me if that helps and I will add it to the dependencies

You should not load the internal models! (They are only for MSL 3.1) No need to load the packages again either.

loadModelica3D();getErrorString();

loadString("model DoublePendulum

  extends Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum;

  inner ModelicaServices.Modelica3D.Controller m3d_control;

end DoublePendulum;");getErrorString();

simulate(DoublePendulum);

That's all.

I see more (Windows) engineers use OMShell while Linux users use omc command-line more often.

Using the command runScript("myMOS.mos") works fine from OMShell anyway.

Adeel: Why not use "loadModelica3D()" for the MSL 3.2.1 version (which is much simpler than 3.1)

As far as I know, this is not possible. It is not referenced in the source code. Sundials is used, but for the radau and lobatto solvers.

Please use the issue tracking system to submit bug reports and patches. Attachments work fine there: https://trac.openmodelica.org/OpenModelica/newticket

Could you create a ticket at https://trac.openmodelica.org/OpenModelica/newticket and attach the model? I cannot reproduce this on my mac machine. So it is either dependent on OS version, CPU architecture, or on the linker (maybe my model didn't need to link against the LAPACK stuff).

Which version of OSX are you using?

Maybe fedora includes a version of LAPACK that does not work the same way as the one we use?

liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f243913e000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f2438e9d000)

Make sure you don't have local changes; do make clean or svn-clean. Hudson says that revision works just fine: https://test.openmodelica.org/hudson/jo … UILD/4962/

https://build.openmodelica.org/Document … tions.html or https://build.openmodelica.org/Document … Flags.html

You can do this without using FMU and without recompling the executable (parameter sweeps).
Simply use the buildModel command to create the executable, and then modify the command-line switches sent to the executable or modify the xml-file.

Yes. Scripting is like a mos-script. You can also use popen and read/write using stdin and stdout though. Or named pipes, etc.

FMI is different from the OMC API. You can use it to control a simulation, but that's about it.

For scripting with omc: https://build.openmodelica.org/Document … pting.html

There is no other API as of yet (assuming you consider the CORBA interface the same as mos-scripting)

You would need to post the full log-file because it is a parallel build. The error is probably in the middle somewhere. Also, you should probably try openmodelica-devel since there were some problems with OSX builds earlier on.

Sure. You have a few choices:
* Use OMShell instead of OMEdit (OMEdit does not support MSL 2.2)
* Convert SystemDynamics to MSL 3.x
* Try an unofficial version of SystemDynamics already converted to MSL 3: http://blog.wolfram.com/data/uploads/20 … cs-2.1.zip

https://trac.openmodelica.org/OpenModelica/newticket is better for bug reports since the upload system works better

Use:
loadFile("C:/Program Files/Wolfram Research/SystemModeler 3.0.2/Libraries/BioChem 1.1/package.mo");

Some of the commercial libraries use copy protection (encryption). And only tools with the secret keys can decrypt them. OpenModelica cannot open these libraries.

There is no real difference between Modelica files and libraries except loading resources through modelica:// URIs.

If you use loadFile("path/to/library/package.mo") it will load the full library. Or just put the library in ~/.openmodelica/libraries (or even a symlink), and use loadModel.

Yes, the Dymola ones may contain syntax errors (so they won't load in OpenModelica), or illegal code (you wrote something that is not strictly speaking Modelica, but Dymola thought it was close enough). Otherwise, they work fine together.

In the OpenModelica system documentation (pdf shipped with OpenModelica). Chapter 6: Interactive Simulation Facilities
The interface is a bit of a mess due to abusing software design patterns

Yes. You have to connect to the interactive simulation manually. For example using telnet

See https://trac.openmodelica.org/OpenModelica/ticket/2131

So write that C/C++ library. I promise you it will work better than the interactive interface to simulations in omc. (I have been told it is working as designed at the moment; that it works as designed is a problem however)

The part inside you have guarded with an expression in an external function that you made sure would only return true once.
The algorithm section will be called every time-step, but the part inside only once.

FMI can do what you want.

The single variable named tau. Anyway, it's a regular expression so you can use things like ".*"

Pretty much, yes

Still didn't say the OS. Some versions are not linked against sundials because it's not available for the platform.

radau1 is roughly implicit euler. Which version of OpenModelica (OS, revision) are you running?

I would probably use something like sum(a[1,i] for i in size(a,2)) or similar.

No, those solvers always choose when and how they iterate. It is merely the points you ask to get an output point in the result file (it will usually be interpolated or extrapolated).

Guard it with external C code. Give it a unique identifier so you can guard multiple sections.

if once(13) then

 ...

end if;

The Dymola demo version usually works for converting old libraries. They will then have the new annotations but still using some old language constructs that have since been forbidden.

The standard library (MultiBody and World object) uses inner and outer components for the purpose of globally accessible variables.

Then make a detailed bug report and maybe it will become part of the next release: https://trac.openmodelica.org/OpenModelica/newticket

Try primitivesVisible:

model A

  extends B annotation(

    IconMap(extent={{-100,-100}, {100,100}},primitivesVisible=false),

    DiagramMap(extent={{-50,-50}, {0,0}},primitivesVisible=true)

  );

end A;

Try getInstanceName():
https://build.openmodelica.org/Document … eName.html

simulate(ModelName, startTime = 0, stopTime = 3, numberOfIntervals=1000);

If a fixed-step solver is used, the number of intervals will be used. For variable-step solvers, it is a recommendation for output points.

You can choose output variables using regex.

Either use for example:

simulate(ModelName,variableFilter="^torque.tau|torque.useSupport$");

Or use the output tab to select output variables in OMEdit.

http://www.mail-archive.com/openmodelic … 01133.html
https://openmodelica.org/index.php/forum/topic?id=434

I don't know any such open code. Most of them use euler.

If you want all the nice stuff in OpenModelica, don't use FMI Or wait a few (months? years?) before FMI for co-simulation is added and is stable.

It wasn't that hard to find solvers from the page I linked

For example this one: https://github.com/mtiller/fmusdk/blob/ … m/fmusim.c

Try https://www.fmi-standard.org/downloads

Maybe try?

model M extends Modelica...Examples.XXX; end M;

You cannot do this from OMEdit. You can however use OMShell, OMShell-terminal, OMNotebook, or .mos-scripting to plot the result once the simulation finishes.

The OSMC-PL runtime license has the option to use OSMC-GPL or OSMC-BSD. (This is only applicable if you link our runtime code with the generated code.)

And to link the 3-clause BSD: http://www.opensource.org/licenses/BSD-3-Clause

Pretty much. If it's linked to the runtime, you have BSD 3-clause and OSMC-PL Runtime license to consider, so:
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
(Include a copy of BSD 3-clause)

And for OSMC-PL you should:
* A recipient must clearly indicate its chosen usage mode of OSMC-PL, in accompanying documentation and in a text file OSMC-USAGE-MODE.txt, provided with the distribution.

So just include a text saying you use the OSMC-PL BSD 3-clause mode and a copy of the license (for distribution). As well as the copyright notices from the MSL and you should have covered all your bases. Not that I think anyone will mind anyway.

But yes, it can be linked to proprietary code and you may ship it with any license (shareware, commercial, free there should be no problem).

That depends on the Modelica tool used and the licenses of the libraries that the model uses.
OpenModelica has a BSD-license option for the simulation runtime, which imposes no real restrictions (just attribution in documentation if you link to the runtime).

The following is from the OSMC bylaws, which clarifies our position. https://openmodelica.org/images/docs/op … -final.pdf, §1.5:
The ownership, copyright, and possible usage license of source code translated by the OpenModelica Compiler into translated code also holds for the translated code originating from that corresponding source code. [This is a consequence of translated code being considered derivative work of the input source code, and that OpenModelica does not impose additional restrictions on generated code in addition to what holds for the input source code.]

What OS is this? Your lib hd5 is too old. Easiest is uninstall or upgrade.

I will comment EnergyStorages very shortly. There is a good reason why MA did not add this library to the 3.2.1 release. It was planned to at one time, but some people, myself included, complained it was not considered mature enough (MSL 3.2.1 is focused on being written according to the language specification and introducing EnergyStorages would mean fixing even more code, etc).
This was the last version of the development branch that featured the package: https://test.openmodelica.org/~marsj/MS … 2-03.html. It will probably be improved and part of the MSL release following 3.2.1.

Upgrading to OpenModelica 1.9.0 should remove the error-message. It's an old bug, known, and fixed.

You want "if noEvent(fraction <= 1) then" since otherwise the if-equation will switch equation at a time that slightly differs from the exact zero-crossing.
I would probably have written it as "b = if noEvent(fraction <= 1) then 1 else -1;". Sign is defined as “noEvent(if v>0 then 1 else if v<0
then –1 else 0)”.

Read the documentation. It lists the steps needed to start the visualizer.

I would use the nightly or stable builds (r15900-ish) with the omlib-modelicaservices-3.2.1-modelica3d package. It probably also works in the old version you are using with package omlibrary-modelica3d.

Follow the steps in https://build.openmodelica.org/Document … ica3D.html and you should be fine (if you use OMEdit, simply add ModelicaServices of version "3.2.1 modelica3d" to the list of libraries to load on startup.

It is a Modelica 1.x library if it does not contain the appropriate within-clauses at the top of every Modelica file. You need to use +std=1.x to load it. But since OMEdit can only handle Modelica3-style annotations you will not see the icons or diagrams if you do.

But there must be more problems with the library - it is in such a bad shape I put it on my github-ignore list. Probably has mo-files that do not match the classname inside the file.

The github issue tracker has also been disabled for, but if you convince webmaster at modelica.org to open a development branch I could probably make the necessary changes to make the library parse.

OK. Subscribe to the follow bug report https://trac.openmodelica.org/OpenModelica/ticket/2145. I think it's related and possibly a reason why wheezy was not released yet. Although more likely is OMEdit does something bad (it often does).

Ok, wheezy is up. Of course there were problems

I have a wheezy repository in the pipeline. Let's say 4 or 5 hours from now you will be able to use wheezy nightly if everything works out fine. Hopefully that will solve it. Else, "raring" (2013) or "quantal" (2012) probably work better than squeeze (2011). I would really like for wheezy to be released soon so I can stop supporting squeeze.

Are you sure that's the repository your packages are coming from? It's discontinued and to me it looks rather empty: http://build.openmodelica.org/apt/dists … 6/Packages (some other packages are left)

Are you using deb-src or some other repo?

apt-cache show omc | grep ^Filename:

Right-click the component, choose Flip ...

apt-get remove omlibrary-msl222. There is a breaks property missing for msl222. You can also probably apt-get update and try again as I updated the package.

The problem with that is the version of ParadisEO that we use cannot be compiled with more recent GCC versions (also GCC 4.7 is almost twice as slow as GCC 4.4). But yes, sometime in the future we need to change compiler (gogo LLVM).

I know nothing about WSM other than they use an older OpenModelica frontend. The backend and executables files are different, so you can probably not use them together with OpenModelica.

What crashes? OMShell or the simulation executable. If it's the executable, you found a bug somewhere and a bug report is in order (preferably with the model provided). You could also run it through gdb to find out where it crashes, but since you are using Windows, I will just assume that is too much to ask

Works fine for me. It is probably an omc session shared with OMNotebook (which overrides some plotting functionality).

If you call the buildModel() command, it returns the path of the executable. If you run Linux, you can run that without changing any environment variables.
For a model M, there is also a file M_input.xml which is read before initialisation. You can write a GUI that read the parameters from that file, allows users to make changes, and then sends an override file on the command-line when calling the executable.

Yes that should mean it finished successfully. You can check if $? is 0, then it is a success and epc4_res.mat is created. If then OMEdit starts spinning it is an OMEdit bug. I believe in the latest versions of OMEdit it is possible to open result files.
Try File->Open Result File and see if OMEdit locks up with just the result-file. It would then be good if you could then open a ticket using https://trac.openmodelica.org/OpenModelica/newticket and attach the result-file so the OMEdit maintainer can have a look at it.  It would also be good if the model could be provided if it is not confidential. If you do not want the files public, you can also email the files to adeel <dot> asghar <at> liu <dot> se.

OMEdit does not do any actual compilation work though. It's all sent to omc. If ps,top, or htop reports 47 minutes of CPU-time for OMEdit, you probably found a nasty error in OMEdit (but check if it's not omc or gcc taking time to be sure).
In that case I would have liked to see if the model works from command-line (omc a.mos).
a.mos:

loadModel(Modelica);getErrorString();

// more libraries maybe?

loadFile("myModel.mo");getErrorString();

translateModel(MyModelName);getErrorString();

This produces MyModelName.makefile. If this works, omc is fine. If make -f MyModelName.makefile spins, it's gcc at fault.

Also check if compilation actually worked, but the simulation is spinning (will be named something like Path.To.MyModelName).

So compilation takes that long? Which process is running after that time, omc or gcc?

You need to use +target=msvc. It needs to create a different set of makefiles.
See also https://openmodelica.org/index.php/foru … =892#p3340

Actually, looking at the configure script again, it only looks for the headers but does not verify that the libraries can be linked.
You can configure --without-ipopt to avoid using the library.

I believe the only way to get OpenModelica to try to link against this library is if the configure script actually detects it is available.
What was the output of ./configure (./config.status -recheck to run it again).

Mine says: Simulations may use IPOPT: No, which means it will not try to link against it (ipopt is not used by the default solvers). I believe probably recent libipopt do not use libcoinmumps any longer but the configure script has not been updated.

Or using getCFlags() + setCompilerFlags(... + "-O0") API (don't ask me why they are different...)

OK, but running Windows so limited to 3GB per process. I would recommend Linux and clang You can also change to MSVC using OpenModelica, but it uses up more memory than GCC.

How much RAM does your computer have?

If you used "apt-get -b source openmodelica", it is as easy as running update and the command again.
If you are using the binary packages, 15755 was built yesterday and is available for installation (so apt-get update && apt-get upgrade will update it).

r15754 should work better as I introduced a bug for the nonlinear system solver in 15753

I made the change in r15753. If it does not work I will get an email from hudson complaining and I will update the status here.

I think we can easily move the f2c.h includes to the c-files instead of the headers... They are remnants of when the headers were filled with f2c-specific calls.

Hmmm... There is a +target=msvc flag in OpenModelica. But I do not know what it will do since I use Linux
I'm guessing you need to compile the simulation runtime with msvc (the cmake targets). I have never tried that myself. I'll write an email to the developers mailing list and see if someone knows more.

Library={"lib1","lib2","lib3"} can be used to add the dependencies (CORBA libs in this case).

You can use https://build.openmodelica.org/Document … Flags.html to add CFLAGS to the compiler as well. It might be possible to compiler the model through netbeans as well. Just add the code and try, but be warned the runtime libraries are linked against the mingw libc. Mixing the two does not always work.

Dassl is an implicit, variable-step solver that can handle stiff systems. Most Modelica tools use some variation of dassl as the default solver.

It might be that the code would run if you ./configure [...] CFLAGS="-O2" since then some SSE instructions might be skipped (my CPU is an Intel Atom D525).

You could see if the code I generated works for you: http://dev.openmodelica.org/~marsj/DP.tar.xz

tar xJf DP.tar.xz

make -f Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum.makefile

./Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum

Changing the compiler used to compile omc may also help. /configure [...] CC=clang CXX=clang++ compiles code much faster than gcc.

After changing CFLAGS, it is enough to "make -C SimulationRuntime/c/ clean". If you change CC and CXX a full make clean is safer.

What command did you use to count the number of equations in OpenModelica? If you used checkModel(), note that the count is way off since it does not handle array-equations correctly.

I think I reproduced the system perfectly (compare my settings), but I cannot reproduce the error-message (I tried Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum). Did you use some other model or does this one also fail?

record OpenModelica.Scripting.CheckSettingsResult

    OPENMODELICAHOME = "/usr/local/",

    OPENMODELICALIBRARY = "/usr/local//lib/omlibrary:/home/xbmc/.openmodelica/libraries/",

    OMC_PATH = "/usr/local//bin/omc",

    SYSTEM_PATH = "/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl",

    OMDEV_PATH = "",

    OMC_FOUND = true,

    MODELICAUSERCFLAGS = "",

    WORKING_DIRECTORY = "/home/xbmc/OpenModelica",

    CREATE_FILE_WORKS = true,

    REMOVE_FILE_WORKS = true,

    OS = "linux",

    SYSTEM_INFO = "Linux htpc 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux

",

    RTLIBS = "  -lrt -lgc -fopenmp -llapack  -lpthread",

    C_COMPILER = "gcc",

    C_COMPILER_VERSION = "Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC) 

",

    C_COMPILER_RESPONDING = true,

    HAVE_CORBA = true,

    CONFIGURE_CMDLINE = "Configured 2013-03-29 21:14:35 using arguments: '--with-omniORB --without-paradiseo --disable-modelica3d'"

end OpenModelica.Scripting.CheckSettingsResult;

Since you had to use --without-paradiseo it means you are using some C-compiler that follows published standards (probably gcc 4.7 or 4.8).
I would need to see the output of checkSettings() to try to reproduce the error though.

Also, based on the comments in https://trac.modelica.org/Modelica/tick … #comment:1 this will possibly be the default behaviour in the to-be released version of MSL 3.2.1 (we ship a development version).

No, I opened nano and edited the system library.

I found what is causing it...
Change M_Transformer to

equation

  for s in 1:N loop

     for z in 1:N loop

       Lm[z,s] = if (z>=s) then L[(s-1)*N+z-div((s-1)*s,2)] else Lm[s,z];

     end for;

  end for;

Instead of algorithm, and it works... I'll submit a bug-report to modelica.org since there is no good reason to keep it an algorithm.

simulate(transmission_Line);getErrorString(); returns:

record SimulationResult

    resultFile = "",

    simulationOptions = "startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 0.000001, method = 'dassl', fileNamePrefix = 'transmission_Line', storeInTemp = false, noClean = false, options = '', outputFormat = 'mat', variableFilter = '.*', measureTime = false, cflags = '', simflags = ''",

    messages = "Simulation failed for model: transmission_Line

Error: Internal error Inverse Algorithm needs to be solved for {m_oline1.s[1].inductance.Lm[1,2],m_oline1.s[1].inductance.Lm[3,2],m_oline1.s[1].inductance.Lm[4,1],m_oline1.s[1].inductance.Lm[3,1],m_oline1.s[1].inductance.Lm[3,4],m_oline1.s[1].inductance.Lm[2,1],m_oline1.s[1].inductance.Lm[4,2],m_oline1.s[1].inductance.Lm[2,2],m_oline1.s[1].inductance.Lm[2,4],m_oline1.s[1].inductance.Lm[3,3],m_oline1.s[1].inductance.Lm[1,1],m_oline1.s[1].inductance.Lm[4,3],m_oline1.s[1].inductance.Lm[1,3],m_oline1.s[1].inductance.Lm[1,4],m_oline1.s[1].inductance.Lm[4,4],m_oline1.s[1].inductance.Lm[2,3]} in   for s in 1:4 loop

    for z in 1:4 loop

      m_oline1.s.inductance.Lm[1, z, s] := if z >= s then m_oline1.s[1].inductance.L[4 * s - 4 + z - div((-1 + s) * s, 2)] else m_oline1.s[1].inductance.Lm[s, z];

    end for;

  end for;

. This has not been implemented yet.



Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createSingleAlgorithmCode failed!

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component Algorithm 340 {1140, 1132, 1129, 1133, 1130, 1137, 1128, 1136, 1134, 1131, 1141, 1127, 1139, 1138, 1126, 1135}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component Algorithm 340 {1140, 1132, 1129, 1133, 1130, 1137, 1128, 1136, 1134, 1131, 1141, 1127, 1139, 1138, 1126, 1135}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {345:1150}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {345:1150}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {346:1151}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {346:1151}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {347:1152}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {347:1152}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {348:1153}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {348:1153}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {349:1154}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {349:1154}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {350:1155}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {350:1155}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {352:1156}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {352:1156}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {353:1157}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {353:1157}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {351:1158}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {351:1158}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {354:1159}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {354:1159}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {355:1160}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {355:1160}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {357:1161}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {357:1161}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {358:1162}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {358:1162}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createOdeSystem failed for component {356:1163}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed for component {356:1163}

Error: Internal error ./Compiler/BackEnd/SimCodeUtil.mo: function createEquationsForSystem1 failed

...

You're posting the wrong error-messages. The ones at the top are usually more relevant:

    messages = "Simulation failed for model: Modelica.Electrical.Analog.Lines.M_OLine

Error: Internal error Inverse Algorithm needs to be solved for {s[1].inductance.Lm[2,1],s[1].inductance.Lm[4,4],s[1].inductance.Lm[4,1],s[1].inductance.Lm[2,2],s[1].inductance.Lm[2,3],s[1].inductance.Lm[2,4],s[1].inductance.Lm[3,1],s[1].inductance.Lm[3,2],s[1].inductance.Lm[1,3],s[1].inductance.Lm[3,3],s[1].inductance.Lm[3,4],s[1].inductance.Lm[1,1],s[1].inductance.Lm[1,4],s[1].inductance.Lm[4,2],s[1].inductance.Lm[1,2],s[1].inductance.Lm[4,3]} in   for s in 1:4 loop

    for z in 1:4 loop

      s.inductance.Lm[1, z, s] := if z >= s then s[1].inductance.L[4 * s - 4 + z - div((-1 + s) * s, 2)] else s[1].inductance.Lm[s, z];

    end for;

  end for;

. This has not been implemented yet.

semiLinear()

Write it to a text-file during simulation or read the result-file after OMEdit simulates a model. You could even write your own external C code to read the result-file during initialization.

OMEdit has no way of doing this. Sorry.

That would work on some installations on Linux, but not any on OSX.

This is how OMEdit does it: https://openmodelica.org/svn/OpenModeli … CProxy.cpp

But it gets the configured installation path and can guess where omc is.

Best way would be to rewrite it to look for
OMHOME/bin/omc[.exe]
DEFAULTHOME/bin/omc[.exe]

And if neither file exists... Just call omc.

Changing getBinaryPaths to return only 1 string... Either an absolute path or "omc", then use that.

OPENMODELICAHOME does change more things if it is set when omc is called. In that case we use either OPENMODELICAHOME or the hard-coded path omc thinks it is installed in to find libraries and headers, etc.

Eclipse clears the environment so you might need to set it there as well. Or write a small patch for the jar-files to also search the PATH for omc. That way you will never need to set OPENMODELICAHOME.

A record with only parameters is fine. Mixing parameters and variables in the same record is begging for trouble.

OPENMODELICALIBRARY=/usr/lib/omlibrary should work. But as far as I remember, SimForge is only for Modelica 2.2

You need to check it during runtime since the result format only supports doubles.

It's a bug in both omc and dymola. You cannot call max on a scalar. Please add a bug report to trac.openmodelica.org

You can look at https://test.openmodelica.org/~marsj/MS … rsive.html to see which examples in the standard library are marked yellow. They require the flag in order to compile a simulation executable.

It's a workaround until OpenModelica can properly handle redeclares. As far as I know, the flag renames some of the redeclared classes in order to make them unique.

That's only a rule for statements. For equations it is different... And I guess to make the grammar simpler those checks are not done.

And regardless, tuples "( ... )" are only allowed for function call results. A Modelica tool will not let it go unnoticed (except maybe during parsing; but that's a non-issue as most languages allow you to use syntax that is not really allowed later on).

I looked at the system (use +simCodeTarget=Dump or +d=dumpindxdae), and found one non-linear block of equations:
Nonlinear System (index 25)
Solves for variables (2 variables, 0 equations): bar3.theta, bar2.theta

So I assumed these were the variables you were having problem with. They are solved implicitly, which means a non-linear solver doesn't know that you expect values in the range 0..2pi.

bar2.b.Coordinate[1] = bar1.b.Coordinate[1] + bar2.l * cos(bar2.theta)

bar2.b.Coordinate[2] = bar1.b.Coordinate[2] + bar2.l * sin(bar2.theta)

0.0 = ground1.l + (-bar3.l) * cos(bar3.theta) - bar2.b.Coordinate[1]

0.0 = bar2.b.Coordinate[2] + bar3.l * sin(bar3.theta)

In fact, there are very many values that solve the system (and yes, 4 equations for 2 variables solved is weird, but it's a torn non-linear system).

There are ways in which you could get the value you want.

Try (in model Bar):

      SI.Angle theta(min = 0, max = 2*Modelica.Constants.pi) "Angle with the +ve X axis"; 

And use a non-linear solver that accepts boundary conditions:

loadModel(Modelica);getErrorString();

loadFile("a.mo");

simulate(Test,simflags="-nls=kinsol");

plot(bar3.theta);

Did you use +d=scodeInstShortcut? That flag is required for most Fluid models.

Yes, you may pass arrays, like Section 12.9.1.2 Arrays says.

As an example, see:
https://openmodelica.org/svn/OpenModeli … /Matrix.mo
It uses the default mapping:
https://openmodelica.org/svn/OpenModeli … ons/Func.h
(inArr,inArrSizeDim1,inArrSizeDim2,outArr,outArrSizeDim1,outArrSizeDim2)

If you pass an output array without using the default mapping, note that you are recommended to pass the sizes of all dimensions explicitly (and that in C, the output array must be passed as an input to the function). No allocation may be done by the user program; OpenModelica must do this for you.

Note that the only error of OpenModelica is that it did not tell you your code was illegal.

See Modelica Spec 3.3, section 12.9.1.3 Records:
"Arrays cannot be mapped"

You are subscripting a scalar. Use clock1.y instead of clock1.y[1].

I cleared the apt-ftparchive cache and now it seems to work again.

OK, I started up a virtual machine (had a 32-bit squeeze here at home). And yes, it seems to complain about a hash mismatch. I'll see what I can do.

No, it's for 32 and 64-bit. And I tested it on 64-bit. Although I use Ubuntu myself, I tested the squeeze target...

Try sudo apt-get update again and then try to install it. I just checked squeeze/stable and it installed fine.

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

Please consider creating tickets for bug reports instead of forum posts: https://trac.openmodelica.org/OpenModelica/newticket. Most of our developers don't read the forums.

If you want to subscribe to the ticket, CC yourself on https://trac.openmodelica.org/OpenModelica/ticket/2078