State events and fixed-step solvers

[paultjevdh]

Hello all,
I've been looking through the standard, but couldn't find it: does anyone know if the standard says anything about event searching and fixed-step solvers?
If I take the bouncing ball model from https://mbe.modelica.university/behavior/discrete/bouncing/, and simulate it with openmodelica, it will insert events (=samples) at the bounces, even if the integration method is fixed-step.
Dymola on the other hand is rigorous in its definition of fixed step and only detects the bounce at the next step on the predefined grid.

Should the simulator search for the events and temporarily ignore the fixed step restriction, or is the fixed step condition leading and should the event thus be shifted to the next sample on the grid?

Best regards,
Paul van der Hulst

[HansOlsson]

The specification doesn't state anything specific about how integrators work, including fixed step solvers.
The goal is that the numerical solution should be as close as possible to the ideal hybrid solution.

Note that the Dymola's handling is more advanced than described above.
It does handle the event at approximately the correct time-point (not only at grid-points), but also adjusts the time to have it on the predefined grid to make it usable in external environments that only handle values at the time grid.

See SAE 2004-01-076 "Realtime Simulation of Detailed Vehicle and Powertrain Dynamics" by Hilding Elmqvist, Sven Erik Mattsson, Hans Olsson, Johan Andreasson, Martin Otter, Christian Schweiger, Dag Brück - https://elib.dlr.de/12173/1/otter2004-sae-realtime.pdf

[paultjevdh]

I'm not convinced that dymola is as smart as you say.
With dassl and 50 intervals over 1 sec, the bouncing ball model returns:

This result was obtained with 32 accepted steps, 51 grid points and 55 result points.
Analytically calculated time for the first bounce is 0.4515236 sec which is what is found in this simulation.

With rk4 (20msec fixed step = 50 intervals in 1 sec), the same model returns:

This result was obtained with 50 accepted steps, 51 grid points and 53 result points.
The bounce is visibly later and less high.
It appears as if Dymola just postponed the event to the next grid point at t=0.46sec. If dymola does something smart, it does not end up in the output, and therefore seems pointless to me.

OpenModelica with runge-kutta inserts an intermediate point at t=0.451415sec, which gives the correct output.

The output may not be strictly equidistant, but the simulation result is certainly closer to the ideal hybrid solution.
I would expect Dymola's 'smartness' to match this.

[HansOlsson]

That trade-off for the relevant use-case for fixed-step solvers (i.e., real-time simulation) is explained in paper. If you are just interested in getting a good plot I would advise against using fixed-step solvers.

[AHaumer]

Without testing, just a quick idea: Wouldn't "Store variables at events" make a difference?

[AHaumer]

See enclosed: OM without "Store varables at events".

[paultjevdh]

This is how I would expect dymola to behave. It is clear that this simulation evaluates the event at the correct time, while not violating the equidistant output requirement. At its worst it is just undersampling the output.

As for what I'm interested in: accurate simulation, with correct output values at the output time grid, also after an event. The plot provided by AHaumer shows this. The dymola plot does not, since its output after the event deviates depending on the simulation method.
Regarding the paper reference, if the mention on page 2 of events is meant, that is hardly an explanation. It claims that 'in case of an event the step size is decreased to hit the time of the predicted event. In order to synchronize with realtime again, the size of the next step is increased'. This implies that the output is calculated at the event, and output at a later time (when the next sample is due according to the constant time step). Apart from that I think this is not correct, this described behaviour is not visible in my provided dymola example. Instead it only seems to evaluate the event at the next fixed step, not searching for the event at all.

[HansOlsson]

This discussion isn't going anywhere.
Fixed-step solvers in Dymola are for actually handling realtime simulations (where doing several times more work at a sampling point to get slightly better result isn't feasible); and support for tools is handled through support-channels.

[paultjevdh]

I agree that this is going too much into details of specific tools. I'm happy to take this up with the tool manufacturer, once I work out what the standard says and implies.

What I'm trying to work out is the following: is root-finding in state event handling mandatory or optional according to the specification?
The point of events is that they typically do not occur at projected sampling instants. In section 8.5, the standard says: "[A root finding mechanism is needed which determines a small time interval in which the expression changes its value; the event occurs at the right side of this interval.]". The standard makes no reservations for any (integration-)implementation.

My conclusion is that the implication is that root finding is mandatory, irrespective of integration method, but I would like confirmation from people who understand the jargon better.

[henrikt-ma]

I agree that root finding (or equivalent approaches) is a necessity when it comes to defining the ideal solution to the model equations. In practice, tools offer a whole bunch of choices of methods and tolerance parameters, which can be tuned for different applications and performance objectives, but it is beyond the scope of the specification to say what the corresponding approximations of the ideal solution are supposed to be.

Not even the experiment.Tolerance parameter defined in the specification has a clearly defined effect on the approximation of the ideal solution, since its effect will depend a lot on the choice of integration method. Neither does experiment.Interval have a clearly defined effect.

[paultjevdh]

Thanks

[paultjevdh]

I guess that the bottom line is that the standard only defines the language, which is completely independent of any implementation.