Regression: SMPM_Braking in MSL v4.1.0-dev fails due to chattering in OpenModelica

[casella]

Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SynchronousMachines.SMPM_Braking in MSL 4.0.0 simulated successfully in OpenModelica, with results matching the reference files.

It fails instead in MSL 4.1.0 with the following error message:

Chattering detected around time 0.523614405406..0.523625675045 (100 state events in a row with a total time delta less than the step size 0.0001). This can be a performance bottleneck.
The zero-crossing was: diodeBridge2mPulse.diode_n.idealDiode[2].s < 0.0

This may be a tool issue, but was apparently triggered by some change in the library at some point. I will do some bisection to figure out when it happened.

@maltelenz does it work for you in WSM?

[maltelenz]

This example does not work consistently in WSM. We have always had (platform dependent) issues with this model over time.

For the 4.1.0 version, we have issues on Windows-64 (correctness) and Linux-64 (looks like it could be chattering). Currently, it does work on the platforms macOS-Intel, macOS-ARM, Windows-32, Linux-32.

[AHaumer]

I tested this example (which was implemented several years ago) both from MSL 4.0.0 and 4.1.0, both with OM 1.24.3 64 bit and Dymola 2025x 64 bit without any problem (ok OM reports "Homotopy solver Newton iteration: Maximum number of iterations reached at time 0.000000, but no root found.", but the simulation runs correctly,)
@casella I don't understand what's the root for these problems. @christiankral do you have any idea?

[casella]

Interesting.

Indeed, I can also run Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SynchronousMachines.SMPM_Braking from MSL 4.1.0-dev successfully with OMC on my Windows 11 PC, while it fails due to chattering on the CI running under Linux.

This is consistent with @maltelenz that reports platform-dependent problems on WSM.

[AHaumer]

IMHO this is a tool issue. I tested the example with Dymola 2024x on my virtual Linux Mint and there are no problems.
I need a little bit of time to install OM on my virtual Linux for testing.

[casella]

I flattened the SMPM_Braking model of MSL 4.0.0 and MSL 4.1.0 with OMC and compared the flat outputs. There are some changes that should not have dramatic consequences but can change the numerical robustness of the generated code:

• Modelica.Complex.Math.abs changed the algorithm from result := (c.re ^ 2.0 + c.im ^ 2.0) ^ 0.5; to result := sqrt(c.re ^ 2.0 + c.im ^ 2.0);. In principle this should be the same, but maybe there are subtle numerical differences when getting close to zero?
• callse to exp() became calls to Modelica.Math.exp(), calls to atan2() became Modelica.Math.atan2(), but given the inlined implementation of those functions, this should have no consequence

[casella]

Using OMC, I checked the diodeBridge2mPulse.diode_n.idealDiode[2].s variable around time = 0.523614405406...0.523625675045, (which is where the MSL 4.1.0 model undergoes 100 switching on Linux before it aborts for chattering), on my Windows PC.

This is the event log:

This is a first plot in the 0.52...0.59 time interval

Zoom in

Zoom in

Zoom in

So, it seems that this variable is "bouncing" three times at increasing frequency around s = 0, until it finally breaks through. The last bounce has a really small amplitude (5e-6), so maybe it's really borderline in terms of event detection, and possibly depending on OS-specific numerics.

I then tried to switch off the equidistant time grid output, so I can see the actual DASSL integration steps. If I do so, the simulation runs until time = 0.7227, then I get a ton of events, the last two at times: 0.726475568508 and 0.726475568896 (which are really, really close), and then the simulation crashes.

This is the overall behaviour of that variable

and this is a zoom of the last 0.15 s:

@AHaumer it seems pretty clear to me that the final state of this simulation is a singular state where all voltages and currents on the variable resistor get to zero, which is also the singular point of the ideal diodes. This seems pretty stretched to me from a numerical point of view.

I guess we should make this a bit more numerically robust by increasing RonDiode and/or decreasing GoffDiode. For example, if I set them both to 1e-4 instead of the default 1e-5, the simulation runs smoothly until the end also with no equidistant time grid.

[casella]

See PR #4562. Except for the increased robustness, the results are virtually identical, here I compare the current in the variable resistor in the two cases and it's very close

Anyway, if we accept #4562, we should probably re-generate the reference results.

@maltelenz please check if the changes in #4562 make the model run OK in WSM.