OpenModelica
Simulation gets stuck in the middle of execution
Description
While working on a custom model made up with a inverter coupled with a permanent magnet motor, I experienced the situation where the simulation got stuck after a certain execution time. Since I can't share the model, I tried replicating the issue by creating a simpler example model. I found out that the issue can be easily replicated by using the PolyphaseTwoLevel_RL example in the Modelica library.
Steps to reproduce
- Open the PolyphaseTwoLevel_RL.
- Simulate it first with default parameters. Simulation runs smoothly, but Warning: maximal number of iteration reached but no root found is printed on the log.
- Change the f parameter (inverter switching frequency) from 1000 to 10000 Hz
- Run the simulation. It gets stuck at 58 %
- Change the f parameter from 10000 to 10000.1 Hz. Simulation runs smoothly. Same happens by setting f = 9999.9 Hz
Expected behavior
Simulation execution should not be stuck.
Version and OS
- OpenModelica Version OpenModelica v1.17.0 (64-bit)
- Versions of used Modelica libraries: Modelica v4.0.0
- OS: Windows 10, 64 bit
@leo-recover thanks for your report!
Could you please first try this out the latest nightly build and confirm that the issue is still present?
Thank you for the prompt response! I've just installed the OpenModelica v1.18.0-dev-344-gbd2ff8137a (64-bit) version. I confirm that I can reproduce the issue here as well.
mos-script to reproduce this (also on Linux):
loadModel(Modelica, {"4.0.0"});getErrorString();
simulate(Modelica.Electrical.PowerConverters.Examples.DCAC.PolyphaseTwoLevel.PolyphaseTwoLevel_RL, simflags="-override f=10000");getErrorString();
an additional "electrical" comment
The system includes diodes/transistors with very low conducting and very high turn-off resistances (1e-5/1e5). This could result in a stiff system of equations and solver problems when the defined tolerance is too high (e.g. 1e-6). Reduction of the tolerance solves the problem here.
loadModel(Modelica, {"4.0.0"});getErrorString();
simulate(Modelica.Electrical.PowerConverters.Examples.DCAC.PolyphaseTwoLevel.PolyphaseTwoLevel_RL, simflags="-override tolerance=1e-7");getErrorString();
My assumption why a small modification of carrier frequency was helpful: a kind of interference between 50Hz grid, 10000Hz switching frequency and 20µs sampling.
OMCompiler v1.18.0-dev.343+g44c791b674 / linux64
Yes I thought about the same assumption you made. Anyway I'm not able to work around the issue by decreasing the tolerance. At least not on OMCompiler v1.17.0 / linux64. The command I run is:
simulate(Modelica.Electrical.PowerConverters.Examples.DCAC.PolyphaseTwoLevel.PolyphaseTwoLevel_RL, simflags="-override tolerance=1e-7,f=10000");getErrorString();
Tomorrow I will try again on the Windows machine running the dev version. I see though that the command you posted does not override the frequency value to 10000. Perhaps this is the reason why it's working for you?
Sorry - I did a mistake in my first reaction. My last observation: The reported problem has noting to do with the change of switching frequency 1000Hz -> 10000Hz. What I did:
- extract the model from the library
- change the number of phases to m=3 (to reduce the amount of data; f remains unchanged = 1000Hz)
- run simulation with
-lv=LOG_EVENTS,LOG_NLS
LOG_NLS | info | ############ Solve nonlinear system 803 at time 2.00411e-08 ############
| | | | | initial variable values:
| | | | | | [ 1] inverter.transistor_p.idealGTOThyristor[3].s = 0.002 nom = 1
| | | | | | [ 2] inverter.diode_p.idealDiode[3].s = -2.0000002e-08 nom = 1
| | | | | | [ 3] inverter.transistor_n.idealGTOThyristor[3].s = 100 nom = 1
| | | | | | [ 4] inverter.diode_n.idealDiode[3].s = -100 nom = 1
| | | | | Solution status: SOLVED
| | | | | | number of iterations : 9
| | | | | | number of function evaluations : 21
| | | | | | number of jacobian evaluations : 9
| | | | | | solution values:
| | | | | | [ 1] inverter.transistor_p.idealGTOThyristor[3].s = 0.002
| | | | | | [ 2] inverter.diode_p.idealDiode[3].s = -2.0000002e-08
| | | | | | [ 3] inverter.transistor_n.idealGTOThyristor[3].s = 100
| | | | | | [ 4] inverter.diode_n.idealDiode[3].s = -100
At the begin of the simulation the number of iterations/evaluations is low, BUT
LOG_NLS | info | ############ Solve nonlinear system 803 at time 0.0585 ############
| | | | | initial variable values:
| | | | | | [ 1] inverter.transistor_p.idealGTOThyristor[3].s = 0.024079785 nom = 1
| | | | | | [ 2] inverter.diode_p.idealDiode[3].s = -2.4079785e-07 nom = 1
| | | | | | [ 3] inverter.transistor_n.idealGTOThyristor[3].s = 100 nom = 1
| | | | | | [ 4] inverter.diode_n.idealDiode[3].s = -100 nom = 1
| | | | | Solution status: SOLVED
| | | | | | number of iterations : 56919
| | | | | | number of function evaluations : 85947
| | | | | | number of jacobian evaluations : 57200
| | | | | | solution values:
| | | | | | [ 1] inverter.transistor_p.idealGTOThyristor[3].s = 0.024079785
| | | | | | [ 2] inverter.diode_p.idealDiode[3].s = -2.4079785e-07
| | | | | | [ 3] inverter.transistor_n.idealGTOThyristor[3].s = 100
| | | | | | [ 4] inverter.diode_n.idealDiode[3].s = -100
at the end the number of iterations/evaluations is quite high. The simulation finished successfully, but for higher switching frequency the "Simulation gets stuck in the middle of execution".
MO, MOS and LOG's attached. PolyphaseTwoLevel_RL.2.zip
I have an update. Running the same example with OpenModelica v1.18.0 (64-bit) using the Cpp runtime results in a successful simulation. When using the (default) C runtime I confirm the simulation is stuck at 58%, with CPU running at 100% without any progress.
Can't reproduce the issue in omc v1.26.0-dev with the C runtime on Ubuntu (WSL). Closing the issue for now.
When simulating longer (StopTime=0.1) I get an error message, but I'm not a modeler so I can't tell if that is because of an inconsistent system or a bug in OpenModelica:
Simulation process failed. Exited with code 255.
Homotopy solver Newton iteration: Maximum number of iterations reached at time 0.020500, but no root found.
Simulation terminated due to too many, i.e. 20, event iterations. This could either indicate an inconsistent system or an undersized limit of event iterations. The limit of event iterations can be specified using the runtime flag '–mei=<value>'.
If you think the issue still persist please re-open this issue.
