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.
Choosing the Best Solver
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):
Mechanics.Translation.EndStopwith mode=="Rigid End Stop"
Mechanics.Rotation.EndStopwith mode=="Rigid End Stop"
Mechanics.Rotation.SpringDamperwith kindR<>"without Backlash"
Mechanics.MechanicsMBS.Joints.RevoluteJointwith kindL<>"No Losses", kindF=="Stick-Slip" and rigid=="true"
- All model types within the libraries
If no BDF or MEBDF method is selected for such models, SimulationX shows the following error message:
Error in Model1: Unsupported model.
The model 'Rigid End Stop' / 'Ideal Diode' (in component "
IDENT") is not supported by this solver. Please select a BDF or MEBDF method or change the model or the parameter settings.
Soft Rules (Recommendations)
The following overview is a set of recommendations to illustrate which solver works best for the task at hand:
|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:
|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.|
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
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.
|Parameters||Parameters in Modelica||Default Value||Explanation|
||Start time of the simulation run|
||Stop time of the simulation run|
||Minimum step size of the calculation|
||Maximum step size of the calculation|
||Minimum step size of the output or suitable time resolution for the result grid|
||Minimum step size (only for BDF or MEBDF methods)|
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
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.
||This applies if
||This is an assumption if
|Time range of the simulation (general):
|This applies if
|This applies if condition 4 is fulfilled and
||This applies if condition 4 is not fulfilled, while
||This applies when
||This is an assumption if neither
||This is an assumption if there is no value for
||This is an assumption if there is no value for
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:
- CVODE method (based on compiled C code)
The automatic conversion is subject to the following rules and conditions:
- There is no
experimentannotation in the model.
- There is an
experimentannotation, but no SimulationX solver is specified.
- If the
experimentannotation has no
toleranceparameter, SimulationX uses the aforementioned values for absTol and relTol.
- If the
experimentannotation has a
toleranceparameter, 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
else construct or state machine (
when constructs), e.g. in