# Explanation of Solvers Settings

This chapter provides tips and rules to help you select the right solver for your application or your simulation task and to parameterize it accordingly. As simulations in the frequency domain (steady-state simulations) are less demanding, this chapter focuses on the proper settings for simulations in the time domain (transient simulations). The availability of Advanced Solver Settings depends on the selected solver settings and are described in the linked sections below.

The button in the More section of the Simulation Control dialog gives you access to advanced solver parameters. Making changes there is only advisable for experienced simulation experts. Otherwise, contact the ESI Support for SimulationX if you require assistance.

## Choosing the Best Solver

### Hard Rules

Models with Rigid End Stops can only be simulated with BDF or MEBDF methods! Such models allow for a structural switchover (mathematical). This applies to the following list of model types from the SimulationX libraries (selection):

All models (classes or types) allowing for structural switchover can only be simulated with BDF or MEBDF methods, especially if the differentiation index changes, i.e. derivatives of different orders are calculated in different branches. Mathematical structural switchover: Various state variables (ODE states) and solver variables are produced in the branches of `if`-`then`-`else` constructs or state machines (`when` constructs).

### Soft Rules (Recommendations)

The following overview is a set of recommendations to illustrate which solver works best for the task at hand:

No. Solver Explanation
BDF or MEBDF method (NOT based on compiled C code)
1 BDF At the modeling stage, where it is common to create small, less complex structures, using the BDF method is recommended, as this solver offers the best debugging capabilities, while the longer computation time (compared to all compiled solvers (incl. C code compilation)) is negligible.
2 BDF When you create new element types (Compounds etc.), use the BDF method, as this solver offers the best debugging capabilities.
3 MEBDF If conservation of energy is important for the analysis (e.g. in Mechanics where either damping or friction is taken into account), MEBDF should be preferred, since BDF causes a small, process-related, numeric damping effect (e.g. visible in the calculation of the one-mass oscillator over many periods).
BDF or MEBDF method (based on compiled C code)
4 The simulation with a BDF or MEBDF method takes a lot of computation time, especially with larger models. The compiled equivalents, in contrast, take way less longer. Since not all special cases can be taken into account, you should check whether the compiled and non-compiled variants return the same results and show the same behavior and how long the compilation itself may take. If it outweighs the benefits of the compiled variants, you can as well keep using BDF (compiled C code) or MEBDF (compiled C code).
CVODE (based on compiled C code)
5 CVODE For complex models generating analysis results in parameter studies, for example, it is recommended you use compiled solvers, especially CVODE.
CAUTION: On top of the time needed for the Modelica compilation (GSA), you need to allow for the C code compilation to take time as well.
6 CVODE The following solver settings for CVODE are usually recommendable, because they ensure a more accurate calculation from the beginning and hence fewer iterations during the computation of time steps:
• absTol=1e-6
• relTol=1e-6
7 CVODE For (automated) variation calculations yielding a plethora of results in a short time, you should use the settings from no. 6.
8 CVODE In general, CVODE delivers a better simulation performance in many mechanical or mechatronic applications than BDF methods.
9 CVODE The order control strategy with CVODE is less favorable than with BDF, since CVODE may calculate with small time steps or show a wrong slope behavior for eigenvalues near the imaginary axis (i.e. little damping compared to the oscillation). This can lead to a significantly slower calculation than with BDF.
Fixed Step Solver methods for real-time applications (based on compiled C code)
10 Fixed-Step Solver Models for real-time calculations, e.g. for infinite simulations or applications in a real-time environment (HiL, SiL), can use the Fixed-Step Solver from the start. Small time constants in the model (e.g. high-frequency vibration excitation) should be avoided though. The calculation step size dtMin should fulfill the sampling theorem.
(Integration method can be "ITI standard").
11 Fixed-Step Solver (comp.) As a general note, it is recommended you use two solvers: one solver with a fixed step size for final calculations on the real-time system and one solver with a variable step size to help determine the necessary step sizes of occurring changes and to evaluate the quality of simplifications (mostly in the light of real-time capabilities).
12 C Compilers The GNU compiler is rarely usable with "large models" (consisting of many elements), because the compilation may fail to run sufficiently. Microsoft compilers, however, usually work.

## Automatic solver settings for Modelica models

Under certain conditions, SimulationX does not use the default values for solver parameters and settings. This is usually the case with simulation models that were originally created in other Modelica environments and have not been saved in SimulationX at any point, e.g. example models from the Modelica Standard Library. The reason for this is that the Modelica specification does not mention any solver types and defines only a few common solver parameters which often enough fall short of the solver type requirements of the various Modelica environments. Modelica defines the following solver parameters (names) which are stored in the model's so-called `experiment` annotation:

``````annotation(
experiment(
StartTime=0,	// start time of the simulation in [s]
StopTime=40,	// stop time of the simulation in [s]
Interval=0.01,	// suitable time resolution for the result grid in [s]
Tolerance=1e-5)	// relative integration tolerance
);``````

These annotations are also documented in the Modellica Specification, chapter "18.4 Annotations for Simulation Experiments".

The following sections give you an overview of the conditions and rules that apply when SimulationX sets the solver automatically.

### Solver parameters (comparison)

Comparison of the relevant solver parameters in SimulationX and Modelica
(All parameters are of data type `Real`.)
Parameters Parameters in Modelica Default Value Explanation
`tStart` `StartTime` `0's'` Start time of the simulation run
`tStop` `StopTime` `1's'` Stop time of the simulation run
`dtMin` n/a `1e-08's'` Minimum step size of the calculation
`dtMax` n/a `(tStop-tStart)/100` Maximum step size of the calculation
`absTol` n/a `1e-05` absolute tolerance
`relTol` `tolerance` `1e-05` Relative tolerance
`dtProtMin` `interval` `0.001's'` Minimum step size of the output or suitable time resolution for the result grid
`dtDetect` n/a `dtMin*1e-4` Minimum step size (only for BDF or MEBDF methods)

### Conversion rules and assumptions for the solver parameters

SimulationX follows the below rules to determine unknown solver parameters from defined solver parameters (or from their default values). Note that SimulationX never overwrites annotations set by other tools. SimulationX never replaces the values for `tolerance` or `interval` when you enter other values for the solver parameters in SimulationX and save them with the model. When a model is loaded, the SimulationX parameter (if available) is always preferred.

No. Rule Condition
1 `relTol := Tolerance` `relTol` has not been modified, while `Tolerance` has a value.
2 `absTol := relTol` This applies if `relTol` has been modified, but not `absTol`.
3 or
`absTol := absTol/pow(10,(ceil(log10(absTol)/3)))`
This is an assumption if `absTol` is set to `< 1e-5`, while `relTol` has no value.
Time range of the simulation (general): `dt := abs(tStop - tStart)`
4 or
`dtMin := dt^2/1000`
This applies if `dt` is set to `> 0` and `dt` to `< 1e-2`.
5 or
`dtMin := dtMin*(relTol/1e-8*0.1)^2`
This applies if condition 4 is fulfilled and `relTol` is set to `< 1e-8`.
6 `dtMin := 1e-8*(if dt<1 then dt else 1) ` This applies if condition 4 is not fulfilled, while `dt` is set to `> 0` and `relTol` to `< 1e-8`.
7 `dtProtMin := interval` This applies when `interval > 0` and `dt > 0`, while `dtProtMin` has no value.
8 `dtProtMin := (tStop - tStart)/500` This is an assumption if neither `dtProtMin` nor `Interval` has a value. Instead of 500, SimulationX may use a different value for the number of intervals if this value was set in a vendor annotation (e.g. `NumberOfIntervals`) by another tool.
9 `dtMax := (tStop - tStart)/100` This is an assumption if there is no value for `dtMax`.
10 `dtDetect := dtMin*1e-4` This is an assumption if there is no value for `dtDetect`.

### Automatic selection of the CVODE method for Modelica models

For "pure" Modelica models, e.g. the example models from the Modelica Standard Library, SimulationX sets the solver method to CVODE automatically. This automatic conversion ensures that the computational speed and the accuracy of the results are comparable with those from other Modelica environments, since the CVODE method is the closest thing to the solvers used in those tools. Automatic modifications (if not specified by other Modelica solver parameters) include:

The automatic conversion is subject to the following rules and conditions:

• There is no `experiment` annotation in the model.
• There is an `experiment` annotation, but no SimulationX solver is specified.
• If the `experiment` annotation has no `tolerance` parameter, SimulationX uses the aforementioned values for absTol and relTol.
• If the `experiment` annotation has a `tolerance` parameter, SimulationX converts this value into values for absTol and relTol according to the specifications described in the section Conversion rules.
• New solver settings are saved with the model.
• SimulationX never changes models automatically if they are saved as ISX project or as ISM file.

Please note that you can change the automatic values at any time or reset them to the default values.

### Structural Switchover (mathematical)

The following describe a definition for ODE solvers (Ordinary Differential Equations), such as CVODE.

To solve ODE systems, the algebraic variables and derivatives of the ODE state variables are calculated from the ODE state variables, partly from assignments or, in the case of implicit equations or algebraic loops, in blocks. What happens when the block variables in certain branches cannot be determined from this block is called structural switchover, because the block becomes singular. In one branch, for example, the derivative of an ODE state variable is calculated from the block. In the other branch, the variable is calculated itself, hence the variable is no longer an ODE state variable. This changes also the differentiation index of this variable (e.g. velocity of static friction, acceleration of sliding friction, switching capacitors and coils in electronic applications on and off). If, however, several potential ODE state variables are connected through a constraint (e.g. a pendulum in the x-y plane), the ODE state variables change, which is achieved through dummy pivoting (description at the derivative's level) or state selection (description at the ODE state variable's level) and hence does not constitute a structural switchover. The same goes for blocks which become singular without an `if`-`then`-`else` construct or state machine (`when` constructs), e.g. in `x*x=1`).