7. Chess treatment

7.1. Encountered failures

Unlike a direct solver, an iterative solver will generally tend to fail during the phase of solving the linear system: for example if the convergence criterion is not verified after the maximum number of iterations previously set. This may be caused by a preconditioner that is not robust enough or an almost singular matrix.

Failures are also possible during the construction phase of the pre-conditioner but are rarer: for example if MUMPS lacks memory during the simple precision factorization to build the pre-conditioner LDLT_SP. In the latter case the solution is to restart the calculation with more memory or by increasing the value of PCENT_PIVOT.

7.2. Recovery in case of failure

Like direct solvers, Code_Aster’s iterative solvers are able to signal the failure or success of linear resolution. This feature is used in the non-linear solver [R5.03.01] in order to allow:

• the cutting of the time step in case of failure during the resolution phase regardless of the pre-conditioner

• the update of the pre-conditioner when LDLT_SP is used

When LDLT_SP is used, the current time step is refreshed first and then the current time step is performed again. If another failure occurs, the time step is then cut up.

It should be noted that no recovery is planned in case of failure during the pre-conditioner construction phase.

7.3. Implementation

The DEFI_LIST_INST operator allows you to activate the processing of failures. In the presence of a cutting action (ACTION =” DECOUPE “) or an action to update the pre-conditioner (ACTION =” REAC_PRECOND”), the capture of errors in the iterative solvers is activated in STAT_NON_LINE or DYNA_NON_LINE.

7.4. Interception of the exception

If the slicing strategy fails or the preconditioner is refreshed, an exception is raised. It can be caught in the command file using its name: ResolutionError.