The Incomplete Cholesky (IC) preconditioner solves the equation for a given lower triangular matrix L and the right hand side b (can contain multiple right hand sides).
More...
The Incomplete Cholesky (IC) preconditioner solves the equation for a given lower triangular matrix L and the right hand side b (can contain multiple right hand sides).
It allows to set both the solver for L defaulting to solver::LowerTrs, which is a direct triangular solvers. The solver for L^H is the conjugate-transposed solver for L, ensuring that the preconditioner is symmetric and positive-definite. For this L solver, a factory can be provided (using with_l_solver) to have more control over their behavior. In particular, it is possible to use an iterative method for solving the triangular systems. The default parameters for an iterative triangluar solver are:
reduction factor = 1e-4
max iteration = <number of rows of the matrix given to the solver> Solvers without such criteria can also be used, in which case none are set.
An object of this class can be created with a matrix or a gko::Composition containing two matrices. If created with a matrix, it is factorized before creating the solver. If a gko::Composition (containing two matrices) is used, the first operand will be taken as the L matrix, the second will be considered the L^H matrix, which helps to avoid the otherwise necessary transposition of L inside the solver. ParIc can be directly used, since it orders the factors in the correct way.
Note
When providing a gko::Composition, the first matrix must be the lower matrix ( ), and the second matrix must be its conjugate-transpose ( ). If they are swapped, solving might crash or return the wrong result.
Do not use symmetric solvers (like CG) for the L solver since both matrices (L and L^H) are, by design, not symmetric.
This class is not thread safe (even a const object is not) because it uses an internal cache to accelerate multiple (sequential) applies. Using it in parallel can lead to segmentation faults, wrong results and other unwanted behavior.
The default template during parse is <ValueType, IndexType> not <LowerTrs, IndexType>. Only the variants with ValueType are supported in parse.
Template Parameters
LSolverTypeOrValueType
type of the solver or the value type used for the L matrix. Defaults to solver::LowerTrs
IndexType
type of the indices when ParIc is used to generate the L and L^H factors. Irrelevant otherwise.
Preserves the executor, moves the solvers and parameters. Creates a clone of the solvers if they are on the wrong executor. The moved-from object is empty (0x0 with nullptr solvers and default parameters)
Because this is directly tied to the specific type, the value/index type settings within config are ignored and type_descriptor is only used for children configs.
Parameters
config
the property tree for setting
context
the registry
td_for_child
the type descriptor for children configs. The default uses the value/index type of this class. When l_solver_type uses LinOp not concrete type, it will use the default_precision in ginkgo.
Returns
parameters
Note
only support the following when using <ValueType, IndexType> not <LSolverType, IndexType> variants