Archived OpenModelica forums. Posting is disabled.

Alternative forums include GitHub discussions or StackOverflow (make sure to read the Stack Overflow rules; you need to have well-formed questions)

Forgot password? | Forgot username? | Register
  • Index
  • » Users
  • » ncafferkey
  • » Profile



Cluster: OpenModelica Compiler 1.9.1+dev (r20338) (Bootstrapping version)
Desktop: OpenModelica Compiler 1.9.1+dev (r20338) (RML version)

I've now rebuilt the cluster's omc as an RML version, and this model completes successfully. Thanks for the tip. Do you happen to have a link to where I can learn about the differences between these versions?

Should I post more details about the crash with the bootstrap version, or is this an expected limitation of this version?

No, I copied a clean SVN checkout. It's a 64-bit Xeon cluster node with 8GB RAM. The model used is from Jens Frenkel, with N=2000 (this model takes 52 minutes to complete on my desktop machine).

This model and larger variants, up to N=9000, work on my desktop machine. My desktop is also 64-bit, and has 16GB of RAM, but I've often run two or three of these models in parallel without trouble.

I'm now trying the same GCC version as used on my desktop, 4.6.3. This necessitates an upgrade of the MPC library, so maybe this will help.

Thanks. I managed to compile OM with GCC 4.4.7, but it seg faults on some models. The first time I tried it, it crashed in the omc_BackendEquation_traverseBackendDAEExpsEqn function. When I reverted to an SVN revision that works well on my first machine (r20338), it crashed somewhere else: omc_Tearing_traverseComponents.

Is this likely to be caused by the compiler version? If so, which version would you recommend?


I get the following error when trying to compile OM from SVN r21763:

g++ -isystem /home/cuc/neil/include/ -fno-tree-ch -fno-tree-vrp -fno-tree-pre -fno-stack-protector -fPIC -c src/netstream-main.cpp -o obj/netstream-main.o
src/netstream-sender.h: In member function ‘void netstream::NetStreamSender::encode(netstream::NetStreamStorage&, const T&) [with T = char [5]]’:
src/netstream-sender.h:139:   instantiated from ‘void netstream::NetStreamSender::changeGraphAttribute(const std::string&, long int, const std::string&, const T1&, const T2&) [with T1 = char [5], T2 = bool]’
src/netstream-main.cpp:58:   instantiated from here
src/netstream-sender.h:72: error: invalid operands of types ‘const char (&)[5]’ and ‘int’ to binary ‘operator!=’

I'm using GCC 4.1.2. Would a more recent compiler help? The same revision compiles without problems on another machine with GCC 4.6.3.


I'd like to see the result of converting 'connect' equations to normal equations. What part of the compiler performs this operation, and is it possible to emit the resultant source code after such "pre-processing"?

Also, one element of the matrix is not a constant. Instead, it is "{'if', sineVoltage.signalSource.startTime,' < ' {},{},}". Is this a bug, or does it mean that a constant can't be evaluated for that coordinate?

No problem. Thanks a lot.

Thanks. It works with one parameter. Ideally, however, I'd like the data to be in a CSV file. Is there an easy way to convert to such a format?

"Error: Class exportDAEtoMatlab not found in scope <global scope> (looking for a function or record)."


I'm having trouble using the exportDAEtoMatlab function. If I run it as follows, there does not appear to be any output file:

exportDAEtoMatlab(MyModel, "mymodel.m")

Are my parameters correct? By the way, it's frustrating that I get no feedback from omc etc. about whether the function is even recognised (e.g. I don't get an error if try to run literally xyz99() as a function).

In case anyone else is interested, I accessed the backend time like this:

res := simulate(cl);
t := res.timeBackend;
system("echo " + String(t));

Thanks. How can I access the times you refer to?


Using the setMatchingAlgorithm function with various values doesn't appear to make any significant difference to the translation times I see. Is this expected? I find it surprising, in particular because I've read that  the *Ext versions are usually about 10 times faster than the standard versions.

The problem seems to be specific to string concatenation: if I change the loop body to "s := i", s contains the last list element ("strings.") at the end of the loop.


The following example from Section 1.2.9 of the user guide doesn't work as expected for me:

lst := {"Here ", "are ","some ","strings."};
s := "";
for i in lst loop
   s := s + i;
end for;

At the end of this sequence, 's' is expected to contain the concatenation of all the strings, but for me it is still empty. Is this a bug or am I doing something wrong?

OM versions tried:
"OpenModelica Compiler 1.9.1+dev (r19572) (RML version)"
"OpenModelica Compiler 1.9.0 (r17628)"

  • Index
  • » Users
  • » ncafferkey
  • » Profile
You are here: