To find out more about the mathematical background, please refer, for example, to this paper.
In preCICE, three different types of acceleration can be configured:
constant (constant under-relaxation),
aitken (adaptive under-relaxation), and various quasi-Newton variants (
IQN-ILS aka. Anderson acceleration,
IQN-IMVJ aka. generalized Broyden). Before looking at the details, we need to understand which data gets modified when.
Coupling data and primary data
All data communicated within a coupling scheme needs to be configured through
exchange tags. Let’s call these data fields coupling data.
<coupling-scheme:serial-implicit> <participants first="FluidSolver" second="StuctureSolver"/> <exchange data="Displacements" mesh="StructureMesh" from="StuctureSolver" to="FluidSolver"/> <exchange data="Forces" mesh="StructureMesh" from="FluidSolver" to="StuctureSolver"/> ... <acceleration:...> <data name="Displacements" mesh="StructureMesh"/> ... </acceleration:...> </coupling-scheme:serial-implicit>
The acceleration modifies coupling data in
advance(). This means, what you write to preCICE on the one participant is not the same with what you read on the other participant. The data values are stabilized (or “accelerated”) instead. This happens also by using values from previous iterations. Simply think of a linear combination of previous iterations.
- For a parallel coupling, all coupling data is post-processed the same way. This means all coupling data use the same coefficients for the linear combination.
- For a serial coupling only coupling that is exchanged from the
firstparticipant is post-processed. Coupling data exchanged in the other direction (from
second) is not modified.
Let’s look at an example: For fluid-structure interaction, if we first execute the fluid solver with given interface displacements followed by the structure solver taking forces from the fluid solver and computing new interface displacements, (only) the displacements are post-processed in case of serial coupling. For parallel coupling, both displacements and forces are post-processed.
Next, we have to configure based on which data the acceleration computes, i.e. how the coefficients in the linear combinations get computed. These data fields are defined within the acceleration as
data tags (such as
Displacements in the code example above). Let’s call these data fields primary data. (Just for completeness: All coupling data that gets post-processed and that is not primary data, is called “secondary data”.)
- For serial coupling, you can only configure one primary data field, which should correspond to a coupling data field that is exchanged from the
firstparticipant. In the FSI example, the
- For parallel coupling, an arbitrary number of primary data can be configured. For numerical performance reasons, you should define at least one coupling data field of each direction (one from
first, one from
second). In the FSI example, configure
Now, we know the difference between coupling data and primary data. Next, we have a look on how we actually configure the type of acceleration.
<acceleration:constant> <relaxation value="0.5"/> </acceleration:constant>
The configuration for constant under-relaxation is straight-forward. The only parameter to be configured is the under-relaxation factor relaxation. In particular, the configuration of primary data is not necessary as the relaxation parameter stays constant, i.e. the linear combination has fixed coefficients (
relaxation for the current iteration,
1-relaxation for the previous iteration).
Constant under-relaxation with a factor of 0.5 can be a good choice for e.g. turbulent FSI at a high Reynolds number.
Dynamic Aitken under-relaxation
<acceleration:aitken> <data name="Displacements" mesh="StructureMesh"/> <initial-relaxation value="0.1"/> </acceleration:aitken>
Aitken under-relaxation adapts the under-relaxation factor in every iteration based on current residuals of the defined primary data and we only need to define an initial relaxation factor initial-relaxation. A value of 0.1 is a robust initial-relaxation factor.
Aitken under-relaxation can be a good choice for strong interaction with a fluid solvers that does not fully converge in every iteration or for compressible fluid solvers. For most cases, however, it is beneficial to change to a quasi-Newton scheme.
<acceleration:IQN-ILS> <data name="Displacements" mesh="StructureMesh"/> <data name="Forces" mesh="StructureMesh"/> <preconditioner type="residual-sum"/> <filter type="QR2" limit="1e-3"/> <initial-relaxation value="0.1"/> <max-used-iterations value="100"/> <time-windows-reused value="20"/> </acceleration:IQN-ILS>
For quasi-Newton, the configuration is more involved and requires some attention to achieve good performance. In the following, we list the options and parameters to be chosen and give hints on good combinations of choices:
- Pick a quasi-Newton variant from the following choices: IQN-ILS (aka. Anderson acceleration), IQN-IMVJ (aka. generalized Broyden).
IQN-ILSis simpler to start with.
- If parallel coupling is used and, thus, several primary data fields are configured, an equal weighting between them has to be ensured. This is done by defining a preconditioner. As type, we recommend to use
- To ensure linear independence of columns in the multi-secant system for Jacobian estimation, a filter can be used. The type can be chosen as QR1 or QR2. In addition to type, a threshold for linear dependency, limit has to be defined. In most cases, the filter efficiency is not very sensitive with respect to the limit. We recommend to start with a
limitof 1e-3 or 1e-2 and QR2 (For
QR11e-6 or 1e-5 is a good choice). A filter should be used with all quasi-Newton variants. If the respective line of the configuration file is omitted, no filter is applied. To find our more, you can have a look at this paper.
- In the first iteration, quasi-Newton methods don’t provide an estimate for the Jacobian yet. Thus, the first iteration is an under-relaxed fixed-point iteration, for which we have to define the parameter initial-relaxation. 0.1 is a robust choice. Too small values can render the information from the first iteration too coarse for the calculation of a good Jacobian estimate. Too large values might lead to stability problems.
- The parameter max-used-iterations specifies the maximum number of previous iterations used to generate the data basis for Jacobian estimation. In particular for small simulations with only few degrees for freedom, this is an important parameter. It should be chosen to be smaller than half of the total number of degrees of freedom at the interface. For large-scale simulations 100 is a robust choice.
- The parameter
time-windows-reusedalso limits the number of previous iterations, but in a per-time-window fashion. Iterations from older time windows than
time-windows-reusedare dropped. Note that, as we don’t know the number of iterations per time window a priori, this is not equivalent to setting max-used-iterations. For
IQN-IMVJ, this parameter can be set to 0 as information from past time windows is implicitly used in the modified Jacobian norm minimization. For
IQN-ILS, this parameter is an important tuning parameter, in particular if no filtering or filtering with a very low threshold is used. The optimum highly depends on the application, the used solvers and also the grid resolution. We recommend to choose a rather large value (10-30) and combine it with effective filtering (e.g.,
QR2with limit 1e-2) as a starting point for further optimization. With increasing degree of non-linearity of the considered application, the optimal value for
time-windows-reusedis expected to decrease.
Quasi-Newton acceleration is a good choice for strong interactions. Please note that a necessary prerequisite for convergence of the implicit coupling loop is the proper convergence of each participant internally. Inner convergence measure (e.g. of the fluid solver) should be two orders of magnitude stricter than the coupling convergence-measure to achieve good performance with quasi-Newton.