Failed library coverage tests for model that work

[rfranke]

The library coverage test Modelica_3.2.3_cpp reports the following two models as failed simulation

Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.AIMC_Conveyor
Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_Transformer 

The reported simulation time is 0.00. There is no error message given. The two models work with my local installation of OpenModelica.

What is wrong?

[rfranke]

Meanwhile this happens for four models from Modelica_3.2.3_cpp:

Modelica.Blocks.Examples.Rectifier12pulseFFT
Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse.ThyristorBridge2mPulse_DC_Drive
Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.AIMC_Conveyor
Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_Transformer

and five models from Modelica_trunk_cpp, additionally:

Modelica.Blocks.Examples.Rectifier6pulseFFT

[rfranke]

Yesterday the daily tests reported failed simulations after 482.5s for Rectifier6pulseFFT and Rectifier12pulseFFT in Modelica_3.2.3_cpp. Today Rectifier6pulseFFT succeeds, including verification, whereas the simulation fails for Rectifier12pulseFFT after 0.00 seconds. There have been no changes to the Cpp runtime. See https://libraries.openmodelica.org/branches/history/master/2021-08-14%2014:24:33..2021-08-16%2023:18:48.html

[sjoelund]

I think I can reproduce it, and I am guessing it has something to do with verifying the results. The problem only happens when enabling verification.

[sjoelund]

It's a pretty annoying bug. The omc process started by OMPython somehow dies, and then OMPython blocks. When a thread in Python3 is blocking, the process cannot exit and it will wait until we finally clean up by sending SIGKILL to remaining zombies...

The problem seems to be that the we hit the ulimit of 8GB when reading the MAT4 file. And there are probably other processes open at the same time in the process group. I have made some improvements (locally) that make the reports look better even if it fails though.

The C++ runtime gives a 2.4GB large file while the C runtime gives a 314MB file without filter. And for the C runtime, we do filter so only compared variables are output. I guess I will just make the simulation work and diff fail if the C++ runtime cannot filter the result-file. First I will try to see if we can run the separate filtering API only for the C++ runtime and perhaps remove all variables before running the diff. But it may fail due to the same reasons (cannot open the large file).

[rfranke]

Thank you for the investigations. The current Dassl implementation of the Cpp runtime just writes a result line everytime the solver returns. Filtering could also be improved to the Cpp runtime. How do you filter variables for the C runtime -- I don't see any command line argument in the sim log?

[sjoelund]

https://github.com/OpenModelica/OpenModelica/pull/7786 will add a flag to OMC. When this is in the version used by OMC on the test machines, I can update the testing script.

Filtering could also be improved to the Cpp runtime. How do you filter variables for the C runtime -- I don't see any command line argument in the sim log?

It's in the other log-file since the variableFilter may be too long to pass as command-line arguments:

Running command: translateModel(Modelica.Blocks.Examples.PID_Controller,tolerance=1e-06,outputFormat="mat",numberOfIntervals=5000,variableFilter="time|PI.I.y|inertia1.phi|inertia1.w|integrator.y|spring.phi_rel|spring.w_rel",fileNamePrefix="Modelica_3.2.3_Modelica.Blocks.Examples.PID_Controller")

[rfranke]

PR OpenModelica/OpenModelica#7801 (Add variable filter option to Cpp runtime) solves this issue.

Edit: Interestingly 6 more examples of MSL 3.2.3 verify now, even though only 4 appeared affected https://libraries.openmodelica.org/branches/history/master/2021-08-23%2012:02:36..2021-08-23%2023:18:10.html