April 26th, 2016 by Mahdieh Mehrabi
Often in modelling, we want to identify which parts of the model are causing the simulation to run slow. For example, we might notice that the simulation is getting stuck at a particular time or points during a simulation.
State variables and related variables which fluctuate at a high frequency can cause the simulation to become stiff. One solution is to try and damp such behaviours to reduce the oscillatory behaviour if undesired.
In filters for example, a highly fluctuating input can cause the filtering to become computationally intensive. If the fluctuations are unrealistically high and we tune the source of the fluctuations to become more stable, then the system could potentially run faster.
If using PIDs, if the output of a PID is highly oscillatory and this signal is used to drive a physical system, the solver will resort to smaller time steps to calculate the transients accurately.
Many more examples exist, these are just two to help illustrate potential issues. However, if the fluctuations are representative of the physical description of the component, this approach is not particularly suitable.
To find out which state calculations are dominating the timestep size and error in the model we can enable “Which states that dominate error” within the Experiment Setup debug tab (Figure 1).
Figure 1: Screenshot showing location of the function “Which states that dominate error” within the Simulation setup.
Once the simulation has terminated you will be able to see the analysis results within the Simulation tab of the Messages window (Figure 2).
In this example we have simulated the model Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater. From the statistics we can see that the calculation of the fluid property h is causing the solver to reduce the step-size and dominates the error at each time step.
By investigating the state variables, which feature with the highest counts, we can isolate the problem areas of the model which are causing the simulation to run slowly. Rapidly changing states will usually have a high number of instances for step size limitation and error domination.
For more information, including model debugging whilst the simulation is running, please see section 5.7.4 Debug facilities when running a simulation 653 of the Dymola User Manual Volume 1 and also the following blog posts:
Figure 2: Example of result within Simulation log after enabling “Which states that dominate error”, then simulating.
By: Alessandro Picarelli – Engineering Project Manager