#
Solver-Related Warnings and Error Messages

The following section extends "Troubleshooting: What should I do if...".It describes the handling with warnings, error messages and selected problems occurring during the simulation with BDF and MEBDF. For debugging and troubleshooting it is recommended to repeat the following sections of section "Analysis".

and to know the used terminology .

The following pre-determinations are valid

- Tracing can be activated as described in the section on tracing. The relevant tracing item will be referred by its name, e.g. Solver/States
- The use of the parameter
`traceOn`

is described in the section "Tracing". - See "Solver Settings" for further simulation parameters of menu
*Simulation/Transient Settings…/Solver/Further Parameters*. The relevant parameters are referred to by their names, e.g.`dblResRelError`

.

## Internal Solvers (BDF and MEBDF)

Warning: The parameter … has no start value, 0 is assumed.

Show more ...Parameters without a value are interpreted as zero. You may ignore this warning if you are sure that the value zero is entered for all empty parameters. When you expand this message, all respective parameters will be displayed.

Warning: System is singular!

Show more ...This warning usually indicates a modeling error or an unfavorable model structure. It is displayed when the Jacobian matrix of the model is structurally singular.

#### This is the case, for instance, if:

- Zero lines occur: No state variables and no derivatives are entered in the equation.This case exists, for instance, if electric connections are switched off through ideal switches, i.e. if they "are in limbo". floating potentials, node potentials
- Zero columns occur: There is no equation for the respective state variable and its derivatives.
- Columns with only one entry which is not zero occur twice: There is only one equation for two state variables or their derivatives.The third case occurs most frequently. Reasons could be:
- Constraints connected in parallel (use just one constraint instead),
- Rigid frictions connected in parallel (use just one friction element which contains the sum of the static and sliding friction forces of the two original frictions
- Rigid end stop in parallel with rigid friction (use the built-in friction of the end stop instead)
- over-determined multi-body models,
- parallel-connected voltage sources,
- series-connected current sources.

#### For the analysis:

In the expanded trace message the following additional information is provided for each singular part of the model:

- The number of equations and the number of states (smaller than the number of equations), where all other states and their derivatives do not contribute to the selected equations.
- The number of states and the number of equations (smaller than the number of states), where the selected states and their derivatives do not contribute to other equations than the selected ones.
- When the number of states and equations are equal, both messages are shown and are marked as (a) and (b).

#### Zero columns and zero rows

- For columns with only zero values no equations were listed. For rows with only zero values no states were listed. This can be reviewed if the tracing for
*"Solver"*→*"Jacobian"*is turned on and the two Jacobian matrices dF/dY and dF/dYP right before the appearance of the singularity warning are observed. Therefore these matrices have to be understood as being placed "on top of each other". Zero rows or columns will show only zero elements in both matrices (if required, the tracing can be restricted using the parameter`traceOn`

). - The states involved in the singularity can also be searched in the model directly from the tracing message (see section "Tracing").
- In order to find out the assignment between an equation name and the equation itself, the symbolic Jacobian generated during the symbolic analysis can be used (enable
*"Equations"*→*"Symbolic Jacobian"*).

Event iteration stopped.

Show more ...This message occurs when the calculation was stopped by the user with the *Stop* button during an event iteration.

The calculated initial state does not meet my expectations.

Show more ...Check whether you have entered and fixed your initial values (see section "Calculation of Consistent Initial Values". Free initial values merely serve as start values for the iterative calculation algorithm. In general, they are changed by the program.

Error: Exception during the calculation

Show more ...The exception during the calculation (usually during the calculation of the residuals, rarely during the calculation of the derivatives or in the DAE solver) aborts the simulation.

The first two cases are easier to debug. It is recommended to restrict the tracing output by the parameter `traceOn`

(e.g. time > 0.56). The analysis of the tracing output of *“Equations"* → *"Calculation of the equations”* and *“Equations"* → *"Calculations of partial derivations”* may reveal the error cause that is displayed at the bottom of the last expanded trace. This error may then be backtracked. Some additional solver information (“Solver" → *"Failed Steps"* → *"Details”*, *“Solver"* → *"Successful Steps"* → *"Details”*, *“Solver"* → *"States”* or *“Solver"* → *"Residual Vectors”*) may be useful for structuring the trace output. Mostly the model equations need to be modified. In some cases the error is due to invalid values of state variables. Then it is advisable you set the attributes `min`

, `minNotReached`

, `max`

and `maxNotReached`

of the relevant state variable to its feasible region.

Calculation of equilibrium stopped

Show more ...This message occurs if the calculation of the equilibrium was stopped by the user with the *Stop* button.

The time domain simulation takes very long.

Show more ...Check your model and the simulation environment for possible optimizations.

Long computation times may have the following reasons:

- Extensive models
- Strongly non-linear models
- High eigenfrequencies in the model,
- Frequently occurring events (discontinuities)
- The computer hardware capability is not sufficient

#### a) Large models always need longer calculation times.

Follow the following principles in modeling: Create models which are not too detailed. Tailor your models for the computation task. Use the libraries for modeling. The modeling of physical systems by means of signal blocks is often inefficient and prone to errors. More complex relationships (control algorithms, behavior models...) are frequently imaged with complicated signal structures. This can usually be done simpler and more efficiently using Modelica® for programming. ITI GmbH has rich experiences in efficient modeling of complex systems. Make use of these experiences.

#### b) If you deal with highly non-linear models, it is important that you scan spots where slopes change highly, with a small step size.

Check whether the model can be linearized. Another option is to model the high change with a characteristic curve which has a kink. This method has been applied, for instance, to the electric diode.

#### c) To find out whether the model has high natural frequencies, start the natural frequency analysis

As long as a model part oscillates with a frequency in this range, you must use small step sizes for your calculation. Only after they have decayed sufficiently, the advantages of the “stiff” BDF method take effect. Stiff model parts can often be modeled as ideally rigid or a model reduction can be performed.

#### d) Event time instants are determined exactly with the step size control. The continuous integration is stopped and the model is reinitialized

All these steps need time for calculation. Therefore, try to create as few events as possible. The occurring events can be traced by *“Discontinuities"* → *"Sign Change of Zero Functions”*. When you work with characteristic curves, an event will be created at every sampling point in linear and staircase interpolation. You can reduce the number of events there by:

- reducing the number of sampling points,
- using spline interpolation, arc, hyperbolic or quadratic approximation, or
- activating "No Handling of Discontinuities" (if possible).

#### e) Refer to the hardware requirements of SimulationX

If you log a very large number of result variables and only little main memory is available, the results are entered during the computation in the dislocation file on your hard disk (cf. section "Storing"). The frequent accesses slow down the computation highly. >In this case, you should:

- clear storage of the main memory (menu “File" → "Options" → "Storage”),
- reduce the number of events to be logged,
- increase the value of the minimum output step size
`dtProtMin`

.

#### Other reasons for low computation speeds

- Multiple event windows
- Multiple visualizers
- Many tracing outputs (output window)
- Animation of complex 3D models on a graphics board without 3D hardware acceleration

#### Examination of slow simulations caused by the solver:

- At the end of a simulation the computational effort can be recorded (tracing option “Solver" → "Summary”). Here you can see if there have been many discontinuities or many invalid steps, which are one reason for a slow simulation. Beside this, frequent limitations and resets of the time step size below the maximum time step size due to zero functions as well as due to the error estimation during simulation will cause many successful steps and are another reason for slow simulation. Reviewing the protocol of the result quantity
`dt`

(current step size; accessible through the Model Explorer or the properties window of the model) allows to identify the critical time intervals. Therefore the Minimum Output Step Size`dtProtMin`

should be sufficiently small, so that all step sizes of interest will be displayed. - Using the (ME)BDF solver most of the computation time is usually required for the computation of residuals. Therefore the number of residual computations is a good measure to identify intervals of slow simulation speeds. The number of residual computations is stored in the 7th component of the
`solverInfo`

vector (accessible through the Model Explorer or the properties window of the model). The interesting time intervals will show a significant increase of residual computations. - The identified critical time intervals can now be entered into the
`traceOn`

parameter of the model in order to allow a closer examination. - In case that many discontinuities appear, this can be traced using the tracing option “Discontinuities" →
*"Discontinuities”*. The reasons for the discontinuities can be identified by tracing “Variable" → "Value Change of Discrete variables” and “Discontinuities" → "Sign Change of Zerofunctions” also. In order to only identify the time instants where discontinuities take place, the 8th component of the`solverInfo`

vector (accessible through the Model Explorer or the properties window of the model) can be examined. For this`dtProtMin`

should be at maximum equal to`dtMin`

. For very small intervals between discontinuities`dtProtMin`

should be set to`dtDetect`

. - In the case of many invalid steps additional information can also be collected from the
`solverInfo`

vector. Of interest are the components 3 (number of not accepted steps, either failed or not accepted due to discontinuities), 4 (number of failed steps with too big error estimation) and 5 (number of failed steps due to insufficient convergence). The result window displays their number between the last successful step and the current successful step, so the Minimum Output Step Size`dtProtMin`

should be set sufficiently small. Failed steps can also be recorded in the tracing (tracing option “Solver" → "FailedSteps" → "Details”). The tracing allows finding out the reason for a failed step. The problem examination continues as described for the respective errors in the examined interval. - The tracing of the limitation of the solver step size due to zero crossings is shown by (“Discontinuities" → "Time Limitation due to zerofunction estimation before a step and Discontinuities" → "Time set back due to sign change of a zerofunction after a valid step”).
- If none of the above reasons applies but nonetheless many successful steps with small step size are encountered, the error estimation is the reason for the problem. The 6th entry of the
`solverInfo`

vector should not be significantly larger then 1 (again,`dtProtMin`

should be sufficiently small). The SimulationX Performance Analyzer (menu “Simulation" → "Performance Analyzer…”) identifies the state variables, which force the solver to a small step size. The performance analyzer has first to be activated (checkbox on top of the dialog) and then will record information during simulation. Also check the box for*“Record the values during simulation time”*. After a simulation, critical time intervals can now be observed and the states can be sorted according to their influence on step size reduction. Of particular interest are states, whose influence significantly grows between the start and the end of the observed time interval. These can be examined by opening a result window and observing the interval in question (again,`dtProtMin`

should be sufficiently small). If the quantity is not directly accessible, a general function element (f(x) in the Signal Blocks library) can be used for display. The internal quantity to be displayed is entered as the expression of the general function block. If the strong change of the corresponding state variables is correct, they have usually correspondingly small time steps chosen to represent this quantity with sufficient accuracy. If the corresponding state variables are not interesting for the calculation, then the major changes can be skipped without reducing the time step size. In this case,`discontChange`

can be set to true in the corresponding attributes dialog (see section "Property Window").

Can I be sure that the simulation results are correct?

Computed results do not meet my expectations.

There are built-in tests in the solver methods which verify that the results are correct. These tests refer to the state variables.

Execute a single simulation step to check the state variables and their values (Solver/States).Inexplicable results often occur due to:

- modeling errors,
- the input of incorrect parameters,
- insufficient knowledge of the system,
- wrong expectations,
- insufficient knowledge of the software.

When the solver computes a model without error messages the results should entirely correspond with the model. There are exceptions if error criteria relative and absolute tolerance (see section "General Settings") and nominal values in the attributes dialog (see section "Property Window") of the corresponding variables are not set adequately with respect to the model’s quality or if the step sizes are too large.Then freeze the results and repeat the computation with smaller step sizes and stricter error bounds. When the results do not considerably change any longer the optimum settings were found. Comparative calculations can also be performed by usage of alternative solvers (switch between the BDF, the MEBDF and the CVODE method).

A step is accepted when the convergence test and the error test passed successfully. Both tests use the `tolerance = relTol *`

value of the state `variable + absTol *`

nominal value.

The Convergence Test checks the Newton correction and the changes in the Newton correction during the iteration in comparison to the tolerance (and during the BDF method also the residue value in comparison to the equation tolerance). It estimates the error between the computed result and the exact result of the discretized system.

The Error Test checks the difference between the predictor step and the last corrector step (= sum of the Newton correction during the corrector iteration) as an estimator for the discretization error in comparison to the tolerance. The discretization error is the result‘s deviation for the discretized system from the DAE system. It results from replacing derivations of state variables by difference quotients. For method order 1, the slope of the tangent at the current point is replaced by the slope of a secant. This discretization error has a particular effect when the result curve of the DAE system changes significantly compared to previous results. This requires the step size to be reduced accordingly in order to reflect this in the result.

If the state variable has a great value, the summand `relTol *`

value of the state variable dominates. If the value is small, `absTol *`

nominal value dominates instead. The choice of the nominal value can impact the accuracy of the calculation if the value of the state variable converges to zero. General note on the calculation of tolerance: If the tolerance is set too low, the step sizes become too small and the calculation is slowed down or does not yield any result at all. If the tolerance is set too high, deviations from the correct value may be too great. This may cause subsequent errors due to calculations within invalid ranges.

## Fixed-Step Solver and CVODE Warnings

Quantities which are computed simultaneously inside so called blocks are a particularity of . These blocks correspond to systems of linear or non-linear equations which are solved by a variant of the (iterative) Newton method. The solution can sometimes fail. Then the following error message occurs.

Error: System of equations with the DAE state(s) … cannot be solved!

Error: Equation with the DAE state(s) … cannot be solved!

This message enumerates all involved block variables of the non-solvable block and the iteration step when the solution fails.

An error message follows the above output. It tells us when the error occurs (during the initialization, at an integration step, during the reinitialization after a discontinuity, etc.). That is important to find the block equations inside the tracing *Equations/Symbolic Jacobian*. In most cases one of the following four messages will be displayed before the above error message. They give us more detailed indications why the solution of the block equations fails.

Residual is not in the image of … Jacobian ... with the DAE state(s)

Show more ...This message includes information about the size of the non-solvable block, the involved block variables, the number of the non-solvable linearized equation (if all preceding equations could be solved) and if the Jacobian has only one column the values of Jacobian and the residual.

Select the tracing "Equations" → "Symbolic Jacobian" and search for one or more involved block variables in the displayed equations. After you have found the sought block, try to find out why it is not solvable.

E.g. inconsistent initial values can be the reason for the output of this message during the initialization:

21. Step: Residual is not in the image of 2*1-Jacobian with the DAE state _der_connection3.phi: res[1] = 6.5741692360397401 (>4.4408920985006302e-013) != jac[1][0] * s = 1 * 0

Two error messages follow:

Error: System of equations with the DAE state(s) _der_connection3.phi cannot be solved! After 21 steps residual is not in the image of the Jacobian.

Calculation aborted because of a problem during the calculation of initial conditions.

Consider the block equations and the initial values of the involved variables (several equations have been combined) inside the output of the tracing Equations/Symbolic Jacobian.

```
initial: connT.om0.fixed:=true;;
initial: connection3.om0.fixed:=true;
initial: der_connection3.phi=connection3.om.start=connection3.om0=0;
initial: der_connT.phi=connT.om.start=connT.om0=20;
initial:{{
EQUATION<>{_der_connection3.phi=0.65741692360397397*_der_connT.phi}
EQUATION<>{_der_connection3.phi=connection3.om.start}
}};
```

Then we can easily identify the cause of the problem here: the given initial values were fixed and are inconsistent.

The value … is below the minimum (…) of the DAE state

The value … exceeds the maximum (…) of the DAE state

One of these two messages will be traced when one block variable tried to leave its valid range, i.e. deceeded its minimum or exceeded its maximum. It includes moreover information about the value of the limit violation, the boundary set in the model and the damping factor which prevents the limit exceedance. Select the tracing "Equations" → "Symbolic Jacobian" and search in the displayed equations for one involved block variable and the corresponding block equations. Have a look at them and also at the current values of the block variables (result window). Try to find out why the variable tried to leave its valid range.

Reducing the damping factor to … because of the DAE state

DAE state … exceeds a limit

When multiple limit violations occur consecutively, the solver repeats to reduce the damping factor until its value is equal to zero. In that case the second message will be traced.

Currently, the values of all variables can only be examined by opening a result window (`dtProtMin`

should be sufficiently small). If the quantity is not directly accessible, a general function element (f(x) in the Signal Blocks library) may be used. Then its name must be entered as expression of the general function block.

- Errors and Warnings
- Ill-Conditioned Eigenvalues
- Ill-Conditioned Eigenvectors
- Solver.Abs_Tol
- Solver.DampFactor
- Solver.ErrTest
- Solver.EventCycle
- Solver.InkonsAWDisc
- Solver.LinSystemNotSolvable
- Solver.No_States_Equ
- Solver.NotKonv
- Solver.PredStateBound
- Solver.Rel_Tol
- Solver.SteadyStateFailed
- Solver-Related Warnings and Error Messages