No, that's not true. The FMU for model exchange is just an interface which includes no solver. So no amount of work on the OpenModelica side will allow you to change the solver. It's rewriting the FMI Validator to include dassl that you need.

import Modelica.Mechanics.Translational.Interfaces; doesn't work?

Note: In OpenModelica, checkModel on a package does very little (it basically checks that any constants defined are OK; it does not check inherited classes as they are unused):

>>> instantiateModel(Modelica.SIunits)

"class Modelica.SIunits

end Modelica.SIunits;

"

Did you import SIunits in NewMass?

Yes, by writing your own FMU simulator.

Because the base type is not replaceable and you didn't redeclare any base classes.

All libraries are packages but not all packages are libraries. But yes, basically the same thing (just how you load them is different).

You can use something like:

import Modelica.Mechanics.Translational.Interfaces;

Interfaces.XXX xxx;

And keep using the standard interfaces. And the standard components, and so on. You only need to redefine them if you want a different kind of connector.

You shouldn't try to add components to the standard library. You need to create your own library to insert classes into.

You'll have to ask the makers of the CPP Codegen module. That field is not for general use and is probably wrong. Why they didn't just put the list<DAE.Dimension> in there, instead using String, I also do not know...

Create a new model, drag your components onto the diagram, and connect them together. I am assuming you added connectors to your components already.

The reason the executable is so much larger is that in omc, the executable includes all possible solvers, and so on. In FMI for model exchange it is the tool that imports the FMU (in your case, the compliance checker) that does the numerical integration. I believe the compliance checker only uses euler, so this might be your problem.

It generated no such file as intermediate output. The generated C-code is essentially the optimized file. You can however look into the file ModelName_info.xml that is generated in more recent OpenModelica versions.

What revision and OS of OpenModelica are you using? Everything runs fine for me on 64-bit Linux. Even valgrind doesn't complain.

https://openmodelica.org/svn/OpenModeli … -MINGW.txt

We ship a full MinGW environment + dependencies in order to compile OpenModelica. It possibly works with MinGW 4.7, but I believe it is a whole lot to change for not much gain (gcc 4.7 is much slower than gcc 4.4).

Open the file and re-save it to UTF-8 encoding. Or use loadFile("PNlib.mo",encoding="Windows-1252")

Even if you managed to load it, OMEdit still wouldn't handle the Modelica 1.x annotations in there. Use ModelicaAdditions from the scripting enviornment (command-line or OMShell). Note that most parts of the library (like MultiBody) are part of MSL 3.x already. And that the PetriNet library has been improved since the ModelicaAdditions release.

See: https://modelica.org/events/modelica201 … elibs.html for PNLib

I would not be able to tell the reason without seeing the full model (and even then it would possibly be a guess). You could try the measureTime=true flag to get a little report. Quite possibly tearing works on a nonlinear system only if area is non-zero.

BondLib is a Modelica2 library. OMEdit only supports Modelica3 graphical annotations, so you need to convert the library using some tool that knows how to convert between the two formats (and also how to convert the models from using MSL 2.2.1 components to Modelica 3.x).

I created a bug report at https://trac.openmodelica.org/OpenModelica/ticket/2045

Yes, but the backend worked fine anyway and gave the correct message "Warning: No system for the symbolic initialization was generated. A method using numerical algorithms will be used instead.".

The real puzzler is why the external object constructor wasn't called before the object was used during initialization.

You want to use x := pre(x) + 1;

But that wll only increase the value by one at each discrete time step. I believe there is no way to increase x by one at each continuous step.

I guess you should contact the author again because the library has some errors in it (see https://trac.openmodelica.org/OpenModel … #comment:1 for details)

OMEdit can do that, and so can you. Use the -port=X option of the simulation executable (seems to have been broken for beta3 but should work in beta4 again).
To test it in Linux, launch nc and the simulation in two different terminals

$ nc -l 10356

$ ./M -port=10356

While it actually doesn't print the simulation time, it print the progress as an integer 0-10000 (0.00-100.00%).

Open up a socket and send a message. Use when sample() to do it periodically. Use a UDP socket if you don't care about lost messages. What information do you need the main program to get?

Yeah, you will need to write your own code in external C functions. Depending on what you want, you either sample the system at certain intervals and exchange information. Or you have something that calculates the value in every time step.

inValue = getFromOrocos(...);
outValue = f(inValue, ...); // 1 or more equations
sendToOrocos(outValue, ...);

For an example of external objects, see:
https://openmodelica.org/svn/OpenModeli … /ExtObj.mo

To force -lwsock32 to be compiled, add Library={"wsock32"}

The simulation model is by default compiled using gcc in Windows. Use +target=msvc if you need to use visual studio (I never tested this myself).

External objects have a constructor function that is only called once in a simulation. when initial() may be called multiple times but is commonly used to call functions at the start of the simulation.

You can stop the simulation by calling terminate() (which I hope is again working in OpenModelica; you can also use assert(false) or #include "ModelicaUtilities.h" and call any of the ModelicaError() family of functions if you would rather stop the simulation in external C code).

The Modelica language has no way of changing the step size while the simulation is running, so any such feature would have to be tool-dependent. And as far as I can tell the control structure is not a global value in OpenModelica so it would be hard to access it without stack inspection or re-writing the runtime.

Write an example session of what you would like to do. To me it's not clear if you want to communicate with a running OpenModelica simulation or simply set some values and start a simulation.

What OS are you running? And what is the output of checkSettings()?

The library is filled with stuff like "Modelica_DeviceDrivers/Blocks/Examples/testInputJoystick.mo:2:1-13:22:writable] Error: Expected the package to have name testInputJoystick, but got TestInputJoystick.".  Makes it a bit annoying to try to load a library when it is malformed.

I was able to flatten Modelica_DeviceDrivers.Blocks.Examples.TestInputKeyboardKey; which model did you have a problem with? (Also, note that you might want to use +showErrorMessages while using +d=failtrace from command-line).

Many people have, but I do not have any example code except this. I would recommend writing your own code since that example is based on a very old OpenModelica and it lacks the C-code anyway.

Use external objects or external C and use the simulation itself as the master using a fixed-step solver. Communicate using when sample(...) and the external object. In the external C code you write, synchronize the time (to real-time) and do the communication (with the hardware). I believe this is a lot less work than writing your own FMI master.

That sounds about right from my limited knowledge of FMI. Note that you probably also need to read the xml-file to get the index of a variable, and so on.

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

translateModelFMU(ModelName)

Could you confirm if the directory build/bin/ exists? It should have been created by the mkbuilddirs target that omc-diff depends on. ls testsuite/difftool could also be useful

I would need to see the gdb backtrace to figure out the chain of calls. All I can tell from this is that a f2c-translated function failed.

As far as I know, you are not guaranteed any upper bound on how many times an initial equation is called in Modelica.

Change overridefile to overrideFile, stopeTime to stopTime, I think

A few spontaneous comments:
objectType = objectrecord.objectType.plane should be rejected (objectType is not replaceable and you did not use redeclare). Should probably add a field in the record that you modify.

Also, OpenModelica cannot handle records that contain arrays (I believe this is true for the whole runtime). But that's ok because the Modelica specification does not allow you to pass records in external C declarations anyway See https://trac.modelica.org/Modelica/ticket/351

Something like:

loadFile("a.mo"); // experiment 1 & 2 

res := simulate(M); // experiment 1 

writeFile("N.override","");

stopTime := 1.0;

y1 := val(y[1], stopTime);

y2 := val(y[2], stopTime);

writeFile("N.override","y[1]=" + String(y1) + "\n",append=true);

writeFile("N.override","y[2]=" + String(y2) + "\n",append=true);

getErrorString();

readFile("N.override");

simulate(N, simflags = "-overrideFile N.override"); // experiment 2, read the parameter value at the start of the simulation 

val(z[1], 0.5); // verify that it worked

There does not seem to be a better way to script it

Oh, and to add my output from running that code:

$ omc a.mos

/home/marsj/trunk/build/bin/omc 1.9.0 Beta2 (r14687)

true

record SimulationResult

    resultFile = "/home/marsj/tmp/M_res.mat",

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

    messages = "",

    timeFrontend = 0.052824347,

    timeBackend = 0.18675881800000002,

    timeSimCode = 0.05071623099999989,

    timeTemplates = 0.130822174,

    timeCompile = 2.005965308,

    timeSimulation = 0.01198327,

    timeTotal = 2.439157141

end SimulationResult;

2.0

record SimulationResult

    resultFile = "/home/marsj/tmp/N_res.mat",

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

    messages = "",

    timeFrontend = 0.039377649,

    timeBackend = 0.018874146,

    timeSimCode = 0.011657719,

    timeTemplates = 0.018043621000000003,

    timeCompile = 0.265671996,

    timeSimulation = 0.010105428000000001,

    timeTotal = 0.36379121200000003

end SimulationResult;

0.9092974268256817

The loadString is just a way of loading a string value instead of a file in a mos-script. I realized another way of doing it that possibly suits you better.

Run as omc a.mos. The disadvantage to the approach above is that here the value is a parameter (which means fewer optimizations are possible). The advantage is that you can write the models as usual and only script the override. (Can also be done using -overrideFile if you have many parameters to set)

a.mos:

loadFile("a.mo"); // experiment 1 & 2

simulate(M); // experiment 1

y := val(y, 1.0); // read the end value from result-file

simulate(N, simflags = "-override y=" + String(y)); // experiment 2, read the parameter value at the start of the simulation

val(z, 0.5); // verify that it worked

a.mo:

model M  //from experiment 1 

  Real x; 

  Real y; 

equation 

  der(x) = 2; 

  y = x;

end M;



model N  //from experiment 2 

   parameter Real y; // to be read from file

   Real z = sin(y); // f(y)

end N;

That's hard to say without the full model. You have a call to a user-defined function collisionDetection where its inputs do not seem to be part of the final equation system. Might be a problem with the inline module.

The latest omc does not use plt format or SimForge. You can get it here https://openmodelica.org/index.php/download. Older omc (and SimForge) have these problems.

The fact that the windows version of omc 1.6 says compilation succeeded does not mean a thing, because older versions of omc on windows failed to check the exit status of gcc. So compilation might have failed and your model simply uses the old result. Or the simulation executable died before it could start writing to the result file.

What works for now is:

function systm 

  annotation(__OpenModelica_Impure=true, Include="#include \"systm.c\"");

  input Real x; 

  output Real tm; 

  external "C" tm=systm(); 

end systm;

If you had two different annotation sections, one was ignored. This is what I will fix.

It seems the generated code for simulations do not use the Include annotation. Only when called as a shared object. Should be easy enough to fix.

Ah. That's possible to do in OpenModelica. Of course you would need to make it into two different experiments. One to get the final value of x, and one to use it:

loadString("model M

  Real x(start=0);

equation

  der(x) = 1.0;

end M;");getErrorString();

simulate(M, stopTime=10.0);

y := val(x, 10.0);

loadString("model N

  Real x = " + String(y) + ";

  Real y = sin(x);

end N;");getErrorString();

simulate(N);

val(y, 0.0);

For a horizontal line based on stop-time... use some other tool for post-processing the data. OpenModelica plotting functionality is limited as the project is more focused on simulation results. Octave and Matlab can both read the results and I believe they have plotting tools.

Maybe it's possible to hold the plot in OpenModelica and put additional lines afterwards, but I do not know the API that well.

The command shouldn't be needed (default has it off). Also, the damn API should never have been added in the first place, Adeel... You should just have created a new API for OMEdit (plotSilent or something).

The model probably does not simulate correctly. The files generated are specified by the filename prefix given to the simulation command (default is the model-name).

Use getErrorString() to get additional error-messages. Use only OMShell or command-line omc to get the error-messages.

Or simply upgrade to a modern OpenModelica (plt data format is very inefficient).

Because Modelica.Constants was updated to depend on ModelicaServices.

Either do loadModel(Modelica) or on the command-line, put both Modelica and ModelicaServices

Yes. There are other things you can do though (if you really do want the older omc).

setLinkerFlags("-L/c/dir1/dir2") might work

Your best bet is:
setEnvironmentVar("MODELICAUSERCFLAGS", "-L/c/dir1/dir2")

Since I believe the simulate flag for this was not added until recently:
simulate(ModelName, cflags = "-L/c/dir1/dir2")

You have two different Include annotations. Possibly only the last one was chosen. And since you include the c-file there is no need to include the header anyway.

Standard order 4

const int rungekutta_s = 4;

const double rungekutta_b[4] = { 1.0 / 6.0, 1.0 / 3.0, 1.0 / 3.0, 1.0 / 6.0 };

const double rungekutta_c[4] = { 0.0, 0.5, 0.5, 1.0 };

function f

  external "C" annotation(LibraryDirectory="file:///opt/local/lib",Library="MyLib");

end f;



model M

algorithm

  f();

end M;

You can also use a modelica:// URI like MyPackage/Resources/Library. The default is to search MyPackage/Resources/Library/$PLATFORM, where $PLATFORM is win32 and mingw32 for the Windows version of OpenModelica.

Of course there is:
Library={"MyLib","ModelicaExternalC"}

Then use two files: libMyLib.a for OpenModelica/GCC and MyLib.lib for Dymola and OpenModelica/MSVC.

You should have /usr/lib/omc/libModelicaExternalC.a. And anyway you should get a message saying it could not find that library while linking. Also note GCC is a one-phase linker, so the order matters. Try "mylib.o" before "ModelicaExternalC" and see if that helps.

delay()

Sometimes it does

I can't help unless I can see the model

And OMShell works.... I believe they both use the same method of starting omc... I guess it's time for a bug report.

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

Set component to OMEdit and make a link to this thread and Adeel will take a closer look.

The problem is OMOptim requires paradiseo. Paradiseo requires gcc 4.4, and some of the OSX system headers are incompatible with gcc 4.4. It might be possible to circumvent this (the Linux builds forces gcc 4.4 but only for OMOptim, if it can find gcc 4.4). OMNotebook is disabled because it simply does not work satisfactory on OSX.

The OMEdit app should be using the correct omc version (I hope). I believe you could try "omc +interactiveCorba" and see if any error-messages pop up. I got this on OSX:

sakura:~ martin$ /opt/openmodelica/bin/omc +d=interactiveCorba

Created server.

Dumped Corba IOR in file: /var/folders/9m/y0z96n9j22dg43hldg3v19y0000102/T//openmodelica.martin.objid

Started the Corba ORB thread with id: 0x10e9f0000

But I don't have an OSX GUI, so I cannot test OMEdit.app.

That is weird. It works for me on 11.4. I tried changing a file to use the OSX built-in OpenCL headers instead of the ones copied from... Windows? It should work better. Or output an error saying you don't have OpenCL headers. At which point you scream and I fix the configure script.

If you only want to apply my patch (and save time recompiling everything), see https://trac.openmodelica.org/OpenModel … set/14600.

Which of the options did you use? The OpenModelica sources do not use Xarch anywhere so it comes from either the portfile or the macports settings. From what I can tell the nightly is now done using +clang since OSX no longer likes GCC.

The following works to load it, but OMEdit requires MSL 3.1+:

loadModel(Modelica,{"2.2"});getErrorString();

loadModel(ModelicaAdditions);getErrorString();

Note that the library is called ModelicaAdditions, not ModelicaAddition.

What version of OpenModelica are you using? The following gave the correct result in r14428

loadModel(Modelica);getErrorString();

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

simulate(dck1.CtrlFlowSystem);getErrorString();

val(pressureEnthalpySource.outlet.P,0);getErrorString();

Look at the header auto-generated by OpenModelica. It should say that it expects the function to take a double. If you want to use single-precision floats, simple typecast it in your own function (will probably be automatic).

Don't name the function "main". It's reserved for the executable entry-point in C and has to have type int main(int argc, char** argv).

The one in the README uses the Qt version of OMShell, which executes getErrorString() after every single command (if I remember correctly). Someone probably forgot that the terminal version would give a different output.

Call getErrorString()

It needs readline. Try make mosh or ./config.status -recheck to see if it failed to find readline.

You're using a g++-version incompatible with the paradiseo framework. Try g++-4.4.

Did you try make qtclients (it should output an error-message if it failed to find omniORB). Else, it might be as easy as make clean (or rm Compiler/runtime/*.o) make -j2 omc (because omc was not re-compiled after omniORB was added to the mix).

You could try https://build.openmodelica.org/apt/pool … _amd64.deb until then. I think it works.

Ooops :p A new build is on its way. It should be roughly 2h36m until it finished: https://test.openmodelica.org/hudson/jo … ld/console

The readme says:

$ autoconf

$ ./configure --with-omniORB

Is that a block you wrote yourself or one that is in the standard library (if so, what is the name of the block)?

If it is a block you wrote yourself, go into the text view of that block and add the equation.

Tried imageshack, photobucket, tinypic, postimage or any of the prevalent number of screenshot hosts?

I updated the makefiles yesterday. In 5 hours or so the new nightly build should be up. As it's built on Debian stable, I am unsure if they also have this sundials bug in that library. nightly-ubuntu will not work, nightly might.

You could also try https://build.openmodelica.org/apt/pool … 1_i386.deb or https://build.openmodelica.org/apt/pool … _amd64.deb  (not part of a repository yet, I'm working on it).

apt-get install ompython I think the package is called. Then skip the install step.

variable(min=minValue,max=maxValue,start=initialGuess)

You don't need OPENMODELICALIBRARY since omc is smart enough to know where to look as long as OPENMODELICAHOME is set. Else I believe it's c:/OpenModelica1.9.0/usr/lib/omlibrary.

There should be some pdf's that come with the windows builds. Try to look in share/doc/omc/. OMEdit knows where to look for its documentation (F1, or Help->User manual).

Which of the packages were you using? Ubuntu 10.04 is very, very old and might no longer work with the builds.

That's easy to answer: it doesn't work well in Linux.

Why not use the C-code? It's C++-compatible If you want to use the C++ codegenerator, you need to compile omc yourself since the C++ code depends on a lot of runtime libraries that we do not want to include with OpenModelica.

The reason is a quite good one that is possible to work around, but we don't want to (after bootstrapping it should be impossible to work around):
You need to have the compiled omc in order to generate the mo-file from a tpl-file. Which means you need to have omc installed before trying to compile it...

We could work around it by generating the C-code to compile a small susan compiler, and add this only once, but this works for now.

Yup. But if a model has a uses-annotation and you try to simulate it, the library will also be loaded.

Remove the uses(Visualization) annotation from the library. It does not depend on it and OpenModelica does not supply it.

There is not, but you could just choose outputFormat="csv" when simulating.

Seems to work with the new tearing implementation: https://trac.openmodelica.org/OpenModelica/ticket/1692

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

So it doesn't work if you cd e:/OM/Tests/ and then run path/to/omc cmlScript.mos?

1.9.0 isn't finished yet, but this is what you get so far:
https://trac.openmodelica.org/OpenModel … otes/1.9.0

Plus some stuff noone bothered to document

You can either save the annotation in there using the setup dialog or use the experiment annotation.

annotation(experiment(StopTime=3));

Try https://trac.openmodelica.org/OpenModel … eset/13088
And please add bug reports to the trac in the future

Ok, I figured out how to solve it. Simply run:

ld -o OSXUGLYHACK.o -r util/omc_error.o ./meta/meta_modelica_builtin.o ./meta/meta_modelica_string_lit.o ./meta/realString.o ./meta/meta_modelica_real.o ./meta/gc/gc.o ./meta/gc/common.o ./meta/gc/roots.o ./meta/gc/generational.o ./meta/gc/marksweep.o ./util/base_array.o ./util/boolean_array.o ./util/division.o ./util/index_spec.o ./util/integer_array.o ./util/java_interface.o ./util/list.o ./util/memory_pool.o ./util/modelica_string.o ./util/modelinfo.o ./util/read_write.o ./util/read_matlab4.o ./util/real_array.o ./util/ringbuffer.o ./util/rtclock.o ./util/string_array.o ./util/utility.o ./util/varinfo.o ./math-support/bigden.o ./math-support/biglag.o ./math-support/dgesv_aux.o ./math-support/dogleg.o ./math-support/dpmpar.o ./math-support/enorm.o ./math-support/fdjac1.o ./math-support/hybrd.o ./math-support/hybrd1.o ./math-support/hybrj.o ./math-support/lsame.o ./math-support/nelmead.o ./math-support/newuoa.o ./math-support/newuob.o ./math-support/nonlinearSystem.o ./math-support/nonlinearSolverHybrd.o ./math-support/qform.o ./math-support/qrfac.o ./math-support/r1mpyq.o ./math-support/r1updt.o ./math-support/trsapp.o ./math-support/update.o ./simulation/solver/daux.o ./simulation/solver/ddasrt.o ./simulation/solver/ddassl.o ./simulation/solver/dassl.o ./simulation/solver/delay.o ./simulation/solver/dlamch.o ./simulation/solver/dlinpk.o ./simulation/solver/events.o ./simulation/solver/initialization.o ./simulation/solver/initialization_data.o ./simulation/solver/ipopt_initialization.o ./simulation/solver/model_help.o ./simulation/solver/solver_main.o ./simulation/solver/kinsol_initialization.o ./simulation/solver/newuoa_initialization.o ./simulation/solver/simplex_initialization.o ./simulation/solver/nelderMeadEx_initialization.o ./simulation/results/read_csv.o ./simulation/results/simulation_result_csv.o ./simulation/results/simulation_result_mat.o ./simulation/results/simulation_result_plt.o ./simulation/options.o ./simulation/simulation_input_xml.o ./simulation/simulation_runtime.o ./simulation/../linearization/linearize.o meta/meta_modelica_catch.o meta/meta_modelica.o

Followed by:

ar -ru libSimulationRuntimeC.a OSXUGLYHACK

This makes the linker suddenly find the symbols. Stupid OSX linkers. Now to see if I can do this without breaking the other tools...

The only difference I can see from the linux version is that the symbols are prefixed "_" in OSX. Of course everything works in Linux and nothing in OSX.

From OMShell or any other tool that runs OpenModelica API (like mos-scripts)

loadModel(Modelica,{"3.2"});

res:=simulate(Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMPM_Inverter);getErrorString();

writeFile("Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMPM_Inverter.sim", res.messages);getErrorString();

That's only because OMEdit fails at showing any messages (go slap Adeel around by adding a ticket if you want them). The regular simulate() command will show all warnings, simulation didn't finish, solution is unsound, etc messages.

All models in the MSL do not work out of the box. The MSL is a third-party library, not developed by us.

https://trac.openmodelica.org/OpenModel … eset/13042

https://test.openmodelica.org/~marsj/MS … verter.sim

(from a more recent omc)

As you can see some variables have start-values outside their min-max range. This probably causes some issues with initialization.

(The good reason is: omniorb is built without python support by default in macports)

That's easy to answer: the Portfile uses --disable-python-interface. Get it from subversion if you need it. It was probably disabled because it was annoying to try to build it on OSX.

You do not re-simulate. Use:

buildModel(M);

setInitXml...;

system("./M -f newFile.xml");

Do you have any environment variables from the jmodelica build process set? Because there are no references to that file in our sources, so the only way you try to build it is if you have added it yourself.

Oh, sorry I did that too. Should not matter (I hope). Too much copy-paste and fiddling around until it worked properly. Event-handling in Modelica is sometimes a little hard to get right. Luckily you don't need it (Bouncing-Ball level hard) very often...

This is simply due to the numerical solver you have chosen. If you take large enough steps (by setting stoptime=50 or similar), the code does not work properly since the guard will not be triggered by the high velocity (the velocity is high, but still not high enough to bounce back above surface level...).

I find the following works better since now there is a much lower risk of getting stuck below the surface (acceleration checked every time-step):

model BB

  parameter Real k = 0.825; //collision factor 

  parameter Real g = 9.81; 

  parameter Real v_min = 0.50; //min. speed 



  Real x(start = 1.5); //height 

  Real v; // speed 

  Boolean stopped;

equation 

  v = der(x);  //Integration of path 

  der(v) = if not stopped then -g else 0.0;

  when x <= 0.0 then

    stopped = abs(pre(v)) < v_min;

    reinit(v, if not stopped then -k * pre(v) else 0.0);

    reinit(x, 0.0);

  end when; 

end BB;

Well, you could always send Adeel a message complaining you don't get the output from the executable... Or adding a bug to trac.openmodelica.org.

OMShell works the same way as you do in OpenModelica scripting from command-line

loadModel(Modelica)

getErrorString()

loadFile("path/to/myFile.mo")

getErrorString()

simulate(myModelName, stopTime=0.10)

getErrorString()

Yes, OMEdit sucks at displaying simulation output. Like "your model ended before the stop-time due to xyz". You can set the filename and read that if you prefer OMEdit over OMShell

Bugs go here: https://trac.openmodelica.org/OpenModelica/newticket

I created a new one: https://trac.openmodelica.org/OpenModelica/ticket/1827

The work-around is using any function that prints and returns a value.

model M

  function myPrint

    input String str;

    input String file := "";

    output Boolean ok;

  algorithm

    Modelica.Utilities.Streams.print(str, file);

    ok := true;

  end myPrint;

  Integer i;

protected

  Boolean dummy;

equation

  when sample(0,0.1) then

    dummy = myPrint("printing at time: " + String(time) + "\n");

    i = pre(i) + 1;

  end when;

end M;

Which gives you output:

printing at time: 0

printing at time: 0.1

printing at time: 0.2

printing at time: 0.3

printing at time: 0.4

printing at time: 0.5

printing at time: 0.6

printing at time: 0.7

printing at time: 0.8

printing at time: 0.9

printing at time: 1

The start values are part of the ModelName_init.xml file. You can modify it manually, try your luck with xsltproc, or hope https://build.openmodelica.org/Document … Value.html works properly

The standard library (MSL) contains the basic components for multibody simulation (see the documentation).

And OpenModelica can simulate the example models in there, so you should not have any major issues to get it running.

The standard library (MSL) contains the basic components for multibody simulation (see the documentation).

And OpenModelica can simulate the example models in there, so you should not have any major issues to get it running.

You have the possibility to write any function you like using `external "C"`. This means you can make the simulation wait at certain times. For example by sampling every 0.01 seconds and sleeping until the correct time. This should work in any tool.

OpenModelica itself does not have built-in support for soft real-time simulations, although it might in the future.

Our back-end developer replied:

The pendulum model requires dynamic state selection. It is not enabled by default. You can enable it by setting
setMatchingAlgorithm("PFPlusExt");
setIndexReductionMethod("dynamicStateSelection");

I opened up a new ticket (#1820) to have these options in OMEdit as well.

I opened up a ticket since this should be a bug report

Xwang wrote:

Is it possible to integrate python code in modelica (I've written some functions which get joystick inputs and send udp packets)?

Yes, but you will need to write an external C wrapper that calls the python code from C (or tcp communication with the python code). I believe it is a lot easier to write the code in C to begin with.

What kind of ide are available (open source)? I've seen some screenshots that shows modelica models in a graphical form (like simulink ones).

I guess OMEdit. jmodelica might have something similar hidden somewhere, but I am not familiar with all their tools.

Moreover what is the difference between openmodelica and jmodelica?

In short, from what I have heard the OpenModelica front-end supports more language features, and the back-end (symbolic manipulations) scales better. I do not know if simulations run faster in jmodelica or not.

Both are open source, can I use both of them with the same model or the model is somewhat "linked" with the program used to create it?

As long as you do not rely on any tool-specific features.

Is there any arch linux package available?

Sort of You can find a PKGBUILD on these forums, but I believe it is not complete.

What about C code generation from a model?

Yes, by default.

The Ubuntu 32-bit OpenModelica package is built using sse2 extensions (-march=pentium4) because it used to be required for numerical stability. There are some comments that say this was no longer needed. Presumably because -fstore-float was used in the configure CFLAGS. But the new Makefiles do not use fstore-float, so maybe SSE2 is required anyway. Your mileage may vary (I'll try removing march=pentium4 from the nightly build and we'll see if it starts working...).

If they are in the omlibrary folder you should be able to set up loading them in the options (PackageName default)

Using loadModel(), the package is a structured entity and some limitations are imposed according to the Modelica Specification 3.2 rev1: 13.2.2.1 Mapping a Package/Class Hierarchy into a Directory Hierarchy (Structured Entity).

[For example, if directory A contains the three files package.mo, B.mo and C.mo the classes defined are A, A.B, and A.C.]

So yes this is intended. We also check the package.order file to see if the author forgot to include a file, used wrong case in filenames, etc.

Fixed in r12689

Thanks for the report. I added a ticket here: https://trac.openmodelica.org/OpenModelica/ticket/1779
With a total model creating using setCommandLineOptions("+showAnnotations"); saveTotalSCode("total.mo",AerosondeModel);

Sources hard to get? The deb repository has source builds, can pull them all from there:
https://build.openmodelica.org/apt/pool … rig.tar.gz
Or from the official server (don't know if it's direct-linkable, but just click ok without filling in their form and you get where you want)
https://gforge.inria.fr/frs/download.ph … ta2.tar.gz

The build of the mlton package or rml-mmc-svn failed?

I used the following rml package for myself (should save more than a few minutes every build since mlton creates compiled code instead of interpreted):

pkgname=rml-mmc-svn

pkgver=20120814

pkgrel=1

pkgdesc="Relational Meta Language and the Meta Modelica Compiler"

arch=('i686' 'x86_64')

url="http://www.ida.liu.se/labs/pelab/rml/"

license=('custom:OSMC')

depends=('mlton' 'sh')

makedepends=('subversion')



_svndir="trunk"

_svnurl="https://openmodelica.org/svn/MetaModelica/$_svndir"



build() {

    cd "$srcdir"

    if [ -d $_svndir/.svn ]; then

        cd $_svndir

        svn --username anonymous --password none --no-auth-cache up

    else

        svn --username anonymous --password none --no-auth-cache co $_svnurl

    fi

    cd "$srcdir/$_svndir"

    ./configure --prefix=/usr --disable-debug --disable-profile \

                --nosmlnj --destdir="$pkgdir"

    make -C runtime

    make -C etc

    make -C compiler rml-mlton

}



package() {

    cd "$srcdir/$_svndir"

    make -C etc install

    make -C runtime install

    make -C compiler install-mlton

}

1. Works fine on my arch (it looks for /etc/apt to decide if it has debian layout) In my opinion nothing is lost if you skip it, but someone some day would complain if it's missing

[martin@mega PythonInterface]$ uname -a

Linux mega 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux

[martin@mega PythonInterface]$ make

omniidl -bpython -Wbglobal=_OMCIDL -Wbpackage=OMPythonIDL ..//Compiler/runtime/omc_communication.idl

! which python2.6 || python2.6 setup.py install --no-compile `test -d /etc/apt && echo --install-layout=deb` --prefix=..//build

which: no python2.6 in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/martin/bin)

! which python2.7 || python2.7 setup.py install --no-compile `test -d /etc/apt && echo --install-layout=deb` --prefix=..//build

/usr/bin/python2.7

running install

running build

running build_py

creating build

creating build/lib

creating build/lib/OMPython

copying OMPython/OMConfig.py -> build/lib/OMPython

copying OMPython/__init__.py -> build/lib/OMPython

creating build/lib/OMPython/OMParser

copying OMPython/OMParser/__init__.py -> build/lib/OMPython/OMParser

creating build/lib/OMPythonIDL

copying OMPythonIDL/__init__.py -> build/lib/OMPythonIDL

copying OMPythonIDL/omc_communication_idl.py -> build/lib/OMPythonIDL

creating build/lib/OMPythonIDL/_OMCIDL

copying OMPythonIDL/_OMCIDL/__init__.py -> build/lib/OMPythonIDL/_OMCIDL

creating build/lib/OMPythonIDL/_OMCIDL__POA

copying OMPythonIDL/_OMCIDL__POA/__init__.py -> build/lib/OMPythonIDL/_OMCIDL__POA

running install_lib

copying build/lib/OMPythonIDL/_OMCIDL__POA/__init__.py -> ..//build/lib/python2.7/site-packages/OMPythonIDL/_OMCIDL__POA

copying build/lib/OMPythonIDL/_OMCIDL/__init__.py -> ..//build/lib/python2.7/site-packages/OMPythonIDL/_OMCIDL

copying build/lib/OMPythonIDL/__init__.py -> ..//build/lib/python2.7/site-packages/OMPythonIDL

copying build/lib/OMPythonIDL/omc_communication_idl.py -> ..//build/lib/python2.7/site-packages/OMPythonIDL

running install_egg_info

Removing ..//build/lib/python2.7/site-packages/OMPython-1.0-py2.7.egg-info

Writing ..//build/lib/python2.7/site-packages/OMPython-1.0-py2.7.egg-info

python setup.py install --no-compile `test -d /etc/apt && echo --install-layout=deb` --prefix=..//build

running install

running build

running build_py

running install_lib

copying build/lib/OMPythonIDL/_OMCIDL__POA/__init__.py -> ..//build/lib/python3.2/site-packages/OMPythonIDL/_OMCIDL__POA

copying build/lib/OMPythonIDL/_OMCIDL/__init__.py -> ..//build/lib/python3.2/site-packages/OMPythonIDL/_OMCIDL

copying build/lib/OMPythonIDL/__init__.py -> ..//build/lib/python3.2/site-packages/OMPythonIDL

copying build/lib/OMPythonIDL/omc_communication_idl.py -> ..//build/lib/python3.2/site-packages/OMPythonIDL

running install_egg_info

Removing ..//build/lib/python3.2/site-packages/OMPython-1.0-py3.2.egg-info

Writing ..//build/lib/python3.2/site-packages/OMPython-1.0-py3.2.egg-info

2. make uninstall is in my opinion rather pointless since package managers manage the installation or you choose some prefix or DESTDIR=some-test-dir
But you can try the following in trunk (I might add it):
find build/ -type f -exec bash -c 'rm `echo {} | sed s,^build,/usr,`' ';'
find build/ -type d -exec bash -c 'rmdir `echo {} | sed s,^build,/usr,`' ';'

3. Must only show up in g++-4.7 (I tried the g++ available on the testserver and it said nothing even with -Wall). I'll contact the developer though

I'd make the package depend on qwt (6.0.1-2 in extra) rather than the AUR package. This is because the qwt packages are a hell to get working properly since all distributions rename them... and I made our sources work with the official package

I could probably make it work with both, but as an arch user at home, it's nicer to not have to recompile everything.

I am fairly sure those stdio files try to use the system headers. So your XCode does not install /usr/include/stdio.h? How does it compile simple C-files then?

$ echo -e '#include <stdio.h>\nint main() {puts("abc\\n");}' | /opt/openmodelica/bin/gcc-mp-4.4 -xc - && ./a.out 

$ echo -e '#include <stdio.h>\nint main() {puts("abc\\n");}' | cc -xc - && ./a.out 

If you do not have /usr/include/stdio.h, I suppose you do not have XCode installed for the system headers.

Add --with-omniORB and re-run make omc. --withCORBA was renamed to --with-MICO some time ago; I'll update the error-message.

Does OMShell-terminal start ok? (It can use raw sockets instead of CORBA)

Else, try to create a file a.mos:

checkSettings();

Run it:

omc a.mos

If everything works fine in that... Try to run:

omc +d=interactiveCorba

And see if any error-messages pop up. If it all looks fine it might be some setup of iptables that could possibly affect communicating with omc since it runs as a server process.

Noone can figure out paradiseo. I am convinced it requires gcc 4.2~4.4 is required to build it (it being the latest *beta*). And damn it's slow using ARCH CFLAGS and default compiler. GCC 4.4 is probably 5 times faster. The openmodelica.profile I am pretty sure is not required, and there are better icons used in the current deb-packages (which you can extract using file-roller or ar and tar).

But it turns out someone was silly enough to add omoptimbasis as a dependency even if omoptim was disabled (this used to work earlier). I blame myself. But the build should work now. I made some modifications as I already have rml-mmc. I also didn't fully re-run the test.

Some suggestions (I didn't try them, but should make things run properly later on; especially prefix is needed to point to the final installation destination):

build() {

  svn --username anonymous --password none checkout https://openmodelica.org/svn/OpenModelica/trunk/ openmodelica

  msg "SVN checkout done or server timeout"

  msg "Starting make..."



  cd "${srcdir}/openmodelica"



  autoconf || echo 'autoconf fail'



  ./configure --prefix=/opt/openmodelica --with-omniORB --without-paradiseo --disable-python-interface

  make

}



package() {

  cd "${srcdir}/openmodelica"

  make install DESTDIR=${pkgdir} 

  install -D -m644 'OSMC-License.txt' "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

  install -D ${srcdir}/${pkgname}.profile ${pkgdir}/etc/profile.d/${pkgname}.sh



  mkdir -p ${pkgdir}/usr/share/icons/

  install -D -m644 ${srcdir}/*.png ${pkgdir}/usr/share/icons/

  mkdir -p ${pkgdir}/usr/share/applications/

  install -D -m644 ${srcdir}/*.desktop ${pkgdir}/usr/share/applications/

}

Snippet from latest deb-package:

configure: configure.in

        autoconf



config.status: configure

        dh_testdir



        # Add here commands to configure the package.

        RMLHOME=/usr CC="$(CC)" CXX="$(CXX)" CFLAGS="$(CFLAGS)" ./configure \

        --host=$(DEB_HOST_GNU_TYPE) \

        --build=$(DEB_BUILD_GNU_TYPE) \

        --prefix=/usr \

        --with-omniORB=/usr \

        --with-static-lpsolve=/usr \

        --with-static-readline=/usr \

        --with-static-sqlite=/usr/lib/`test -f /usr/lib/$(DEB_HOST_GNU_TYPE)/libsqlite3.a && echo $(DEB_HOST_GNU_TYPE)/`libsqlite3.a \

        --disable-rml-trace



build: build-stamp



build-stamp:  config.status

        dh_testdir



        # Add here commands to compile the package.

        $(MAKE) release mosh omlibrary

        # Qtclients will start make omc again

        # This is a good thing as Susan will then run and regenerate SimCodeC

        ANTLRHOME=/usr $(MAKE) qtclients;

        /usr/bin/time -f "== Testsuite wall-time: %e" $(MAKE) -C testsuite/ > ./build/share/doc/omc/testsuite.txt 2>&1

        touch build-stamp



clean:

        dh_testdir

        dh_testroot

        rm -f build-stamp 



        # Add here commands to clean up after the build process.



        dh_clean 



install: build

        dh_testdir

        dh_testroot

        dh_prep 

        dh_installdirs -popenmodelica -Pdebian/tmp



        # Add here commands to install the package into debian/tmp.

        $(MAKE) install DESTDIR=$(DEST)

The actual error is higher up in the log since it looks like you are making a parallel build. In principle I would need to complete log-file as it is out of order.

Or do you perhaps have an ANTLR2 jar-file in your CLASSPATH? That could possibly screw things up.

What is your "java -version"? I use (ArchLinux build 7.u5_2.2.1-1-x86_64) and the ANTLR stuff runs fine for me. I assume you have tried make clean?

Use external C or Modelica.Blocks.Tables and be prepared to swear a lot

If you strongly believe OpenModelica is causing it, try to start the OS in Safe Mode (possibly with Networking). If there is then no crash it is highly likely some 3rd party driver is causing the issues.

Blue screens are usually caused by faulty hardware (try running Memtest86+) or faulty device drivers (such as a webcam, printer or other USB device you plugged into the computer).
OpenModelica itself should be unable to cause your operating system to crash, although if there are buggy device drivers in there, anything can happen... Have you tried running OpenModelica as a non-privileged user (non-admin)?

Adeel: The file will *not* be generated in /tmp on OSX. The temp-directory on OSX is much more complicated (look into the sources for OMEdit to see where to look).

Which of the Ubuntu packages? release, stable or nightly? It should be working in nightly; for the others you also need to install liblapack-dev

r12308 should do it. My bad. Also sorry for taking so long; work computer filtered the email and my home one doesn't subscribe to the folder...

Ok, try r12302.

svn up
./config.status --recheck
rm -f  OMOptim/{,OMOptimBasis/}build/Makefile{,Lib}
make -j2

That's fine. I'll make configure look for both.

They need to be somewhere. I used the paths from our Windows package as I assumed that was a proper paradiseo installation. Its directory structure is as follows:

paradiseo-eo/src/...

paradiseo-eo/lib

paradiseo-eo/lib/libeo.a

paradiseo-eo/lib/libeoutils.a

And similar for -moeo and -mo. Do 'find /usr/local/paradiseo -name "*.a"' and I will update the paths

Try r12299 and see if it configure works with it (should print soemthing like paradiseo... stock version in: /usr/local/paradiseo)

My main problem is just deciding where to put this structure in the deb-packages since it won't conform to the Filesystem Hierarchy Standard with /usr/local reserved for the administrator... I guess I should just make the configure script look for both.

So make install does not put the files in /usr/local?

I tried running the bash-script of paradiseo but as always it fails me. And it seems it now won't compile on modern GCC anyway. I'll just stick to the bianry package I made ages ago (https://build.openmodelica.org/apt/pool … md64.deb). But you are correct in that configure.in probably does not reflect the structure of the paradiseo installer since I never got that running...

From the debian build-script:

       # paradiseo cannot be compiled using gcc-4.5+

        (cd paradiseo-eo; CC=gcc-4.4 CXX=g++-4.4 cmake . -Dconfig=../install.cmake)

        (cd paradiseo-moeo; CC=gcc-4.4 CXX=g++-4.4 cmake . -Dconfig=../install.cmake)

        (cd paradiseo-mo; CC=gcc-4.4 CXX=g++-4.4 cmake . -Dconfig=../install.cmake)

        $(MAKE) -C paradiseo-eo VERBOSE=1

        mkdir -p ../paradiseo-eo/build/lib/

        # Yes, paradiseo builds outside its source directory! It's crazy!

        cp paradiseo-eo/lib/*.a ../paradiseo-eo/build/lib/

        $(MAKE) -C paradiseo-moeo VERBOSE=1

        $(MAKE) -C paradiseo-mo VERBOSE=1

        cp paradiseo-*/lib/*.a $(DEST)/usr/lib/paradiseo

        (cd paradiseo-eo/src/ && for f in `find . -name "*.h"`; do mkdir -p `dirname $(DEST)/usr/include/paradiseo/$$f`; cp $$f $(DEST)/usr/include/paradiseo/$$f; done)

        (cd paradiseo-moeo/src/ && for f in `find . -name "*.h"`; do mkdir -p `dirname $(DEST)/usr/include/paradiseo/$$f`; cp $$f $(DEST)/usr/include/paradiseo/$$f; done)

        (cd paradiseo-mo/src/ && for f in `find . -name "*.h"`; do mkdir -p `dirname $(DEST)/usr/include/paradiseo/$$f`; cp $$f $(DEST)/usr/include/paradiseo/$$f; done)

        cp paradiseo-eo/src/eo $(DEST)/usr/include/paradiseo/

        cp paradiseo-eo/src/utils/checkpointing $(DEST)/usr/include/paradiseo/utils/

        cp paradiseo-eo/src/other/external_eo $(DEST)/usr/include/paradiseo/other/

        cp paradiseo-moeo/src/moeo $(DEST)/usr/include/paradiseo/

Do you plan on using OMOptim_ Configuring without paradiseo is always an option. And we do use paradiseo 1.3. I'll see if I can fix it. Where are your headers installed to?

https://trac.openmodelica.org/OpenModel … eset/12289 - checking if the header is qwt5 using grep for now. Should help a little. You could also try to remove that qwt symlink and try the latest trunk if you want to see if I broke anything for you

Which won't work because Qt4 headers are required to preprocess the qwt headers. Now I remember why I hate trying to autoconf this library

I will see if I can apply some autoconf magic to make this work. Previous assumptions that the include suffix /usr/include/qwt5 and library names libqwt.so are the same fail in the current autoconf...

The with-qwt option seems to only accept =no or =yes and autodetects some of the very odd differences between different distributions of qwt (some use qwt, some qwt-qt4). I'm willing to bet you have something like /usr/include/qwt5/... ? If so that's the first time I saw it, but I can change the trunk if so. Please list the files of your qwt5 package simialr to this:

$ apt-file list libqwt5-qt4-dev

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_abstract_scale.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_abstract_scale_draw.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_abstract_slider.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_analog_clock.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_array.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_arrow_button.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_clipper.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_color_map.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_compass.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_compass_rose.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_counter.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_curve_fitter.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_data.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_dial.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_dial_needle.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_double_interval.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_double_range.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_double_rect.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_dyngrid_layout.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_event_pattern.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_global.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_interval_data.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_knob.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_layout_metrics.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_legend.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_legend_item.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_legend_itemmanager.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_magnifier.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_math.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_paint_buffer.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_painter.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_panner.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_picker.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_picker_machine.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_canvas.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_curve.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_dict.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_grid.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_item.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_layout.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_magnifier.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_marker.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_panner.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_picker.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_printfilter.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_rasteritem.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_rescaler.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_scaleitem.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_spectrogram.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_svgitem.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_plot_zoomer.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_polygon.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_raster_data.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_round_scale_draw.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_scale_div.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_scale_draw.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_scale_engine.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_scale_map.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_scale_widget.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_slider.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_spline.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_symbol.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_text.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_text_engine.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_text_label.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_thermo.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_valuelist.h

libqwt5-qt4-dev: /usr/include/qwt-qt4/qwt_wheel.h

libqwt5-qt4-dev: /usr/lib/libqwt-qt4.so

libqwt5-qt4-dev: /usr/lib/x86_64-linux-gnu/qt4/plugins/designer/libqwt_designer_plugin.so

libqwt5-qt4-dev: /usr/share/doc/libqwt5-qt4-dev/README

libqwt5-qt4-dev: /usr/share/doc/libqwt5-qt4-dev/README.Debian

libqwt5-qt4-dev: /usr/share/doc/libqwt5-qt4-dev/changelog.Debian.gz

libqwt5-qt4-dev: /usr/share/doc/libqwt5-qt4-dev/copyright

Did you do "make clean" first? There are probably some o-files compiled against qwt6. If you want to recompile as little as possible "make -C OMPlot/OMPlotGUI/ -f Makefile.unix clean" I think

The OpenModelica 3D visualization was (poor) work performed before the 3D API in ModelicaServices was standardized. Use any re-implementation of ModelicaServices, commercial or not. It is just an API and OpenModelica has nothing to do with it.

The Linux version of OpenModelica is built on every commit using Ubuntu (https://test.openmodelica.org/hudson/). The majority of developers use Linux (mainly arch and debian-based, but some Fedora and CentOS). Nightly builds use Ubuntu and Debian. Windows and Mac builds only on demand or for releases (every 9 months or so). The Mac version also does not have the same features that the Linux release does (OMNotebook support to name one).

For the full list of dependencies used by aptitude (from e.g. https://build.openmodelica.org/apt/pool … n.tar.gz):

Source: openmodelica

Section: math

Priority: optional

Maintainer: OpenModelica Build System <build@openmodelica.org>

Build-Depends: debhelper (>= 7.0.0),

 libncurses5-dev,

 libsqlite3-dev,

 libssl-dev (>= 0.9.8g),

 libreadline-dev,

 libqtwebkit-dev | libqt4-dev (>= 4.4.3),

 libqwt5-qt4-dev (>= 5.1.1),

 liblpsolve55-dev (>= 5.5.0.10),

 rml-mmc (>= 204),

 openjdk-6-jdk | sun-java6-jdk,

 libomniorb4-dev,

 omniidl4 | omniidl (>= 4.0.0),

 omniidl4-python | omniidl-python,

 python-omniorb,

 gnuplot,

 xsltproc,

 flex,

 paradiseo,

 bison,

 libf2c2-dev,

 liblapack-dev,

 autoconf,

 zip,

 libexpat1-dev,

 libsundials-serial-dev

Standards-Version: 3.8.4

You're using qwt 6.0 is what's wrong They changed the API.
And yes, 3D support was removed from builtin OpenModelica as it is now part of Modelica libraries instead (ModelicaServices packages, mostly commercial, but standardized).

You don't need to use make install to use OpenModelica. You don't need any of the optional dependencies, such as CORBA (omniORB). But what you then end up with is an executable in trunk/build/bin/omc that you need to call via absolute path, and you get no GUI. If your OS supports sockets and readline you even get OMShell-terminal. Perfect according to me

Otherwise it's also quite easy to install the binary packages (if they match your shared libraries). I find rml-mmc and paradiseo harder to install than OpenModelica, because they do not work with all C-compilers.

Most of the deprecated things mentioned were deprecated for a reason - removal. In the current trunk none of them are useful anymore.

Have you tried configure --without-paradiseo (only OMOptim uses it)? Also, paradiseo is used as a library, so your PATH does not matter. You need to use configure LDFLAGS="..." CPPFLAGS="..." to set the paths I believe (or maybe --with-paradiseo=/usr/local/paradiseo works).

You can do this by post-processing in matlab/octave. Probably also scilab.

Can you break up the time for initialization and see if that is what became slower? simulate(M,measureTime=true) might help, if it was working in the revisions you tested.

Wow, it seems you are right. Squeezy does not have KINInit... I added a check for linkage of this function in the configure-script so the next version of omc should be built without sundials.

To define documentation in Modelica, set Documentation.info:

function fill "Returns an array with all elements equal"

  input OpenModelica.Internal.BuiltinType s;

  input Integer n annotation(__OpenModelica_varArgs=true);

  output OpenModelica.Internal.BuiltinType o[:];

  external "builtin";

  annotation(Documentation(info="<html>

  See <a href=\"modelica://ModelicaReference.Operators.'fill()'\">fill()</a>

</html>"));

end fill;

To query, use getDocumentationAnnotation():

[martin@mega trunk]$ /home/martin/trunk/build/bin/OMShell-terminal

OMShell Copyright 1997-2012, 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 &

>>> getDocumentationAnnotation(fill)

{"<html>

  See <a href=\"modelica://ModelicaReference.Operators.'fill()'\">fill()</a>

</html>",""}

>>> 

https://build.openmodelica.org/Document … ystem.html
http://linux.die.net/man/3/system
Any command you can run from command-line, like cat, grep, sed and awk

$TypeName() is an OpenModelica code quoting construct.

The syntax of for-loops is the same as for Modelica algorithm sections with the caveat that some of its semantics are a bit weird since the scripting environment does type-checking once for each execution of a statement. Unlike Modelica functions where the type is calculated only once.

This is because some of the API calls, like setComponentModifierValue (?) are part of an untyped API (they do not evaluate the arguments; expecting only literal values, etc). The typed API can be found here: https://build.openmodelica.org/Document … pting.html or by using  getDocumentationAnnotation(OpenModelica.Scripting.XXX).
As long as you used typed API you can do a lot of cool things with for-loops or reduction expressions (which are a lot faster since the expression is typed only once).

{simulate(M) for M in {

$TypeName(Modelica.Mechanics.MultiBody.Examples.Elementary.Pendulum),

$TypeName(Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum)

}}

Some cool examples for utilizing the scripting environment in the later versions of OpenModelica:
https://openmodelica.org/svn/OpenModeli … ursive.mos
https://openmodelica.org/svn/OpenModeli … ateDoc.mos
(user: anonymous, password (4 letters): none)

Maybe something like this:

loadString("model M

  parameter Real p = 3.0;

end M;

");

buildModel(M);

for i in 1:5 loop

  system("sh \"" + getInstallationDirectoryPath() + "/share/omc/scripts/replace-startValue.sh\" p " + String(i) + " M_init.xml > new_init.xml");

  j:=system("./M -f new_init.xml > log 2>&1");

  print("Output of run " + String(i) + " (exit code "+String(j) +"): " + readFile("log") + "\n");

end for;

getErrorString();

No, MSL 2.2 MultiBody does not work in the OM backend (it will pass flattening so MathModelica can simulate the model in their backend).
If you want to use MultiBody with OM, MSL 3.1 is the only way to go (as Adrian suggested).

Our bugtracking system is down right now so I cannot find the relevant bug to link for you, but I could probably find similar ones that were fixed.
The issue here is that you have pre(x) where x is an alias of p, which happens to be a parameter. Since parameters cannot change, pre(x) = pre(p) = p and should have been replaced somewhere in the backend (but only the change to pre(p) was changed).
Note to self: Maybe our simplification routine should get an optional hashtable of variables and their variability so we could remove these things easier in the back-end... I'll ask the back-end people...

Note that files that are not encoded in UTF-8 are not valid Modelica files. But OM provides workarounds.

See http://build.openmodelica.org/Documenta … Model.html

Yes, there was a problem in the try above since tlmDelay was set in 2 places. It would probably have worked if tlmDelay = 0.0 was not set (or used start = 0.0 instead). The code below is of course the nicest Glad to see it worked.

The total error can be reduced to the following:

model M

  Real tlmDelay = 0.0;

initial algorithm

  tlmDelay := 1.5;

end M;

I believe this is an erroneous model (the model is reduced to 0.0 := 1.5). The backend should detect this error and scream a bit.

I guess you want to give tlmDelay a default value and modify it slightly during initialization? I'm a bit unsure how you do this in a good way in Modelica. You probably simply want to make tlmDelay a parameter instead and avoid sources for error.

myscript.mos:

loadModel(Modelica);

loadFile("mymodel.mo");

simulate(MyModel);

From the shell:

omc myscript.mos

In Windows (probably):

%OPENMODELICAHOME%\bin\omc myscript.mos

Would you mind sharing the code of the C-function and the lines of Modelica code that caused the error?
To me it looks your Modelica code might be:

0.0 = f(x);

And for some reason the backend does not realize it needs to solve this equation as a non-linear system, but I could be wrong...

That library is malformed as Modelica is case-sensitive. Some library developers use operating systems and Modelica tools that disregard this restriction.

Change the package named FuelCellLib.casestudies to FuelCellLib.CaseStudies or the within-statement to without caps. Or ask the library developer for an updated version of the library.

Yes, OpenModelica generates executables which do not depend on OMEdit. It is only on Windows that they are dependent on some odd files (the MinGW runtime), but you can add the dll's to the system PATH.

The non-linear solvers are used to solve non-linear system. They are not used for numerical integration (which choosing a solver in OpenModelica implies).

You mean adding a new solver except the ones that are there by default (dassl,euler,rk,etc)? You would need to modify the source code.

Using events:
when inertia1.w > inertia2.w then
   spring1.c = 10000;
else
   spring1.c = 0;
end when;

No root-finding:
spring1.c = if noEvent(inertia1.w > inertia2.w) then 10000 else 0;

https://trac.modelica.org/Modelica/ticket/95 says it wasn't touched and since a lot of bugs were closed solved in 3.3 that means 3.3 spec should be in the works with rooted still not mentioned.

I thought Adeel had added display of messages in the latest OMEdit; if you are using the latest version send him an angry email and add a bug to the tracker: http://openmodelica.org:8080/cb/proj/tr … acker_id=1

OMEdit should output something like:

 DASSL--  AT CURRENT T (=R1)  500 STEPS

      In above message,  R1 =   .5494283178917E-04

 DASSL--  TAKEN ON THIS CALL BEFORE REACHING TOUT

warning | Error solving nonlinear system at time 5.4961e-05

The default solver is dassl; not dopri5. I forget what application dopri5 is good for, but I guess it's not closed-loop multibody...

Did you specify Library={"ModelicaExternalC"} in your function?

Note that reinit() has to be applied to a state variable, so you would need der(broken) somewhere even if it is a real.

CPPFLAGS = Flags for the preprocessor (c and c++)
CFLAGS = Flags for the C-compiler (c to o)
CXXFLAGS = Flags for the C++-compiler (cpp to o)
LDFLAGS = Only link-time flags

Since we use compilers that have the same C and C++ flags, we link them to be the same. Some LDFLAGS (-lmyLib) in CFLAGS should make the linking fail while others (-LlibPath) would succeed but should not be there anyway

That belongs to CPPFLAGS, not CXXFLAGS. Not that OpenModelica respects CPPFLAGS...

Make your configure CXXFLAGS into CFLAGS or everything will not be found.

Cannot be. The configure-script doesn't touch CXXFLAGS anywhere. What's your "./config.status --config"? And what does @CXXFLAGS@ resolve to for you?

Yes, so you cannot compile the python interface

It is possible with --disable-python-interface. I'll see if I can make it disabled by default if no CORBA implementation was given

Then you have a messed up omc or merged header, Try;

svn revert Compiler/OpenModelicaBootstrappingHeader.h

rm build/bin/omc # or make clean

make -j7 omc

How you keep getting p1=p2=0.0 I do not know (since I get the correct values).

But if you do not want the call evaluated during flattening, you need to tell the compiler that it is impure, because all functions are assumed to be pure.

annotation(__OpenModelica_Impure=true) in the function should do the trick.

beta3 was released. And beta4 was supposed to be released a few months before the release... In my opinion the language in the document needs to be quite heavily revised. I also do not know about any plans to support FMI 2.0 although it should not be that hard to add since most of the additions are optional. Supporting tunable parameters is trivial: just export all of them non-tunable

Of course I generate an empty array and it seems to work just fine. I think I would need the code of the functions you removed to see what's wrong.

I'll see if I can reproduce it

Look into the FMI 2.0 beta specification, which includes "tunable" parameters. It is not yet released and OpenModelica does not support it.

This work was the start of that, but I believe it is on hold. Instead we are working on a new flattening of Modelica models that will keep as much structure as possible intact.

Anyway, the expansion is only a problem for binding equation. By using real equations, the code is efficient.

model Bad

 constant Integer sz=10;

 function fcall

   input Real r;

   output Real[sz] o = fill(r,sz);

 end fcall;

 parameter Real p = 1.5;

 Real x[sz];

equation

 x = fcall(p);

end Bad;

Are you sure? I get:

class DAE05

  Real x(start = 0.9);

  Real y;

  parameter Real p.p1 = 1.0;

  parameter Real p.p2 = 2.0;

equation

  der(y) + (1.0 + p.p1 * sin(y)) * der(x) = sin(time);

  x - y = exp((-p.p2) * x) * cos(y);

end DAE05;

Using the first one (since your C-code did not match up to the second one). Make sure you have recompiled your o-file to match the C interface and not using some old file you forgot to recompile.
Or use Library="xxx.c" instead of .o to always recompile the library.

You're probably using non-UTF8 strings in your model. Upgrade to the latest OpenModelica and let it tell you where this happened (I'm assuming you're using an old omc anyway).

The executable should output some diagnostics saying a non-linear system could not be solved, or some assertion was triggered, or the numerical solver failed to solve the system, etc, etc.