1
votes

Here is the link of the model:https://mbe.modelica.university/behavior/discrete/decay/#chattering The simulation result for the following result in Dymola 2021 would be:

model WithChatter(stopTime=1.001s) 1112Snipaste_2020-09-10_00-26-32

model WithChatter(stopTime=1.5s) 2122

As we could see, noEvent operator does decrease the CPUTime, but it also causes the system stiff, it would be easier to understand with more explanation about why noEvent would cause the system stiff.

Based on the event logging of model WithChatter, the simulation process actually uses the minimum time step because the der(x) is not a continuous function. But why doesn't this approach suit the model WithNoEvents?(https://mbe.modelica.university/behavior/discrete/decay/#speed-vs-accuracy)

If noEvent operator means using the integrator directly, it might require the functions in the equation system have to be continuous? So Does this mean that the model used in the Chattering example(https://mbe.modelica.university/behavior/discrete/decay/#chattering) isn't appropriate, since the function in this model is not continuous?

1
Some more chattering examples are here: github.com/casella/FailureModes/blob/master/FailureModes/…Priyanka

1 Answers

3
votes

The model used in the chattering example isn't appropriate since it is not continuous, and the error message from dassl is just a boiler-plate message, so the model isn't stiff but discontinuous as you found.

Markus A has a good point in the related question When to use noEvent operator in Modelica language? that using noEvent to avoid chattering is in general not a good idea, and one should normally try to rewrite the model instead of adding noEvent.

This specific model is sort of similar to a friction model where you would have

der(v)=(if v>=0 then -1 else 1)+f_other/m;

The solution for friction is not to introduce noEvent, but to add a stuck mode as in Modelica.Mechanics.Rotational.Components.BearingFriction.