As far as I know, the Ideal Diode is not really working in OpenModelica (gives wrong results)...

http://openmodelica.org/svn/OpenModelic … cation.idl
http://openmodelica.org/svn/OpenModelic … icator.cpp
http://openmodelica.org/svn/OpenModelic … CProxy.cpp
http://openmodelica.org/svn/OpenModelic … icator.cpp

User: anonymous
Password: none (4 letters)

Client-Server is faster if you need a state in the session. It is also a bit faster since you do not need to load the standard library over and over. Using command-line invocation you can read script results from file, and it should be possible to parse the output.

rml 2.3.8 is too old; use the subversion release (no tarball is available as far as I know)

I created a bug report for this: http://openmodelica.org:8080/cb/issue/1537

Look in the file ModelicaBuiltin.mo if you want to write to file from OMShell:

function writeFile

  "Write the data to file. Returns true on success."

  input String fileName;

  input String data;

  output Boolean success;

external "builtin";

end writeFile;

Or use the Modelica Standard Library: Modelica.Utilities.Streams.print(string,filename)

Or do you mean how to read the result-file? You could just use simulate(..., outputFormat="csv") and read the data back in most tools...

The problem is:
http://openmodelica.org:8080/cb/issue/1534 and http://openmodelica.org:8080/cb/issue/1535

Yes, it should be possible to do. Look into the C++ sources on how to start OMC in server mode. Use whatever C# CORBA implementation you fancy and things should work rather smoothly.

I cannot help with the MDT issues, but the help() command was fixed in the stable and nightly branches (not release; no one found that bug in 6 months of testing).

Ok, I got it

str := "

model TrivialLookupTable 

  Modelica.Blocks.Tables.CombiTable1Ds t(table = [-10,20;0,0;10,10], columns = {2}); 

equation 

  t.u = time;

end TrivialLookupTable;

";

loadString(str);getErrorString();



simulate(TrivialLookupTable,startTime=-15,stopTime=15,method="euler",numberOfIntervals=12);

arr:=-15:2.5:15;

val(t.y[1], arr);getErrorString();

Now gives:

time: {-15.0,-12.5,-10.0,-7.5,-5.0,-2.5,0.0,2.5,5.0,7.5,10.0,12.5,15.0}

t.y[1]: {30.0,25.0,20.0,15.0,10.0,5.0,0.0,2.5,5.0,7.5,10.0,12.5,15.0}

Which I believe is correct

Updated it again

That key should be correct. I have added the fingerprint to the webpage as suggested. Also included here for reference:

$ gpg openmodelica.asc 

pub  2048R/64970947 2010-06-22 OpenModelica Build System <build@openmodelica.org>

sub  2048R/E4012527 2010-06-22

Note that you do not need to import it to your own gpg. It should be imported to /etc/apt/trusted.gpg (which is what apt-key does). Use apt-key list to verify that it is there.

No really good workaround yet. Also see https://openmodelica.org:8443/cb/issue/1499 , which is the same as this bug

(Actually, just passing the array is working in the trunk; it's only passing array dimensions that is a problem. The latest Windows nightly build is probably too old though)

You can use alien on the deb-packages if you like handling dependencies yourself

Using the MATLAB clone GNU Octave:

octave:1> load A_res.mat

octave:2> who

Variables in the current scope:



Aclass       dataInfo     data_2       name

ans          data_1       description

Aclass describes the format (if it is transposed matrices or not)

octave:3> Aclass

Aclass =



Atrajectory

1.1        

           

binTrans 

octave:6> dataInfo

dataInfo =



   2   2   2

   1   2  -2

   0   0   0

  -1  -1  -1

The dataInfo is Nx4. Each variable has 4 fields.
1) Part of matrix data_N where N is the value of the variable
2) Index in this matrix (negative indices means it is a negative alias of that index)
3) and 4) are unused by OpenModelica. Handles interpolation and stuff in Dymola I believe

octave:9> name'

ans =



time

x

y

In OpenModelica we transpose this matrix for some reason The order of the names (and description) matrices are the same as dataInfo.

So to get all y-values:

-data_2(2,:)

I think this is fixed in r8845, but I am unsure exactly how the combi-tables should work. I changed the extrapolation method to base the value on first/last two values of the array when the value is out of range.

Not created in a local scope (i.e. inside a function-call).

Yes, constructor/deconstructor is called properly when defined as top-level variables of a simulation.
External Objects work fine for non-array inputs and without any weird call mapping (like trying to send constant expressions...).

No, we don't support it properly.
I could alias it to false if you need the code to run (but still not generate the event). I'm adding a ticket here: http://openmodelica.org:8080/cb/issue/1 … ation=true

You can also work around this bug by adding "#define terminal() 0" to OPENMODELICAHOME/include/omc/modelica.h

Oh yea... The code I tested was:

model M

  function fn

    input String str;

    output Integer i;

  external "C" i=puts(str);

  end fn;

  Real x;

equation

  x = fn(String(time) + " ab\nc");

end M;

It depends what version of OMC you are using. Older versions of OMC would output \\n in some cases and \n in others (a bit arbitrarily).

As far as I know, putting a newline character in the Modelica string, i.e.

String str = "ab

c"; 

works for all OMC versions. If you found a certain way (read:bug) in which OMC 1.7 does not translate \n, post it and it will be fixed.

I believe we are talking about months for flattening (next release / Christmas is my guess)

That I cannot help with since I do not use SimulationX. Maybe someone else knows it though...

Use each to set each parameter in an array of components. Use for-equations to connect multiple components.

class A

  connector C

    parameter Real x;

    Real o;

  end C;

  parameter Integer n = 25;

  C cs[n](each x = 1.5);

equation

  cs[1].o = 1;

  for i in 1:n-1 loop

    connect(cs[i],cs[i+1]);

  end for;

end A;

You are running the mos-script with +showErrorMessages, which will print anything added to the error buffer as soon as it can.
This is only really useful when debugging the compiler itself since these error-messages will be rolled back during the normal course of the compiler (it will try to perform an action just to see if it can). I believe the flag will also cause getErrorString() to always return the empty string

The bug tracker is a good place to upload models that you want to be better tested: http://openmodelica.org:8080/cb/proj/tr … cker_id=1.
As for how well tested the releases are: Most releases have a testsuite trace attached to them (for example: http://build.openmodelica.org/omc/build … race.txt). You can also see status of the nightly builds: http://build.openmodelica.org/omc/build … 4-ubuntu/.

This is related to a task needed to handle Modelica.Media: http://openmodelica.org:8080/cb/issue/1334

You can try fn1, fn2 and fn3 yourself if you want to see smaller examples that show what OMC does not yet handle

model M

  function fn1

    output Real r;

  external "C" r = sin(c1+c3);

  end fn1;



  function fn2

    output Real r := sin(c1+c3);

  end fn2;



  function fn3

    output Real r;

  algorithm

    r := sin(c1+c3);

  end fn3;

  constant Real c1 = 1.0;

  constant Real c2 = fn1();

  constant Real c3 = c1+1.0;

end M;

(The problem is that the constants are not instantiated in the correct order, so the type of the expression becomes unknown...)

I am not familiar with SimulationX, but it sounds like you either need to change a

tolerance

or

stepsize

parameter to the simulation. Doing so will allow the solver to take smaller steps (increasing total simulation time) or accept larger numerical errors.

Depending on the model, you could also try to reduce the number of events and zero-crossings by using the noEvent operator in strategic places.

Thanks for the bug. The stable/release versions of OpenModelica are built on Debian, which uses a different C++-compiler I will fix this for the 1.7.0 release.
If you want to use OpenModelica sooner than that, consider using the nightly-ubuntu package as a workaround.

Yes. Adrian Pop noticed this problem on Monday this week, so I am assuming he is working on it. Of course, I am certain there are more issues with the model anyway

The offending code is:

  redeclare replaceable function extends getMolarMass 

  external "C" MM=  TwoPhaseMedium_getMolarMass_(mediumName, libraryName, substanceName) 

    annotation(Include="#include \"externalmedialib.h\"", Library="ExternalMediaLib");

  end getMolarMass;

We don't (yet) support external declarations when doing class extends

ClassLoader.loadClassFromMp failed means nothing. In fact, loading the classes probably succeeded.

Note that OpenModelica does not yet support Modelica.Media however:

Error processing file: Example.mo

[./ExternalMedia/Interfaces/PartialExternalTwoPhaseMedium.mo:17:3-31:24:writable] Error: Class getMolarMass not found in scope ExternalMedia.Media.TestMedium (looking for a function or record).

[./ExternalMedia/Interfaces/PartialExternalTwoPhaseMedium.mo:17:3-31:24:writable] Error: Looking for a function FluidConstants but found a RECORD.

[/usr/lib/omlibrary/msl31//Modelica/Media/package.mo:5527:3-5527:75:readonly] Error: Failed to elaborate expression: {externalFluidConstants}

Error: Failed to elaborate expression: {externalFluidConstants}

[./ExternalMedia/Interfaces/PartialExternalTwoPhaseMedium.mo:17:3-31:24:writable] Error: Class getMolarMass not found in scope ExternalMedia.Media.TestMedium (looking for a function or record).

[./ExternalMedia/Interfaces/PartialExternalTwoPhaseMedium.mo:17:3-31:24:writable] Error: Looking for a function FluidConstants but found a RECORD.

[/usr/lib/omlibrary/msl31//Modelica/Media/package.mo:5527:3-5527:75:readonly] Error: Failed to elaborate expression: {externalFluidConstants}

Error: Failed to elaborate expression: {externalFluidConstants}

[Example.mo:2:3-2:58:writable] Error: Class ExternalMedia.Media.TestMedium.ThermodynamicState not found in scope Example while instantiating state.

With +d=scodeFlatten (experimental Modelica.Media flag):

$ OPENMODELICALIBRARY=/usr/lib/omlibrary/msl31/:. omc +d=scodeFlatten Example.mo ExternalMedia Modelica.Media 

/home/marsj/dev/trunk/build//bin/omc 1.7.0 (r8597)

Error processing file: Example.mo

[Example.mo:3:3-3:15:writable] Error: Class SI.Density not found in scope Example.

When fixing that, it still fails at the previous error, however...

In r8597+ it should also work with any vectorization limit:

size 3: +v=1

  real_array_create(&tmp1018, ((modelica_real*)&($Pelement$lB2$rB$Pprofile$Palpha)), 1, 3);

size 3: +v=100

  array_alloc_scalar_real_array(&tmp1018, 3, (modelica_real)$Pelement$lB2$rB$Pprofile$Palpha$lB1$rB, (modelica_real)$Pelement$lB2$rB$Pprofile$Palpha$lB2$rB, (modelica_real)$Pelement$lB2$rB$Pprofile$Palpha$lB3$rB);

The generated code should be faster with a lower limit since we just use a reference to the array instead of creating a new one...

I will have a look at this bug. Note that this is related to the vectorization limit of OpenModelica.
As a workaround, you can run

omc +v=100

, or setVectorizationLimit(100) in OMShell or OMEdit. But this may have a negative impact on the performance of large models.

I had OMOptim compile using:
Ubuntu 64-bit (GCC 4.4, Qt 4.7.0)
MacPorts 64-bit (GCC 4.2, Qt 4.7.2)

Since mine works, I tried GCC 4.6 (which I also happen to have installed).

../GUI/Widgets/WidgetMooPointsList.cpp:63:100: error: cannot call constructor 'QSizePolicy::QSizePolicy' directly [-fpermissive]

I wonder why GCC 4.4 accepts Class::Class for the constructor, and GCC 4.6 does not

-    _listPoints->setSizePolicy(QSizePolicy::QSizePolicy(QSizePolicy::Maximum,QSizePolicy::Preferred));

+    _listPoints->setSizePolicy(QSizePolicy(QSizePolicy::Maximum,QSizePolicy::Preferred));

I'm not really sure what the question it, but certainly when-equations may cause a state variable der(x) to also appear as reinit(x, ...). However, if a variable is selected as a state, it is always solved as a state in OpenModelica (which means no equation can contain x on the left handside; right handside I am not sure of though).

Yes, it seems OMEdit could not reliably create functions. I have changed it to no longer do type-checking of functions (in r8534).

It sounds like you are trying to use OMShell or maybe OMNotebook to pass classes to the compiler. If you do so, you need to pass all functions at the same time because some type-checking is done if I recall correctly. Otherwise I would need to see some sample code.

Thanks. I guess it would have been fix if you had OPENMODELICAHOME unset (this is what the Ubuntu builds use, so I don't test OPENMODELICAHOME as heavily as I used to).

But this should be fixed now.

Either try r8493 (where the OPENMODELICAHOME from the configure script is used). Or launch the process as OPENMODELICAHOME=/path/to/trunk/build OMOptim.
At least I am guessing this is your issue. If you still have problems, just post them here and I will try to respond.

But thanks for the bug-report. I will see if I can resolve this tomorrow.

I would guess OMOptim does not null-terminate the name of the expected file (trailing garbage digits). Regardless, OMOptim on Linux can only be used to try out the GUI right now. Launching simulations (and thus doing optimizations based on simulation results) sadly uses WIN32 API.

You can use the stable packages for 10.04 as they also work with 10.10. The additional things included in Qt 4.7 are minimal.

As for the solver... I have no clue, and that's why I hate DASSL. Euler and RK worked, but I don't know if the result was correct or not.

Yes. A reinstall in a bit over an hour from now should solve it. I would suggest using the stable builds in classes though (as the nightly builds break from time to time).

This would have been fixed in the trunk yesterday, but someone broke compilation of OMEdit

Anyway, it should be solved with today's build around 14:00 CEST for your system (I'm just assuming no one will break the builds on a Saturday).

Does the following do what you want?

class A

  Real x = 2-8*time;

  Real y = 1+time^2-time;

  Real ratio = abs(if noEvent(abs(x)>abs(y)) then y/x else x/y);

end A;

The other features, I'm not sure. But if you file a bug they might be solved Open some extra ones about drag&drop of custom components, and send Adeel a few extra emails. It seems to be a quite popular feature to still be missing.

String-comments are as such:

class A "class-comment"

  Real r = 1.2 "var-comment" annotation(stuff noone cares about);

algorithm

  x := 1.3 "cmt";

...

end A;

And with a long way off, I mean the oldest bug we have among the new bugs (post-bugzilla) is https://openmodelica.org:8443/cb/issue/ … tion=true. The very same thing you want now Who knows though. Maybe the master's student working on the issue this time will actually solve it.

The bug tracker isn't working? It is for me ( https://openmodelica.org:8443/cb/proj/t … acker_id=1 ), but maybe that's because I have a separate account there...

As for comments... String-comments are preserved, but line-comments (//) and block-comments (/* ... */) are not. This is due to the architecture used by OMEdit to communicate with OMC. That's also why indentation is not preserved in the models. Some work being done to resolve these issues, but I think it's a long way off still.

I don't think

when sample(0, 1) then 

  A =  if sample(0, 1) then TRUE else FALSE; 

end when; 

is very well defined due to numerics being involved (they are separate zero-crossings and they might actually be triggered during different time steps). It's an interesting example though...

Or actually, I should probably check if libf2c.a is only part of the -dev package... Might be my bad as usual

Package: omc

Section: math

Architecture: any

Depends: ..., libf2c2, ...

Didn't the package install libf2c for you?

It's enough to point out /usr/bin/omc as the OMC executable. But otherwise environment variables are the way to go.
The debugging is for MetaModelica only, not Modelica.

Well, I update the stable branch every few weeks. All I need to do is check that the clients work, and update a text-file...

build@build:~$ cat debian-control-files/stable

8226

The r???? is the only flaw in the latest release I think. Mainly because that was a new feature added around that time.

svn blames Adrian. Anyway, this will be fixed in the next nightly build (between 11 and 15 CEST depending on what repository you use).

I get the same error now, it seems. Wonder who changed OMNotebook most recently

You will need r8370+ of OpenModelica for this option

Anyway, it might be possible to fix this problem by adding -lcurses or -lncurses. I'd just need some time to find the correct way to do this in autoconf.

So that means -lreadline doesn't work on your system, but at least the headers are there.

It's (now) possible to ./configure --disable-omshell-terminal if you don't care about that OpenModelica client (it's the only one using readline).
Otherwise, I'm sure Slackware has some method of displaying what files were part of which packages. My guess is this is called -lreadline6 or something.

The following might give a better error message as to why readline won't link...

$ echo "int main() {}" > a.c && gcc -lreadline a.c

The following is used by the autoconf:

AC_CHECK_HEADER(readline/readline.h,,AC_MSG_ERROR([readline missing]))
AC_CHECK_HEADER(readline/history.h,,AC_MSG_ERROR([readline missing]))
AC_SEARCH_LIBS(readline,readline,,[AC_MSG_ERROR([readline missing])])

What locations are used by these headers in Slackware? If it's /usr/include/readline.h, we have a slight problem

They should be, but I think Media support is higher on the list and will take some time to implement.

With revision 8329, this now compiles even if the functions are non-static (no more linker problems due to multiple copies of the functions).

Note that included C-code will still be compiled using g++ and as such it is subject to more checks than in Dymola and SimulationX (void* for example from malloc needs to be explicitly cast to the correct type).

Actually, OpenModelica does accept #include syntax. However, you need to make sure that the c-file is in a directory searched by the compiler (which directory this is, is not specified by the MLS 3.1; for Windows OpenModelica, just put the file in OPENMODELICAHOME/include/omc).

It's a problem with flattening (compiler crashes even when trying to get the Icon annotations)

OpenModelica does ship Modelica.Media, but it's not 100% working so OMEdit disables it.

Actually, in the latest trunk only method = "dasslold" works with OMI. After Parham updates OMI to use the new solver inferface, "euler" and "rungekutta" should also work fine.

As far as I know, people unset TMPDIR to run MDT on OSX. OMNotebook also has issues on OSX (crashes if you open too large books).

Writing a patch to the MDT plugin to look in the system-wide temp-directory instead of assuming it is /tmp.

And the final key to the puzzle is:
OMShell, OMNotebook and OMEdit all call the command "cd("TMPDIR/OMEdit/")" or similar after startup. Because when you start a .app in OSX, the working directory is not writable.

I would not trust the simulate() command when it tells you g++ or Compile is not found (the checkSettings() command is more trustworthy).

One of these days I should make the scripts do the updates in a tmp-directory and then move the files so this doesn't happen
Just update again and it should be fine

http://openmodelica.org/svn/OpenModelic … .Linux.txt
User: anonymous
Password: none

Compiling rml-mmc is the most painful of the dependencies. I'd suggest looking in http://build.openmodelica.org/apt/pool/ … ian.tar.gz for hints on how to compile that.

You forgot to use the command

loadModel(Modelica)

This is working in r8102+

I really do hope the replacement plot widget is completed soon
Anyway, after calling plot(), all subsequent system() calls fail due to:

ERROR: system(OPENMODELICAHOME=\"$OPENMODELICAHOME\" /opt/openmodelica/share/omc/scripts/Compile Modelica.Electrical.Analog.Examples.CharacteristicThyristors ) failed: Interrupted system call

The workaround is to start $PREFIX/bin/OMPlotWindow before running the plot-command in omc.

The bug report is here: https://openmodelica.org:8443/cb/issue/1444
I might have a look in the weekend (work=Linux; home=iMac).

OMEdit has never handled MSL 2.2, so older versions of OM would not help. I'd suggest using OMShell instead of OMEdit.

Well, the current OMC kernel handles it just fine. For example, if you use OMShell, you can use (modify for Windows paths; these are Mac ones):

setEnvironmentVar("OPENMODELICALIBRARY","/opt/openmodelica/lib/omlibrary/msl221");

loadModel(Modelica);

You can fool OMEdit into using MSL 2.2 by settings the same env.var:

OPENMODELICALIBRARY=/opt/openmodelica/lib/omlibrary/msl221 open -a /Applications/MacPorts/OMEdit.app

But OMEdit doesn't handle Modelica2 annotations, and crashes (because it fails at sanitizing returned data).

Oh yea, I forgot to mention it uses MSL 2.2. OMEdit uses MSL 3.1 by default, which is not compatible.

It sounds like you are using Windows. Doesn't the application install the OMShell shortcut? Anyway, the model seems to run, but I guess there is some problem with initialization because the following commands gave a life expectancy of 0.0 for all values.

loadModel(Modelica);

loadFile("SystemDynamics.mo");

getClassNamesRecursive(SystemDynamics);

res:=simulate(SystemDynamics.WorldDynamics.World3.Life_Expectancy,

    startTime=1900,stopTime=2200,outputFormat="mat");

s:=res.resultFile;

readSimulationResultVars(s);getErrorString();

1900;val(life_expectancy,1900);getErrorString();

1950;val(life_expectancy,1950);getErrorString();

1990;val(population,1990);getErrorString();

2000;val(life_expectancy,2000);getErrorString();

2010;val(life_expectancy,2010);getErrorString();

Well, since Modelica is balanced you must not change the number of equations in a system, or it cannot be simulated.
The main difference between if-statement and if-expression is that you can use things like assertions in statements.

In OpenModelica, a statement like

if cond then

  a = b;

else

  d = e;

end if;

is converted into

0 = if cond then a-b else d-e;

If you really need to have a different number of equations, make the condition a parameter. That way you specify that the number of equations cannot change during the simulation.

No, it's suggesting using if-expressions instead of if-statements (and then showing the old if-statement). It failed when trying to rewrite the statement to if-expressions; our backend cannot actually handle statements.

Anyway, I believe the problem is that you have a mismatch in the number of equations in the if-equations. This is only allowed if the condition expression is parameter (?) or constant because then the statement can be optimized to be only one branch.

Use --with-omniORB or --with-omniORB=/usr
=usr will look in the current working directory

$ unset OPENMODELICAHOME && cat a.mo && cat a.mos && /opt/local/bin/omc a.mos 

class A

  Real x;

equation

  der(x) = time;

end A;

loadFile("a.mo");

simulate(A);

plot(x);

true

record SimulationResult

    resultFile = "A_res.plt",

    simulationOptions = "startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-06, method = 'dassl', fileNamePrefix = 'A', storeInTemp = false, noClean = false, options = '', outputFormat = 'plt'",

    messages = "",

    timeFrontend = 0.004679566,

    timeBackend = 0.000658616,

    timeSimCode = 0.001480352,

    timeTemplates = 0.001502038,

    timeCompile = 0.770774324,

    timeSimulation = 0.017465982,

    timeTotal = 0.796675502

end SimulationResult;

true

The following shows the evil little OMPlotWindow. What tool are you using? MDT?

Well, I don't see any variable called x in your model. Looking through the API it also does not seem like it is possible to query the compiler for names that are available in the result-file. This should probably be enhanced

It seems MDT won't look in the TEMPDIR or TMPDIR folder, whatever it was on OSX
You could try unsetting that env.var before starting eclipse, or ask Adrian to fix the bug.

First of all, you cannot simulate a package. Second, you need to use
loadModel(Modelica)
loadModel(ModelicaAdditions)

Note that not all models in ModelicaAdditions work with MSL 3.1 and that some do not use valid Modelica code.

Well, it doesn't parse so look for parse errors.


simulate(BouncingBall, start=0, end=5s);

5s is not a Modelica token.

The only way I could think of was the following, but it won't work because you may only inherit from one class of type restriction.

class A

  type E1 = enumeration(a,b,c);

  type E2 = enumeration(d,e,f);

  type F

    extends E1;

    extends E2;

  end F;

  F f;

end A;

The following does flatten,  but won't produce correct code:

class A

  class E1 = enumeration(a,b,c);

  class E2 = enumeration(d,e,f);

  class F

    extends E1;

    extends E2;

  end F;

  F f;

end A;

Also, there is an undocumented vendor-specific annotation:

annotation(__OpenModelica_Impure = true)

that you can add to a function to force OMC to not consider a function call constant

Start OMC in a terminal and let OMShell/OMEdit resume the session; then view the output in that terminal. OMEdit launches omc with Qt calls, which disable stdout.

Works for me.

$ cat a.mos ; omc a.mos

loadFile("a.mo");

loadModel(Modelica);

testRandom1({23,35,75});getErrorString();

/home/marsj/dev/trunk/build//bin/omc 1.6.0

true

true

x = 0.7490418042138446

x = 0.8643095911627987

x = 0.4815900479477273

x = 0.07248000599078153

x = 0.6682546425212224

x = 0.2268866442874202

x = 0.6882514204208467

x = 0.06556030683102243

x = 0.1382381189319646

x = 0.4670802318116736

0.467080231811674

""

How are you trying to use the function? And from what client? If you are using OMShell/OMEdit, do note that it will only display stdout from functions that are called during simulation.
Since you called the function using constant input, it would be evaluated before the simulation starts (because in Modelica a function may not have side-effects like printing to standard output ). You could try using a non-constant input or annotation(__OpenModelica_Impure = true) to defer evaluation of the function to runtime.

OpenModelica is not really used to plot data although it has basic plotting functionality. Whenever I need best fit or something similar, I export my OpenModelica simulation results, postprocess them in Python and plot using gnuplot.

At the moment I believe most users have their own Fluid libraries that do work with OpenModelica. I'm not a modeler so I don't know if there are free ones out there (that are good enough).

We are working on supporting Fluid in the future. It will just take some time since part of the compiler needs to be redesigned in order to handle Modelica.Media. As far as I could tell, jmodelica.org does not support Fluid/Media either. And as far as I know there are no other free compilers that would be close to being able to handle Media either.

My OMEdit actually contains all expected classes:
Note that OpenModelica does not support full MSL 3.2 yet. For example operator overloading required to get ComplexBlocks/ComplexMath running. OMEdit will crash if you try to access some of these.

If you open the OMC logger in OMEdit you will see that during startup deleteClass(Modelica.Media), deleteClass(Modelica.Fluid) is called. This is because Fluid/Media is not working in OpenModelica (the OpenModelica kernel will crash or hang if you click any of the tabs, so they were removed). ComplexBlocks/Math was not removed because the installer does not ship with MSL 3.2 by default.

Resources is not a Modelica package; it's simply referenced by the standard library.

Why do you need to add the include? It really is quite unnecessary in OpenModelica (except to check if your external function is defined differently from the way OpenModelica assumes it is).
IncludeDirectory and LibraryDirectory are Modelica 3.2-specific (which we have not implemented). In fact, modelica:// is not present anywhere in our source code.

Our test case, using a really stupid client: https://openmodelica.org/svn/OpenModeli … imulation/
Chapter 5 of the manual: https://openmodelica.org/svn/OpenModeli … sGuide.pdf
The sample client provided by the original developer: https://openmodelica.org/svn/OpenModeli … pleClient/

User: anonymous
Password: none (4 letters)

http://openmodelica.org:8080/cb/issue/1 … ation=true

You skipped the only interesting part of the error message: what does gcc say comes after residualFunc38(...):?

No, the interactive simulation is a socket-based client that communicates with the simulation.
Basically sending:

doStep()

doStep()

doStep()

changeParameter(i,100)

I'm not that familiar with it, but it should be in the documentation and sample code in https://openmodelica.org/svn/OpenModeli … teractive/

Parameters are stored in RAM. It is only possible to change them if you make an interactive simulation.

Structural parameters are special in Modelica. That is, parameters that define if-conditions or array dimensions do not always work as expected.
Sadly, the compiler does not register which parameters it thinks are structural. So trying to do a parameter sweep is sometimes a bit hard.

It is often possible to start with compiling a model that has a larger input array than you need, and then changing the parameter to something lower. This way OpenModelica will allocate more than enough memory for your array.

It is somewhat possible. You need to link in the simulation runtime though; it includes a main() function, but I do believe it is possible to write your own entry function.
The script Compile.bat sets all environment variables you need and calls make.exe on the $ModelName$.makefile. It is possible to set this in your program and call g++ with dynamic linking options.

The sequence is random. You need to parse the file to realize what line to update.

This seems to be the same problem as this bug (if you want to follow it): http://openmodelica.org:8080/cb/issue/1390

I am assuming it has to do with bug #1401, which I reported today: http://openmodelica.org:8080/cb/issue/1 … ation=true
Basically, the backend fails to evaluate functions that are known to be constant after some symbolic transformations. The backend continues anyway and solves this with a non-linear solver I believe, but I'm not certain.

Error: Could not evaluate expression: Modelica.Mechanics.MultiBody.Frames.TransformationMatrices.from_nxy(...

You're out of luck.

From Peter Fritzson's book (8.5 Partial Differential Equations):
This section describes a generalized in operator that at the time of this writing is not yet formally accepted in the Modelica language specification

From the Modelica 3.2 specification (Preface):
There are no language elements to describe directly partial differential equations, although some types of discretized partial differential equations can be reasonably defined, e.g., based on the finite volume method and there are Modelica libraries to import results of finite-element programs.

It's in your $OPENMODELICAHOME/lib/omlibrary/msl31/ModelicaServices/ I believe. You could also type list(ModelicaServices) in the OMEdit logger.

Or view it online here:
https://openmodelica.org/svn/OpenModeli … package.mo
User: anonymous
Password: none (4 letters)

Does list(Modelica.Constants) give you any output? I suspect the Modelica library is not loaded; try running:

loadModel(Modelica);

simulate(...);

This problem was fixed yesterday, but OMNotebook will not work correctly anyway due to problems with more recent Qt versions (one of the custom widget containers causes an infinite number of events to trigger if the Notebook is larger than a few cells, so OMNotebook is unusable on Mac).

Well, the main difference is that MDT is also used for OMC development, which requires +g=MetaModelica for code completion. +g=Modelica makes it the same as OMShell (minus some OMShell specific features like tab-completion of commands like simulate(), if MDT doesn't have that).

I'm a bit unsure of the status of all simulations as I don't work on the backend of OpenModelica, but you can check the last update from Jens, which suggests that indeed no examples with closed loops simulate with correct results yet:
https://www.openmodelica.org/svn/OpenMo … e/Makefile

User: anonymous
Password: none (4 letters)

Are you using MDT? If so you might have to switch to Modelica grammar instead of MetaModelica.

Yes, that's the message you get if you install the Debian packages. If you install the Ubuntu packages, OMEdit should just refuse to start due to an old Qt version.

Ah. I should have looked a bit closer. The LTS is too old for OMEdit (run it from command-line and it should say some symbols are missing; it's due to a too old Qt version).

If you start it from command-line, you should see that you installed the Debian packages. Debian does not have Qt 4.7, so the application is just a placeholder. Use nightly-ubuntu for OMEdit.

I believe that you also need +s to invoke the backend.

That's a syntax error because your are trying to use a command-line command from OMShell. Use bash, sh, tcsh or a similar terminal instead.

This is fixed in r7508. From your user agent, you seem to be using Windows so you need to wait until Adrian makes a new OpenModelica build.

$ ./test -v

 jac flag set : 0

read start = 0 from init file.

read stop = 5e-14 from init file.

read stepSize = 1e-16 from init file.

read tolerance = 1e-06 from init file.

read method = dassl2 from init file.

read outputFormat = plt from init file.

read $dummy = 0 from init file.

read der($dummy) = 0 from init file.

read a = 2 from init file.

read b = 2 from init file.

Read parameter data from file test_init.txt

Notice: Calculated time of sample events is not yet used!

Number of sorted, unique sample events: 0

initDelay called with startTime = 0.000000

Allocated simulation result data storage for method 'plt' and file='test_res.plt'

Recognized solver: dassl2.

Calculated bound parameters

Initialization by method: simplex

fixed attribute for states:

$dummy(fixed=true)

number of non-fixed variables: 0

No initial values to calculate

Save ZeroCrossings

**Calling DDASRT the first time...

**Calling DDASRT from 0 to 2.22045e-13...

**Deleting work arrays after last DDASRT call...

Save ZeroCrossings

Performed initial value calculation.

Start numerical solver from 2.22045e-13 to 5e-14

    *** Statistics ***

Events: 0

State Events: 0

Sample Events: 0

The problem is in the initialization we do, apparently:
Start numerical solver from 2.22045e-13 to 5e-14. The "small" step we take to initialize derivatives is not so small for you. In fact, it's as big as 2000 of your time steps, and it's supposed to be in the order of 1e-9 of a time step. Might be a bug; I'll try to fix it.

OMEdit depends on Qt 4.7

This is all because the arrays whose sizes are being determined by the initialization process are actually part of solving the initialization problem.
It should be possible to use a fixed=false parameter in an initial equation in OpenModelica with the following caveat: You need to make sure that when doing buildModel, you have the largest number of elements in your matrix because this is the size that will be allocated (so if you want to scan 8x1, 4x4, 3x5, you need to use buildModel and evaluate 4x4; then it should be possible to change the init-file or use some other method to change parameter values during runtime). You might get terribly weird results if you do this wrong though, so it's not recommended (structural parameters are more like constants than parameters).

class A

  Real c = 0.2;

  Real x = (1-c)*sin(x) + c*cos(x);

end A;

-or-

class A

  parameter Real c = 0.2;

  Real x = (1-c)*sin(x) + c*cos(x);

end A;

The first example solves the equation in each time step (using the previous value as an initial guess, so it basically only verifies that the equation is solved in all time steps except the first). It uses Powell's Hybrid method.

The second examples solves the non-linear equation during initialization. The default initialization method uses simplex.

Note that a Modelica tool is free to choose any algorithm it wants to solve an equation system, and tool-specific tweaks need to be used if you need to change the defaults

I have created a bug for this in http://openmodelica.ida.liu.se:8080/cb/issue/1370.

The answer I got from one of the OMEdit developers was that it is currently not supported. The TODO-list is quite long so I don't know when it will be added.

You could also use the release version instead of stable or nightly. That's the actual 1.5.0 release.

Installing the packages manually now works (instead of the bigger openmodelica package). I will update the stable version number when all distributions compile (should be in ~26 hours). Then apt-get install openmodelica should also work (omedit referenced a now deleted package; omedit does not run on Debian because it lacks Qt4.7 anyway....)

$ apt-get install omc omlibrary-msl31 omnotebook omshell omshell-terminal

Reading package lists...

Building dependency tree...

Reading state information...

The following extra packages will be installed:

  drcontrol drmodelica libgl1-mesa-dev libglu1-mesa-dev libomniorb4-1

  libomnithread3c2 libphonon4 libpthread-stubs0 libpthread-stubs0-dev

  libpulse-mainloop-glib0 libqt4-assistant libqt4-dev libqt4-help

  libqt4-multimedia libqt4-opengl libqt4-opengl-dev libqt4-scripttools

  libqt4-svg libqt4-test libqt4-webkit libqt4-xmlpatterns libx11-dev

  libxau-dev libxcb1-dev libxdmcp-dev mesa-common-dev qt4-qmake

  x11proto-core-dev x11proto-input-dev x11proto-kb-dev xtrans-dev

Suggested packages:

  qt4-dev-tools qt4-doc libmysqlclient-dev libsqlite0-dev libsqlite3-dev

  libpq-dev unixodbc-dev firebird2.1-dev

The following NEW packages will be installed:

  drcontrol drmodelica libgl1-mesa-dev libglu1-mesa-dev libomniorb4-1

  libomnithread3c2 libphonon4 libpthread-stubs0 libpthread-stubs0-dev

  libpulse-mainloop-glib0 libqt4-assistant libqt4-dev libqt4-help

  libqt4-multimedia libqt4-opengl libqt4-opengl-dev libqt4-scripttools

  libqt4-svg libqt4-test libqt4-webkit libqt4-xmlpatterns libx11-dev

  libxau-dev libxcb1-dev libxdmcp-dev mesa-common-dev omc omlibrary-msl31

  omnotebook omshell omshell-terminal qt4-qmake x11proto-core-dev

  x11proto-input-dev x11proto-kb-dev xtrans-dev

0 upgraded, 36 newly installed, 0 to remove and 0 not upgraded.

Need to get 52.3 MB of archives.

After this operation, 135 MB of additional disk space will be used.

Do you want to continue [Y/n]?

I would need to know what OS and processor architecture you are using

I made the following diff. It seems to work rather fine (it starts at a size appropriate for a larger display but may be resized if the screen is too small). You might get scroll bars in the editing area though, as it becomes quite cramped there.
-    this->setMinimumSize(950, 670);
+    this->setGeometry(0, 0, 950, 670);
+    this->setMinimumSize(400, 300);

The new packages should be in <15 hours if all goes well.

dpkg --ignore-depends=package,... --install omeditXXX.deb

Short answer: When Debian Squeeze is actually released (for a recent enough Qt to build OMEdit). You could also try the Ubuntu repository, which already has it.

Yes, we are still working on supporting Modelica.Media, which the ThermoPower library uses. Small parts of Modelica.Media do work, but most likely not enough for ThermoPower.

As for modeling and libraries, I have no clue.

As far as I can tell, this is the signature used by Interactive.mo (only has 6 arguments):
Absyn.CREF(componentRef = class_)
Absyn.CREF(componentRef = comp_ref)
Absyn.ARRAY(arrayExp =  {Absyn.BOOL(value = finalPrefix), Absyn.BOOL(value = flowPrefix),  Absyn.BOOL(value = streamPrefix),  Absyn.BOOL(value = protected_), Absyn.BOOL(value = repl)})
Absyn.ARRAY(arrayExp = {Absyn.STRING(value = variability)})
Absyn.ARRAY(arrayExp = {Absyn.BOOL(value = dref1),Absyn.BOOL(value = dref2)})
Absyn.ARRAY(arrayExp = {Absyn.STRING(value = causality)})

Your eclipse might be setting an environment variable in its project settings.

However, if you have problems finding out where, you can always use:

>>> setEnvironmentVar("abc","def")

Ok

>>> getEnvironmentVar("abc")

def

The output of these API calls seems to be bad (should be true and "def"),  but it works.

I don't think that suits his requirements either (creating a 3+ GB file just to get the last 2 results is crazy anyway).

The method I listed does work from another application though. You just need to redirect stdout to a file and parse it. It's quite fast but might be difficult to maintain if OpenModelica output changes or if your simulation usually outputs dassl warnings, etc.

Nope, it's not needed; I will disable linking against it since it's something for future use (the Windows version builds its own sqlite3 and links to it statically which the linker optimizes away; the Linux developers are lazy and skip building it since sqlite3 already exists on their systems waiting to be dynamically linked).

Anyway, debhelper adds all the dependencies it can find; even if they are uselessly linked, like half the Qt dependencies

The Linux builds start at 11,12,13,14 CET, so tomorrow around 15:00 the new build should be up. After that I can mark a new stable build

I think the interactive client does what you want, but I have not tried it.
when terminal() does not work in OpenModelica so it can't be used either.

However, you can terminate the simulation and print any result you want:

$ omc +s a.mo

class A

  Real a = time;

equation

  when time >= 0.9999 then

  terminate("a");

  end when;

end A;

trunk marsj@marsj-laptop:~/tmp

$ make -f A.makefile 

g++ -I"/home/marsj/dev/trunk/build//include/omc" -march=native -mfpmath=sse  -I. -o A A.cpp A_functions.cpp   -lsim -L"/home/marsj/dev/trunk/build//lib/omc" -lc_runtime -lf2c -linteractive -lsendDataHumbug -lpthread 

trunk marsj@marsj-laptop:~/tmp

$ ./A

Simulation call terminate() at time 0.9999

Message : a



Simulation terminated at time 0.9999

This might suit your needs if you just want a quick and dirty solution

Aha... The dcmotor example is using MSL 2.2.1, not 3.2. Also, you will get errors if you try to use MSL 3.2 since we are still working on MSL 3.1 and they introduced many new language constructs in that version.

Oh yes, I forgot to add:
Use getErrorString() after loadModel(Modelica) to see if you got any lexer or parser errors...

You can verify what settings OMC thinks it is currently using through the command checkSettings()

You can use simulate(Name.Of.My.Model) to simulate any loaded class (using loadFile("file.mo") or loadModel(Modelica)). Or through command-line:
omc myModel.mo Modelica +i=Name.Of.My.Model

It is supported, but not tested very well in the testsuite (2 out of 1000+ testcases I believe).

As an example, the following is supported:
http://openmodelica.org/svn/OpenModelic … ngParam.mo
http://openmodelica.org/svn/OpenModelic … gParam.mos
http://openmodelica.org/svn/OpenModelic … aram.ext.c

(User: anonymous, Password: none)

If there are any issues you find with our external object implementation we would love some examples that currently fail so we can fix it and add more testcases.

Yes, sample() is a good idea if you need to make sure when your function is called. Sadly, it's a bit slow in OpenModelica.

Without sample(), an external function can be called several thousand times even in a single time step (if inside an algebraic loop).

There seems to be some other issues as well... import D = Modelica.Electrical.Digital; seems to leave some constants as D.xxx.yyy.zzz in the generated code.

It seems this is a code generation problem for enumerations (clock.y has type Logic = enumeration(
        'U' "U  Uninitialized",
        'X' "X  Forcing Unknown",
        '0' "0  Forcing 0",
        '1' "1  Forcing 1",
        'Z' "Z  High Impedance",
        'W' "W  Weak    Unknown",
        'L' "L  Weak    0",
        'H' "H  Weak    1",
        '-' "-  Don't care")).

Indeed, the installer requires Snow Leopard and a 64-bit Intel CPU. I'd recommend installing via macports since then you get a newer version of OpenModelica (tons of bugfixes). It probably also works on older OSX versions and CPUs (if there are any errors, run port -v install openmodelica-devel and post a log so we can fix it; I don't have access to any 32-bit Intel Macs, only G4 and 64-bit Intel).

$ file OpenModelica150/bin/omc
OpenModelica150/bin/omc: Mach-O 64-bit executable x86_64

Anyway, in 45 minutes there should be an Ubuntu32 build up. Hopefully the server can handle it, else I'll just have to make some builds nightly and others on demand.

Bah. I missed you were using 32-bit platform. I'll see what I can do; I can probably fit another VM to the build server, but it only has 16GB of RAM so I'm a bit uncertain.

The example seems to be working using branches/sjoelund-functiontree instead of trunk (well, at least the simulation runs without error; I did not verify if the results are correct). So it will be fixed when we merge it with the trunk in the near future. (It is a bug in the current trunk though)

There is a new virtual machine running Ubuntu 10.10 to create nightly builds (I suppose also release/stable when new releases are made)
deb http://build.openmodelica.org/apt nightly-ubuntu contrib # Based on Ubuntu-Stable

Try it if you want. It seems to not have these issues with OMNotebook (and should be more reliable for people using stable Ubuntu).

The problem with code generation is that you have a name conflict with the implicit for iterator variables and the globally defined ones.

You can just remove   Integer i=1, k=1;  and the model simulates correctly.

If you have a stiff system, the step size is ignored (DASSL will take as small steps as is necessary to solve the equations with the given error tolerance). So you could try increasing the tolerance.

Or you could try a fixed step-size solver like euler or rungekutta.

This is an issue with Qt4.7 (we compile against Qt4.4 on Debian Stable because Debian users can't use Ubuntu executables, but Ubuntu users can use Debian executables).
The OMNotebook I compile myself on Ubuntu does work properly. Hopefully this will be solved when Debian updates their ancient software. I'm considering adding some more virtual machines to build both Debian and Ubuntu versions. It's quite weird that the release packages does work fine.

You could probably force the old OMNotebook to be install together with the new omc

I created a bug here (that I probably won't fix): http://openmodelica.ida.liu.se:8080/cb/ … ation=true

Yes, the stable packages have 4 months of bugfixes applied to it.

The release packages were working.
The stable packages were broken and now working.
The nightly packages are still broken (but should be fixed with the automatic build at 12:00).

Thanks for reporting this issue.

The issue with QString(int) is fixed in OpenModelica/trunk (they added String(int) constructor in Qt 4.7, and the creators of OMNotebook used String(NULL) instead of String("")).

You could of course install just omc, omnotebook, omshell‚ omshell-terminal instead of openmodelica (which pulls in drmodelica and drcontrol; you could download those files separate if you want to use them).
At least as a workaround until I know why the packages do not work on 32-bit (it works for me on 64-bit Ubuntu 10.10).

If you start OMNotebook from the menu, note that you have to logout/login for the environment to refresh.

If you use a terminal, verify that OPENMODELICAHOME is set, and then start OMNotebook from the same terminal.
echo $OPENMODELICAHOME
OMNotebook

There is a reason environment variables are discouraged by Debian maintainers... We just haven't had time to update these things.

Error: Too few equations, underdetermined system. The model has 4 equation(s) and 12 variable(s)

It flattens without errors using:
$ OPENMODELICAHOME=/usr OPENMODELICALIBRARY=/home/marsj/dev/sjoelund-functiontree/libraries/msl31/ omc a.mo Modelica

What version of OpenModelica are you using? Per recently made some fixes regarding the Digital examples.

the number of intervals is the number of time steps the simulation will take.
For example, if you simulate from time 0 to 1.0 with 10 intervals, you will get output at 0.0, 0.1, 0.2, 0.3, ..., 1.0

If you have more intervals, the simulation will be slower

Well, you are doing closesocket(sock); And you'd need to make sock and the other data global to save it between calls.

If you have a global variable (or a static local variable), you can store a global state that does not change between function calls.

static int is_initialized = 0;
if (!is_initialized) {
  connect();
  is_initialized = 1;
}
... code goes here; always connected. It's the same connection for all calls to the function though.

As for OMI, I have no clue

Do you connect() every time you exchange data? That seems... Slow. Maybe you could solve it by using a global variable for the connection or external objects instead.

Yes, mixing C and C++ can be a bit weird, but it's mostly if you include C++ headers in a C file.
If you create a function fn in a C++ file that only calls the C++-function you want to call, and make it linked external "C", and only expose "external int fn(int);" in a header (or the automatically generated code of OMC), you are usually fine. It's always possible to create such an entry point if it doesn't use C++ datatypes.

Yes, but you need to force the compiler to link it in C-mode (no function overloading):

myFile.cpp:
external "C" {

int myFunction(int x) {
  return 3*x;
}

}

Yes, but the problem is supposed to be there, as Modelica doesn't support function calls on the form you are describing
(a,b,c) = fn() is ok
(a,-b,c) = fn() is not

rungekutta is a fixed-step solver (order 4; euler is rungekutta order 1).
There is no way of reducing the number of variables in the plt-file, but you can run scripts on the result file instead of plot-commands directly (not handling plotting directly in OpenModelica). If you do process the file after simulation, you can also change file format for example to .csv, which takes a bit less space and might be easier to convert (GNUPLOT can handle csv-files and is reasonably efficient).
You can also choose mat-file as output if you have Matlab (I don't have it installed at the moment so I can't verify if it works or not).

http://build.openmodelica.org/omc/builds/windows/ for Windows nightly builds (latest is Oct 12; r6338).
http://openmodelica.org/index.php/downl … load-linux for Linux nightly (latest is Oct 14; r6383).

"The only way to call a function returning more than one result is to make the function call the right hand side of an equation or
assignment. In these cases, the left hand side of the equation or assignment shall contain a list of component
references within parentheses."

Your tuple contains a negated component reference, which is not allowed according to the specification. We made OMC more conforming to the specification with regard to function calls. For example, you can now omit -vx and just type del = ExternalFunc1(time). The error messages are as bad as always though.

There isn't an easy way to do this. Conditional components are rather ugly:

class WithAlternatives

  parameter Integer alternative;

  Real alt1 if alternative == 1;

  Integer alt2 if alternative == 2;

end WithAlternatives;



class A

  extends WithAlternatives(alternative = 2);

end A;

Why do you need a header file? The model is linked as an executable, not a library ( the model conforms to OPENMODELICAHONE/includes/omc/simulation_runtime.h ).

Just run "make -f modelname.makefile" followed by "./modelname"

It is possible to install OpenModelica without root access. I wouldn't recommend trying to build it from source yourself unless you already have all dependencies installed though (there are a lot of dependencies; I'd recommend not compiling with Qt for example).

You could take the required .deb-files from http://build.openmodelica.org/apt/pool/contrib/, unpack them into some directory and set some environment variables to get everything going. (Setting your own PATH variable to include the bin directory, setting OPENMODELICAHOME to the directory and OPENMODELICALIBRARY to $OPENMODELICAHOME/share/omlibrary/modelicalib/). If your Linux installation contains the runtime dependencies, you are fine.

Yes. After calling simulate(myModel) or buildModel(myModel), you can open myModel.cpp and see all the source code yourself. The function passed to the DASSL solver is "int functionODE()".

Yes, in many different ways:
You can use OpenModelica as a CORBA server (see trunk/Compiler/runtime/omc_communication.idl for interface)
You can use OpenModelica as a server using sockets
You can use OpenModelica as a script (system("omc myScript.mos") from C-code)
You can generate executables using buildModel(myModelName) and then use system("myModelName") in C. (You can also change myModelName_init.txt to change input parameters between runs)

final constant NonSI.Temperature_degC T_zero =  -273.15 "Absolute zero temperature";

You need to use:

start=to_degC(Modelica.Constants.T_zero)

Anyway, if you want to enforce that the value is in the correct interval, you need to do that explicitly. The min attribute is only supposed to add an assertion equation:
assert(value >= min and value <= max, "Variable value out of limit");

OpenModelica does not add these equations. But min is only supposed to be a hint to the optimizing backend (e.g. if you state min=0, it means the value is always positive and you can make some assumptions).

I'd guess "touch /usr/local/lib/libmico.so" would suffice.

It's weird that SimForge doesn't at least read the environment variables to set it up automatically.

Use your $OPENMODELICAHOME and $OPENMODELICALIBRARY
/usr and /usr/share/omlibrary/modelicalib by default. Note that it asks for the path containing bin/omc, and that modelicalib contains more libraries than just MSL2.2.

However, it seems SimForge needs LD_LIBRARY_PATH for the Windows version to work. The Linux version of omc does not use libmico, since it's not part of the Ubuntu distribution.

outputInterval and fixedStepSize do not exist in OpenModelica
numberOfIntervals changes the step size (why it's not called stepSize, I do not know). anyway, step size ~ (stopTime-startTime)/numberOfIntervals
tolerance is used in dassl (it knows how large an error there is from integrating a derivative); I'm unsure if it's used when solving non-linear systems or the like
method = "euler" "rungekutta" "dassl" "dassl2" "inline-euler" or "inline-rungekutta" (default dassl). Newer omc versions give an error if it finds that you select an unsupported solver.

This is what I got when running the code....

$ omc a.mo Modelica

Error processing file: a.mo

[/usr/share/omlibrary/modelicalib//Modelica/Blocks/Sources.mo:194:7-194:54:readonly] Error: Variable pulse.amplitude: Wrong type on builtin attribute quantity of type Integer, expected String

[/usr/share/omlibrary/modelicalib//Modelica/Blocks/Sources.mo:194:7-194:54:readonly] Error: Variable pulse.amplitude: In modifier quantity = 380, not processed in the built-in class Real

[/usr/share/omlibrary/modelicalib//Modelica/Blocks/Sources.mo:194:7-194:54:readonly] Error: Variable pulse.amplitude: Wrong type on builtin attribute quantity of type Integer, expected String

[/usr/share/omlibrary/modelicalib//Modelica/Blocks/Sources.mo:194:7-194:54:readonly] Error: Variable pulse.amplitude: In modifier quantity = 380, not processed in the built-in class Real

I think you are using quantity wrong. If you are using a variable with unit "Volt" in Modelica, that means quantity="Current", unit="V".

If you want to set that the amplitude is equal something, use:

SO.Pulse pulse(amplitude =380, width =10)

The CORBA API is String->String. Only. The socket interface is the same, but harder to use so I recommend CORBA.

What you can do is wrap the simulate() command for the user.
Your Java code parses the CORBA response to get name of the plt or csv file. You then use that file and present it to the user.

CPU time (after you have compiled the model, e.g. by running the simulate() command first):

system("time ./ModelA > output.log"); readFile("output.log");

or (not as accurate):

timing(system("./A"));

Number of zero crossings (after you have generated source code, e.g. using the buildModel() or simulate() command):

system("grep \"^#define NG\" ./ModelA.cpp")

Maximum integration order I don't know how to get.

The problem here is that:
vx(t) + der(vx(t))*step = vx(t+1) in the next timestep. The function call can't provide vx(t+1) or der(vx(t)), so omc doesn't know how to handle that equation. I think that's because omc can only use integrating solvers (no way to change state variable that I know of).

I believe that you are thinking like I used to: der(x) = "(x-delay(x, step))/step". But that's the wrong slope when you use an integrating solver.

I'm not 100% sure, but I believe this is the correct syntax:

Heater.Wood[N] woodInHeater(each v=woodInput.v, each rho=woodInput.rho, each s0=s_0, each h0=h_0);

I don't recognize the warning though. OpenModelica output is:
[b.mo:2:1-2:20:readonly] Warning: Variable x: Non-array modification '10' for array component, possibly due to missing 'each'.

That code does work in (at least in the trunk version of OpenModelica).

That's not as issue with reinit of a matrix in when; it's an issue with change() not working properly (only works on discrete Real in OpenModelica runtime it seems).

You can't access time from within a function in Modelica. You need to pass it as an argument if you want to use it.

Normally you would put an if-equation:
if (y0 <= 6.37814E6) then terminate("Simulation ended at time: " + String(time)) end if;

But OpenModelica seems to have issues with it.

You can use:
assert(y0 > 6.37814E6, "Simulation ended at time: " + String(time));

After simulation, call readFile("output.log"), and use val() on the time shown for each of the variables y1,y2,y3.

I believe the answer you are looking for is in the following topic: http://www.openmodelica.org/index.php/forum/topic?id=88

No, it is not possible to put an equation or algorithm section within the statements of a for-loop. The code won't even parse, which means the error messages will be really weird.

It's part of the subversion sources

You type "make omcd" instead of "make omc" to build omcd.exe. You can debug mo-files with it, but enabling failtrace often gives sufficient information for debugging and does not require compiling omcd (omc +d=failtrace +showErrorMessages myFile.mo from command-line).

If you need omcd.exe, read README-OMDev-MINGW.txt for information on how to compile it.

Change the solver to euler or dassl2. The dassl implementation has some issues with very small time steps (I think it uses comparisons with an absolute delta somewhere).

The default is:
simulate(modelName, method="dassl")

You can also try some alternative solvers:
"euler" is a fixed-step, explicit euler solver.
"rungekutta" is supposedly fourth-order.
"dassl2" uses the same event system as the euler solver, and the same solver as "dassl". I haven't checked it in-depth, so I'm not sure what it does differently from "dassl".

$ ./sam
ERROR: Division by zero in partial equation: m_v / V_v because V_v == 0.
Error in initialization. System of initial equations are not consistent.

The project files just are not updated. You might need to update them to match the Makefiles, as that is what is used during development and in OMDev.

Hmmm... simulation_result.cpp and solver_euler.cpp don't exist anymore. They have been replaced by solver_main.cpp and simulation_result_{csv,plt,bin}.cpp

omc_communication.cc and .h are created in Compiler/runtime/ automatically (or should be).
If it's a problem in OMShell or OMNotebook you may have to copy them manually.

In Windows by default, javac is not installed on the system $PATH. It's not a problem as the make system will recover and use the jar-file from subversion instead.

Ah. Maybe you have some old downloaded files stored there (/var/cache/apt/archives). The problem is solved so it shouldn't happen again, but if you downloaded some of the bad files, they will still be there

Also, I'm assuming you are using stable or release. Then you won't be able to get the version compiled for SSE instead of SSE2 (until the release comes).

Oh yea... I forgot about that. Adrian is still reinstalling the webserver OS. Not everything is back up yet.
You can use one of the source files from the Linux build system. They are same, just not version-controlled: http://build.openmodelica.org/apt/pool/ … rig.tar.gz

The README is part of the source code.The username and password are in the first paragraph of the article you linked.

Check out the source then read the README for instructions. Or you might be able to use just omc (not OMNotebook/OMShell), if omc.exe was compiled with MinGW.

Building from source is probably safest. I only use Mac and Linux versions of OMC, so I can't really help you with weird bugs there.

What bug remains?

It sounds like your omc is not recent enough. Try http://build.openmodelica.org/omc/build … n-5740.msi or build it from source.

Try omc_5833-1_i386.deb . It's compiled -msse -mfpmath=sse -ffloat-store, which should make the evil fortran code work correctly.

Yummy... 3 BouncingBall testcases spinning at 100% CPU on the build server.... That's what happens if you try to run simulations without -msse2 -mfpmath=sse

-msse is not good enough, because the dassl solver requires double precision. And the 387 floating point unit spins forever in simulations. Which means SSE2 is required to use OpenModelica on Linux.

I'll get on fixing the build on 32-bit tomorrow. I'll just need to check the build logs since it failed.