The Run statistics pane

Run statistics pane

The Run statistics pane displays information about the solver. It provides all the indicators from the Run stats component (remember that you need to have this component on the sketch).

The main objective of this tool is to identify when specific events are slowing down the simulation during the run.

Figure 22: Run statistic pane

Note

Any variable displayed in Run statistics can be plotted independently by dragging and dropping the variable name onto the Simcenter Amesim sketch

Figure 23: Dragging and dropping variables from the Performance Analyzer

We will now explain each variable available in this pane in detail:

CPU time

CPU time

This information will be used to evaluate the performance of the simulation and identify times when the simulation is slowing down.

It is the real CPU time of the simulation process. This means that it will not be influenced by the other processes running on the computer at the same time.

It is interesting to observe the CPU time evolution against the simulation time. This plot is automatically shown in the upper part of the Run statistics pane. What information can you get? When the slope of the curve is increasing it means that the simulation is slowing down, when there is a visible step it means that the solver has been working hard to solve the current set of equations at that moment of the simulation, and every time the slope of the curve is decreasing it means that the simulation is speeding up.

Finally the position of that curve compared to the virtual identity curve (y=x) gives an idea of the real time performance of the model. Here real time means that 1 second of the simulation time is solved in 1 second. If the CPU time curve is below the identity curve the model is faster than real time and if its above it is slower than real time.

Figure 24: CPU time curve compared to identity curve

In the plot above, the red curve is the CPU time and the green curve is the identity curve which would be the real time reference. We can see that until 12 seconds the model is fairly rapid and solves faster than real time. After that moment the simulation slows down. That indicates that something is happening in the model after that moment.

Elapsed time

elapsed time

This is the time elapsed between the start and the end of the simulation process (also called wall-clock time). It will, therefore, be influenced by computer activity during the simulation and if the computer is busy with other processes then this time could increase significantly. By comparing the CPU time and the elapsed time you can see if the time is spent by the Simcenter Amesim solver or by other processes. This can be very useful for cosimulation models.

log 10 of current/minimum/maximum integration step

current integration step

log 10

minimum integration step

maximum integration step

These variables are plotted in the lower part of the Run statistics pane and they respectively represent the current integration time step of the solver at any instant of the simulation, the minimum integration time step and the maximum integration time step. The Simcenter Amesim default solver uses a variable step size to perform the integration of the differential equations of the simulated model.

When the current integration step is decreasing it means that the solver is finding the model difficult to solve and you can expect the simulation to slow down. Basically the solver is taking very small time steps to try and solve the equations.

Note

The current integration step is plotted at a resolution given by the Print interval value and the eventual discontinuities when they are printed, hence, most of the time it may not show the minimal values taken by the solver which may happen at any instant between the actual points which are printed in the result file. This is where the minimal integration time step becomes useful; it will always register the minimal value since the start of the simulation taken by the integration step and independently of the print interval. The simple example analyzed in the first part of that manual illustrates this point.

Figure 25: Difference between current and minimum integration steps

You can clearly see that although the current integration step doesnt seem to go lower than 10-8 s the minimal one jumps down to 10-12 seconds after 12 seconds of simulation. This means that around that time the solver did take at least a very small time step.

log 10 of minimum/maximum integration step since last print

minimum integration step since last print

maximum integration step since last print

These variables can be manually plotted with a drag and drop into the plot area or on the sketch. As explained in the previous paragraph the current integration step is the integration step at the exact moment when the results were saved. These new variables allow you to visualize what the integration step is doing between these saving instants. They give the envelope of variation of the integration step between two print instants. When the envelope is wide it means that the solver is working hard or that there are a number of discrete events or that the model is highly nonlinear. A tighter envelope means that the solving process is fairly smooth.

Figure 26: Minimum and maximum integration steps since last print

In Simcenter Amesim, the calculation of the integration time step is automatic and as a user, you do not need to interact with this calculation. In some specific situations it is possible to set a maximum integration time step value. Refer to Section 4, "Maximum time step" of the document Discontinuity Handling for more information. This setting can be adjusted in the Run Parameters.

Figure 27: Access to technical bulletins

Figure 28: Setting a maximum integration time step

Current total number of function evaluations

current total number of function evaluations

When a simulation model is solved a number of functions are called; these include calls to all the submodels routines and calls to the integrator. This information computes the total number of function calls during a simulation including each solver step, successful or failed solver steps, calls for Jacobian calculations, and calls to print routines.

Current total number of Jacobians

current total number of Jacobians

This information gives the number of evaluations of the Jacobian matrix which is needed when using the BDF solver. A Jacobian calculation is always very expensive and a very high number of Jacobian calculations means that the system is numerically unstable especially when it is compared to the total number of BDF steps. In general you should not have more than one Jacobian calculation every three BDF steps. If this is not the case there must be something abnormal in your model; too many Jacobians can also mean that discontinuities are not handled properly. This can happen if you have written your own user-defined submodels.

Current total number of discontinuities processed

current total number of discontinuities processed

As we have seen before, this must be closely monitored. A high number of discontinuities will definitely slow down the simulation. Always try to identify where the discontinuities are coming from and assess whether it is possible to reduce this number.

Current total number of steps

current total number of steps

This variable gives the total number of successful solver steps.

Mean CPU time per function evaluation

mean CPU time per function evaluation

This is a measurement of the cost of the simulation model, independently from its solving part. Here, cost is in terms of time to evaluate. The higher the number is, the more complex the model is to evaluate. A high value could mean that there are some iterative schemes within the submodels which could be difficult to solve, in this situation the number of Jacobians will probably also be high. In general this time decreases shortly after the start of the simulation, this denotes the cost of the initialization of the model. You can use this measurement to assess how your user-defined submodel is performing.

Mean CPU time per step

Mean CPU time per step

This is a measurement of the cost of the solving process. It gives the total number of successful and failed steps, the Jacobian calculation and the influence of the tolerance both for the global error calculation and the local discontinuity handling. It can be compared with the previous number; when the evaluation of the model becomes more expensive than the solving there is probably something wrong going on.

Total number of Adams steps

total number of Adams steps

In order to solve the simulation model, the solver will switch between different integration methods. The Adams method is used for explicit systems, it is usually considered as an "easy" integration.

Total number of BDF steps

Total number of BDF steps

The other type of integration method used by the Simcenter Amesim solver is a BDF integrator and it is used for stiff, oscillatory, or implicit systems.

Number of Adams steps of order (1..12)

number of Adams steps of order (1..12)

When the order is increasing it means that the system is easy to solve. Usually this happens when the tolerance is smaller. When this is the case the Simcenter Amesim solver will look for maximum accuracy and hence, increase the order. But if the system is not so easy to solve it becomes more advantageous to use BDF methods. This vector gives a decomposition of the Adams steps according to their order.

Number of BDF steps of order (1..5)

number of BDF steps of order (1..5)

This informs you about the BDF solver steps and similarly to the previous one, it gives a precise decomposition according to the order used. Remember, you can always plot these variables in order to see the detailed evolution during the course of the simulation. When the model highlights a high number of BDF steps with order 1, there is usually something wrong with the model or with a submodel inside the model.

In most situations, you will check the CPU time, the current/minimum integration step and the number of discontinuities, but for an advanced user who is using user-defined submodels, the other information also becomes relevant.

Note

In most situations, check:

• the CPU time curve,

• the number of discontinuities,

• the current and minimum integration step.

If you have written code for user-defined submodels, also check the other variables.

In the following section you will learn about the State contributions pane.