[HUBCAP] Crash in latest nigly when connecting FMU ports in SSP

[diewald@…]

Hi,

the latest nightly in a HUBCAP sandbox crashes when connecting the ports of FMUs. This was observed when adapting ​https://download.fortiss.org/public/projects/af3/help/example_co-simulation.html to the HUBCAP platform.
To reproduce, use the attached FMUs. Create a new SSP model and import the FMU "input" and the FMU "openmodelica" as submodules. Then, connect the output port of the FMU "input" with the port "setpoint" of the openmodelica FMU. A crash should occur.

The corresponding log files and alike are attached.

[diewald@…]

Logs and FMUs to reproduce the crash

[diewald@…]

The bug is also present in Openmodelica v1.16 in HUBCAP.

[adrpo]

Ok. We will have a look at this asap.

[adrpo]

I tried to reproduce the bug using OMEdit on Ubuntu Focal is WSL and it doesn't crash.
I will try tomorrow on the actual Sandbox, maybe the problem is there.

[adeas31]

I can reproduce the crash. I have tried to push in a fix for it.
​https://github.com/OpenModelica/OpenModelica/pull/6901

[adeas31]

Fixed in bc86d38/OpenModelica.

[anonymous]

Perfect, thanks! I will test this with tomorrow's nightly in HUBCAP just to verify it.

[adrpo]

I made a new tool in the HUBCAP sandbox: OpenModelica nightly-build 20201111
which does not crash when you connect the things together. I saved the SSP in the Download folder there.

However, when the SSP is instantiated OMEdit freezes (seems to be due to the overture FMU).
It might be this issue:
​https://github.com/OpenModelica/OMSimulator/issues/858

[adeas31]

Lennart can you please test the ssp from command line to see if its OMSimulator or OMEdit that has the issue.

[adrpo]

Or maybe the actual FMUs are having the issue.

[adrpo]

I tried the SSP with the experimental OMSimulator from ​https://github.com/OpenModelica/OMSimulator/issues/858 and --numProcs=1 and got:

adrpo33@ida-0030:~/testing/omsimulator$ ~/OMSimulator/bin/OMSimulator --numProcs=1 TestSSP.ssp
info:    Set temp directory to    "/home/adrpo33/testing/omsimulator"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
info:    New model "TestSSP" with corresponding temp directory "/home/adrpo33/testing/omsimulator/TestSSP-6jkx7taq"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
info:    Set working directory to "/home/adrpo33/testing/omsimulator/TestSSP-6jkx7taq"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
error:   [terminate] Model "TestSSP" is in wrong model state
info:    0 warnings
info:    1 errors
Error occurred during initialization of VM
java.lang.Error: Properties init: Could not determine current working directory.
        at java.lang.System.initProperties(java.base/Native Method)
        at java.lang.System.initPhase1(java.base/System.java:1948)

[diewald@…]

Thanks a lot for your efforts: I will try out the updated sandbox tomorrow morning during the available time slot.
IIRC, my colleagues mentioned that the simulation had to be started from the command line to make the simulation work. I could not create a ticket for that issue yet as I did not get that far (yet). I'm not sure if this as an impact on the issue discussed here.
Another thing I can and will test tomorrow is whether the Overture version has an impact on the freezing issue. My colleagues had a working simulation with an FMU generated with Overture version 3.0.0 while I used version 2.8.5 from the HUBCAP tool catalogue.

I will let you know about the results tomorrow.

[diewald@…]

With the Openmodelica sandbox created by Adrian, I can now create connections without a crash of the application. Thanks for the quick fix!

Unfortunately, the freeze when trying to simulate the FMU setup occurs on my side, too. Using an FMU exported from Overture version 3.0.2 does not change the behavior.
If I start the simulation from the command line, I get the same error as written above, except the JVM error. Is it possible that the command-line error message is a result from a missing initialization that is mentioned in the co-simulation documentation linked in the first post? OMEdit hangs at this point, too, in addition to the hang if clicking "Simulate".

[barner@…]

Adrian, Alexander: We have previously discussed this with Hugo, and he suspects that this is because OMSimulator seems to decides there is a problem with the FMU at the initialization:

error:   [terminate] Model "model" is in wrong model state

Thus, OMSimulator deletes the temporary folder where the Overture generated FMU is still working, thus why you did not see the results.

From our experience, starting the simulation from the command line as follows works:

OMSimulator --deleteTempFiles=false ../Pendulum.ssp

However, at that point we could not continue our analysis due to lack of knowledge of OMSimulator.

Adrian, do you have any idea?

[diewald@…]

Simon, thanks for pointing out that the mentioned command fixes this particular issue. I will test this tomorrow when the sandbox timeslot is open again. I'd open another ticket for this problem.

[adrpo]

There is a HUBCAP review going on, so the platform is available today during the day.
I ran this on my own Windows computer in WSL:

adrpo33@ida-0030:~/testing/omsimulator$ ~/OMSimulator/bin/OMSimulator --deleteTempFiles=false TestSSP.ssp
info:    Set temp directory to    "/home/adrpo33/testing/omsimulator"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
info:    New model "TestSSP" with corresponding temp directory "/home/adrpo33/testing/omsimulator/TestSSP-n2mxnufv"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
info:    Set working directory to "/home/adrpo33/testing/omsimulator/TestSSP-n2mxnufv"
info:    Set working directory to "/home/adrpo33/testing/omsimulator"
error:   [terminate] Model "TestSSP" is in wrong model state
info:    0 warnings
info:    1 errors
stdout            | warning | The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
info:    Result file: TestSSP_res.mat (bufferSize=10)

From command line some result file is generated. I will check OMEdit.

[diewald@…]

Hi,

in the sandbox with the nightly built from master, the simulation does not finish with the command from comment 13 and 15 either. The last line is "info: 1 errors".

Regarding the released versions 1.14 and 1.16:
My colleagues noticed that executing the simulation from the GUI does work in Windows, while it doesn't under Linux and only the command line version can work there.
Note: This is different from the problem mentioned above, where the OMSimulator hangs in the hubcap sandbox image where the latest build from master is used.

Hope this helps somehow. BTW, would it make sense to separate the second observation (and maybe also the first one) to a dedicated ticket?

[diewald@…]

FYI, using the 1.16 version from the HUBCAP catalog, a segfault is produced referencing the libc-2.27.so.

[adrpo]

Yes, please open a new ticket about this and I will add Test.ssp to it.