# Understanding the simulation log basics

When you run a Simulation in Dymola, a Simulation log is generated and displayed in the Simulation tab of the Dymola Messages window.  For example: Figure 1: Simulator log table example. Stores the general information

The statistics listed above can be considered the key performance indicators of the simulation computational performance. It should be remembered that these statistics concern the numerical execution of the model compiled by Dymola, rather than detailing information regarding the structure and composition of the compiled model. Information regarding the compiled model architecture and structure can be viewed in the Translation tab of the Dymola Messages window.

Often there is information in the Simulation log before Figure 1; this is general information such as warnings or reports of unusual simulation behaviour. Users can also program their own messages to appear here if a certain condition is reached within the simulation by utilising a print statement contained within an if statement. Furthermore, messages generated by the failure of an assert statement are also reported here, minus the simulation statistics presented in figure 1, as the simulation was forcibly stopped from completing.

So what do the statistics presented in the Simulation log upon completion of the simulation actually mean? General definitions of each variable are presented below. Further definitions of these statistics are useful to know, in order to be able to correctly interpret the simulation results and understand its performance.

Grid points define the locations where data is stored in the simulation results file (the trajectory file issued to the working directory by Dymola with a mat extension upon ending of a simulation). Typically, they are stored at equidistant locations determined by the interval or the number of intervals set in the Output interval group of the Simulation Setup.

Result points are stored locally, being interpolated to calculate the grid points.

Steps are the number of intermediate steps the solver has calculated in order to determine the next result point.

F-Evaluations calculate the gradients of the states in the model based on the symbolic equations in the model.

H-Evaluations are the number of times the crossing functions were calculated (these are functions used to determine if an event has occurred). Models with elements which rapidly switch between states (such as a brake locking and unlocking rapidly) will typically generate large numbers of H-Evaluations during simulation.

Numerical Jacobians are used by certain solvers to calculate the value of a derivate of an expression which Dymola cannot automatically solve. The solver requests a Jacobian evaluation from the model when required, for example the Dassl solver makes a lot of Jacobian evaluation requests and the Euler solver makes none, so it is dependant on how the solver works.

(model) time events detail each time a real elementary relation changes its value, for example if the threshold time>=2 becomes true. Time events are only generated if the relation involves the variable time.

(U) time events detail events which occur within inputs to a model, for example in dsu.txt.

State events detail each time a real elementary relation changes its value, for example if the threshold x>=2 becomes true. State events differ from time events, as any variable termed a solution variable can be used to generate a state event. Dymola will stop the onwards time integration and iterate steps to determine the precise time a threshold switches between states (such as a Boolean true and false).

Step events are generated when a simulation with a dynamic state selection switched state. Dynamic states in models are related to the state selection conducted by Dymola during the translation of the model.

For more information on state events and time events check Section 3.4.2 of Dymola User Manual Volume 1. For information on state selection please see State Selection: Overview and Definitionswith more information available on numerical Jacobians here.

Written by: Garron Fish – Chief Engineer