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

[Linux Mint, Python 3.6] "OMC Server is down. Please start it!"

[Linux Mint, Python 3.6] "OMC Server is down. Please start it!"

As stated in the description. The error I see and my steps there can be seen here:

output.txt

How can I fix this error?

Edited by: dafred - Nov-19-18 12:05:08
Attachments:

Re: [Linux Mint, Python 3.6] "OMC Server is down. Please start it!"

My guess would be that the OS version you use and the OS version omc was compiled on do not match, because it crashes during initialization of ZeroMQ. It could also be that you are using an older version of OMC before the ZeroMQ fixes.

Re: [Linux Mint, Python 3.6] "OMC Server is down. Please start it!"

Thank you for your reply and time! So far, as this is more of an inconvenience than a fatal problem to my work, I have not yet tried another distribution.

I have, however, stumbled across another problem (that could possibly be related).

[EDIT] By this time, I asked the same question here: https://stackoverflow.com/questions/534 … d-gradient

I want to use the Tensorflow C++ API in a Modelica Model.
For this, I created a class in C++ that encapsulates the Tensorflow details.
Moreover, the same file contains 3 functions (to call the constructor, destructor and a function that uses an existing instance of my class. These functions are declared "extern" in the respective header file (only if read by a C++ compiler, I am using __cplusplus to differentiate).
I then compiled said file (the class and the 3 functions) into a .so using g++ (I did make use of -fPIC and -shared). In /usr/lib, I created a symlink to said shared object library.
(For completeness, I should mention that I had trouble with the "LibraryDirectory" and "IncludeDirectory" annotations. This is why I created symlinks to the contents of all the directories I would pass to g++/gcc using -L and -I (for my test program) right into Model/Resources/Library and Model/Resources/Include directories. As there were no more compilation errors, I thought that this was okay.)


Now the strange thing is:

I can use the 3 functions in a test program compiled with gcc. I linked it against all Tensorflow libraries (and libm, libstdc++ and my .so from above) and it just works as expected.
However, when I try to use these 3 functions in a) a Modelica Class (constructor and destructor), and b) a function using an "external" function call, it will compile fine but a runtime error occurs:

------------------------------------------------------------------------------------------------------------------------------------------------

stdout | OMEditInfo | <p>/tmp/OpenModelica_fred/OMEdit/TestCpp -port=44382 -logFormat=xmltcp -override=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=TestCpp_res.mat -w -lv=LOG_STATS</p>
stdout | error | <p>2018-11-22 10:47:00.153977: F tensorflow/core/framework/function.cc:1440] Check failed: GetOpGradFactory()-&gt;insert({op, func}).second Duplicated gradient for MapAccumulate<br>

stdout | error | <p>Process crashed</p>
stdout | error | <p>Process crashed<br>
Simulation process failed. Exited with code 6.</p>

------------------------------------------------------------------------------------------------------------------------------------------------

How is this possible? I am not able to do anything in my test program with the 3 functions that leads to the same error. What could the OMC-generated executable be doing with them that I am not in my test program?

Edited by: dafred - Nov-23-18 09:09:30

Re: [Linux Mint, Python 3.6] "OMC Server is down. Please start it!"

My runtime issue with my Tensorflow model has finally been resolved!

My OMEdit, for some reason, despite being set to gcc in Tools->Options->Simulation->Target Compiler used clang!

I don't know how to properly resolve this but what worked for me was to do the following (CAUTION):

cd /usr/bin
mv clang clang_OLD
ln -s gcc clang

Basically, this tricks any program calling "clang" into using calling "gcc". This is bound to cause side-effects but helps me for the moment.

There are 0 guests and 0 other users also viewing this topic
You are here: