A closer look at Dymola events

The Dymola solver implements events that may be in a model to allow it to solve in an accurate way. This post has a closer look at how this is implemented.

What is an event?

When discrete behaviour occurs in a model an event is generated, or to say the other way events cause discrete behaviour.

A simple example of an event is:
y = u >= 0.5 (1)

In the example when the continuous signal u goes from smaller to larger than 0.5, y changes discretely from false to true, at this time instance and an event is generated. An event is also generated when u goes from larger to smaller than 0.5.

The different types of events that can occur are:

Time events – Events that are dependent only on time, for example y = time >= 0.5. [1]

State events – Events that are dependent on state variables used in the model, for example der(s) = s>=0.5 then 0.1 else cos(s).

Step events – occur when dynamic state selection occurs in the model.

Input time events – occur when a discrete change occurs in the input signal of a model, for example if dsu.txt is being used as the input to a model (see Simulating models with dsu.txt for more details).

How does a variable step solver find when events occur?

When a model that contains code that can generate events is translated, the event conditions are extracted from the model and added to an events trigger list. Setting Advanced.Translation.Log.EventExpressions=true results in the event generating expressions being printed to the translation log.

In example (1) the code y = u > 0.5 can generate events. In this case u – 0.5 would be the event trigger and is added to the trigger list. When this trigger is negative this corresponds to the condition being false, if the condition is positive the condition is true.

With a variable step solver the step size is adjusted so that the event occurs exactly at a simulation step (i.e. when the condition is zero).

Time and input time events

For time and input time events the event simulation step can be calculated in advance, at a given simulation time.

State events

For state events the simulation time that the event occurs at is searched for. This search is an iterative process that is started when an event trigger changes sign. The search is done with the results obtained as if the condition has not occurred yet. Once the simulation time, where the trigger is zero, is found then the model is simulated with the condition changed. And finally, this is run again to check for consistency (i.e. that once the condition has changed this does not result in the condition immediately changing back again). This iterative search process can be seen in Figure 1.

Figure 1. Flow diagram for event handling with a variable step solver.

Figure 1. Flow diagram for event handling with a variable step solver. Flow diagram created with code2flow

If the consistency check fails then an error is generated. An example of the event handling can be seen in Figure 2.

Figure 2. Event handling example based on event der(s) = s>=0.5 then 0.1 else cos(s)

Figure 2. Event handling example based on event der(s) = s>=0.5 then 0.1 else cos(s)

In Figure 2 the s >= -0.5 condition is false at first and the model continues to simulate until the event simulation time is overshot and s – 0.5 > 0 ; then event simulation time is searched for. Note that the condition is not changed yet and the der(s) = cos(s) equation is still used. When s – 0.5 == 0 is found then the condition is updated, the event consistency is checked and the simulation continues.

Step events

Step events appear to work in a similar way to time events in that it detects when the conditions are present for states to be swapped and perform the swapping without searching.


This post looks at how events are handled by a variable step solver. A follow up blog will look at how fixed step solvers are dealt with.


[1] Note that for some reason time events have to use time >= and time < , using time > and time <= will cause state events to be generated. Setting Advanced.Check.StyleTimeEvent=true will cause a warning to be generated saying which comparison should be used so that a time event will be generated rather than a state event.

Written by: Garron Fish – Chief Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion


Got a question? Just fill in this form and send it to us and we'll get back to you shortly.


© Copyright 2010-2024 Claytex Services Ltd All Rights Reserved

Log in with your credentials

Forgot your details?