Opened 4 years ago

Closed 3 years ago

#6194 closed defect (fixed)

Issue with chattering involving arrays in the Buildings library

Reported by: Francesco Casella Owned by: Andreas Heuermann
Priority: high Milestone: 1.19.0
Component: Run-time Version:
Keywords: Cc: Michael Wetter

Description (last modified by Francesco Casella)

Please check Buildings.Controls.Continuous.Examples.SignalRanker. The simulation fails with

LOG_SUCCESS       | info    | The initialization finished successfully without homotopy method.
stdout            | info    | Chattering detected around time 7.45058059692e-13..7.45057922302e-11 (100 state events in a row with a total time delta less than the step size 0.0002). This can be a performance bottleneck. Use -lv LOG_EVENTS for more information. The zero-crossing was: sigRan.y[1] < sigRan.y[1 + 1]
assert            | debug   | Aborting simulation due to chattering being detected and the simulation flags requesting we do not continue further.

Change History (12)

comment:1 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

comment:2 by Andreas Heuermann, 4 years ago

I would need to check dumps from the backend and the generated C code to determine if the generated equations for the zero-crossings are correct. I'm not sure if all array equations are handled correctly.
This could become ugly with this example, so having a minimal working example would be great, but that sounds like an even harder task.

Of course it could be a problem in the simulation runtime as well.
Hard to tell how much time is needed for this ticket.

comment:3 by Francesco Casella, 4 years ago

We'll see, we'll have one year to figure out.

comment:4 by Francesco Casella, 4 years ago

Description: modified (diff)

comment:5 by Francesco Casella, 4 years ago

Cc: Michael Wetter added

comment:6 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

comment:7 by Francesco Casella, 3 years ago

Description: modified (diff)

comment:8 by Michael Wetter, 3 years ago

I am fine with changing this example to add a time sampler at the input of the SignalRanker. As it is implemented now, it does inequality checks on reals without any hysteresis, and this is probably tripping up the solver when trying to figure out the time of the event when sin(...) and the pulse(...) happens simultaneously, one of which being a state event and the other likely a time event.

Let me know if I should go ahead and change this example in IBPSA and Buildings.

comment:9 by Francesco Casella, 3 years ago

I agree. We should probably avoid having numerically fragile examples in a library meant to be used across tools.

comment:10 by Francesco Casella, 3 years ago

@mwetter, if you do so please also commit it to the 7.0.x maintenance branch, so we see the results in the test reports.

comment:11 by Michael Wetter, 3 years ago

This test is now corrected on the master, the maint_7.0.x and maint_8.0.x branches of the Buildings library, and will be corrected for the IBPSA Library through https://github.com/ibpsa/modelica-ibpsa/pull/1535

comment:12 by Francesco Casella, 3 years ago

Milestone: 1.19.0
Resolution: fixed
Status: newclosed

I confirm that the test is now successful, see report.

Note: See TracTickets for help on using tickets.