Integrators can sometimes appear to ignore the input value, acting as if it did not change. Here, a model is investigated for the purpose of understanding how the solver works and to know how to modify the model or settings so that the model solves accurately.
A simple model that does not generate the desired results
Sometimes models look right but they generate results which look wrong. This simple model below is a good example:
The table in Figure 1 generates a pulse of amplitude 1 between 5 and 6 seconds. Interrogation of the results however, reveals a problem. When this model is simulated for 10 seconds with an outputInterval of 1 using the DASSL solver, the resulting integrator signals looks like those in Figure 2 below.
![Figure 2. The integrator.u and integrator.y signals generated. The integrator.y signal stays at zero even though the input becomes 1 at 6[s].](https://www.claytex.com/wp-content/uploads/2020/05/IntegratorSignals.png)
Why is the integrator ignoring integrator.u?!
Results presented in Figure 2 are strange. Let’s investigate what is occurring with this model, beginning with the simulation log.
The simulation log in Figure 3 reports that 14 steps were accepted. Therefore, 14 steps were calculated by the solver, where the solver error measure was acceptable (see a-closer-look-at-solver-tolerance for more details on what a solver error measure is). These accepted steps are referred to as solver steps in this blog post as no rejected solver steps are present in this example.
11 grid points are present in the simulation log. The grid point steps are run to generate results at the desired output interval. These grid point steps are referred to as output steps in this blog post. See understanding-the-simulation-log-basics for more details on the simulation log.
Examining when the steps are run
To better understand what is going on, knowing the simulation times at which the solver steps and the output steps occur is useful. In order to generate this data, the following flags were set in the Dymola command line:
Advanced.DymosimRealTimePriority=true;
Advanced.Define.PrecisionTiming=true;
Advanced.GenerateTimers=true;
Then the model was simulated again and in the working directory the plotTimings.mos was generated:
Interpreting the times array
By looking at the times array in Figure 4, we can determine when the accepted solver steps occurred and when the output steps occurred (i.e. the grid point steps). These are presented in Figure 5.
So, what is going on?
When a solver is run, the solver steps start with small increments and then increase until the error measure exceeds a tolerance, an event is generated or the simulation is finished.
If a solver step is larger than the next output step, then an output step is run. Looking back at Figure 5, we see that there is a solver step at 0.511[s] and then at 1.023[s]; the solver then runs the output step at 1[s]. This behaviour is described by the flow diagram in Figure 6.
Signals at the output steps are calculated by running the simulation equations at the output intervals and the states are interpolated from the solver steps solutions. This is key; in this simulation, at every solver step the integrator input is zero. No solver steps occur when the table output is non zero. So the integrator.y state is interpolated to be zero at the output steps. Incredibly, the solver has in effect missed the system dynamics of the model!
How do you stop this issue occurring?
There are two methods described here to avoid this issue. The first is to use events; the other is to set a limit to which the solver steps can be incremented.
Add events
A good way to ensuring the model is accurately solved is to include events at the start and the end of the pulse. This forces the solver to run at these exact times resulting in the pulse being accurately integrated. In a non-intuitive twist, adding events in this way will often decrease the computation required to solve the simulation, when a variable step solver is being used. For our example model, a Modelica.Blocks.Sources.TimeTable block can be used instead of the Clock and CombiTable1D blocks as in Figure 7.
Set the maximum solver step increment
The maximum solver step size can be set using Advanced.Simulation.StepSizeMax. For example, setting the following in the Dymola command line limits the solver step size to 1 ensuring that the pulse width would be detected in the example in this post:
Advanced.Simulation.StepSizeMax=1;
How concerned should I be that this may happen in my model?
Typically this issue does not occur in complex models because the time step does not get large enough. The time step remains fairly small as the derivatives of states in a complex model typically vary significantly and events occur which limit the size that the solver steps are incremented at.
The checkDerivatives() function in the VeSyMA-DiL library checks derivative signals by comparing them against the estimated derivative value calculated using the states in the model. This function could be used to determine if the issue described was occurring.
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