Profiling

Dymola provides a means to measure where the CPU time is being spent in the model code execution. This feature is known as profiling. Profiling is described in Section 5.7.5 of the Dymola User Manual Volume 1.  This blog article supplies further information.

Profiling is implemented by inserting timers into the dsmodel.c code so that the amount of time spent computing different sections of the code can be recorded. To enable profiling in Dymola set either of these flags from the Dymola Command line:

Advanced.GenerateBlockTimers=true;
Advanced.GenerateTimers=true;

When Advanced.GenerateBlockTimers=true a few timers are inserted in the code when Advanced.GenerateTimers =true a large number of timers are inserted and this allows finer analysis of the code’s performance.

An example of the profiling information that is returned when a model is simulated is in Figure 1.  These results were generated by simulating the Modelica.Magnetic.FluxTubes.Examples.SaturatedInductor model for 10 seconds using DASSL and with Advanced.GenerateBlockTimers=true.

Figure 1. Profiling information for model

The 1st column in Figure 1 gives the name of the timing block. For further information about the different types of timing blocks refer to Table 1 found at the end of this blog post.

The Block number (column 2 in Figure 1) makes it easy to find where the timers have been inserted into the dsmodel.c code. To find the start of the timer search for DymolaStartTimer(#) and to search for the end of the timer search for DymolaEndTimerName(#), where # is the Block number.

Columns 3 to 6 contains timing information, from the results in Figure 1 most of the CPU time is spent calculating the simulation.nonlinear[1] system.

How often a section of code is called (i.e. column 7 of Figure 1) is important as improving the performance of the code with the largest number of calls will give a large performance improvement. A basic flow diagram of how a time step calculation is performed is in Figure 2, this diagram helps explain why different code sections are called a different number of times.

Figure 2.  Simple flow diagram of how the model code in dsmodel.c is called when solving a time step calculation. The blue blocks are model code, red blocks are controlling code and yellow blocks are comments. The flow diagram was created using code2flow.com.

The flow diagram in Figure 2 is of the control of the calls to the model code. The controlling code will call the InitialSection, the OutputSection, the DynamicsSection, the AccpetedSection1 and the AcceptedSection2 code of dsmodel.c.

If initialisation fails the first time then the homotopy method is used and the InitialSection code will be called multiple times as the homotopy’s lambda value is increased to 1. Once the model has been initialised successfully then the IntialSection code is not called again.

When an inline solver is used then the states are updated within the dsmodel code, in this case there is no DynamicsSection and only the OutputSection code. If an inline Runge Kutta method is used then the OutputSection code will be called multiple times depending on the order of the Runge Kutta.

When the DASSL solver is used the DynamicsSection code is called multiple times until the solution calculated by the solver satisfies the solver’s requirements.

In some cases the controlling code can detect that the states are non-changing for that time step, in this case there will be no call to the OutputSection and the DynamicsSection code and the states will remain unchanged.

The AcceptedSection1 code contains code that does not directly affect the derivatives of the states, however, the past values of this code may affect the derivatives. An example of code that may be found here is the pre() functions used in logic expressions. The AcceptedSection2 code contains equations for calculating model variables that are dependent on the states of the model.

There are many possible locations in a time step calculation where the code may fail, these failures have not been included in the flow diagram in Figure 2 to keep the flow diagram as simple as possible.

 

———————————————————————————————————————————————————————————-

Name of block timer Comment
AcceptedSection1 Code for which past values effects the OutputSection and DynamicSection equations.  For example the pre() equations.
AcceptedSection2 Typically auxiliary variables that are not required by the OutputSection or DynamicsSection
Asserts Calls to the assert() function
Auxiliary code Calculates variables that are not directty required by state update process
Code for h fixed Code specific for a fixed time step, typically used with fixed step solvers to solve the first time step
Code for h variable Code specific for a range of times steps, typically used with a fixed step solver
Crossing code Used for detecting events
DynamicsSection Equations to calculate the derivatives of states used by solver to update states
Dynamics code Code part of the dynamics section
Empty timer Used to calculate how long the timer code takes
Entire model Total time for all evaluations
Event handling The total time for model evaluations during event handling.
Initial # eq A system of # equations in the initial section
InitialSection Initialisation code
initialization.linear[#] Initialisation code for linear system #
initialization.nonlinear[#] Intialisation code for nonlinear system #
Inline Update Meant to calculate the how long the code used to control the inline solver takes, however it is calculated in a questionable way
Inlined sys System of equations that are a result of inlining
Lin sys Jac Jacobian used by linear system of equations
Lin sys solve Calls to linear system solving functions such as SolveLinearSystemOfEquations(J, b, y, 1); and similar equations, inside Lin sys total
Lin sys torn Linear system torn section, inside Linear system total, inside Lin sys total
Lin sys total Linear system
Mixed sys Mixed system of equations, equations involving Boolean and Real equations
Nonlinear residue Time taken to calculate residues
Output # eq Output code for a system of # equations
Output code This code includes the assert calls, and can include when equations and more.  Code to update the internal states of an inlined solver
OutputSection Section of all the output code
Outside of model The total time spent outside of the model code
Parameter code Assigning parameters, includes reading variables from files, string variables etc.
simulation.linear[#] Linear system number # in the simulation section.  Only equations that have been expanded out are labelled with the simulation.linear[#] method
simulation.nonlinear[#] Nonlinear system number # in the simulation section
Structured Jacobian Calculation of structured Jacobian
Structured residual Calculation of residual of structured Jacobian

Table 1.  Explanation of some of the timer block names

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

CONTACT US

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

Sending

© Copyright 2010-2018 Claytex Services Ltd All Rights Reserved. | Designed by CMA Marketing

Log in with your credentials

Forgot your details?