#include <Multigrid.h>
Inheritance diagram for NestedFASMultigrid::
Public Methods | |
| NestedFASMultigrid (const MLSolver_prm &pm) | |
| ~NestedFASMultigrid () | |
| virtual bool | solve (StartVectorMode start) |
| virtual String | description () const |
Protected Methods | |
| virtual bool | cycle (SpaceId space, StartVectorMode start) |
NAME: NestedFASMultigrid - FAS, full approximation storage, imbedded in a nested iteration
DESCRIPTION:
Implements a standard (multiplicative) multigrid cycle. The different sub-domains here are the different grids. The grids themselves can be Lattice Grids, structured or unstructured grids, or adaptively refined grids. It can be used as a iterative solver, a preconditioner or a non-linear solver.
The coarse grid is number 1, the fine grid is number "getNoOfSpaces". The grids all cover the same geometric domain, but differ in the resolution or grid size. For standard applications the grids are nested and the grid sizes double form fine to coarse. However, in general the grids need not be nested.
The "Proj" operators will usually be used to implement the grid transfers for "transfer" of "MLSolverUDC". Only the transfers from i to i+1 (prolongation) and the adjoint transfers from i+1 to i (restriction) are used. These transfers can be implemented very efficiently for nested grids which grid sizes double. For non nested grids this transfers are more expensive.
The approximate solvers for the different grids usually are called smoothers. The solver for the coarsest grid number 1 can be exact, e.g. a direct solver, but does not have to be exact. It is not useful to use additional exact solvers for linear problems. Hence the other solvers are iterative solvers. Usually it is sufficient to use a small fixed number of iterations. Note that the optimal relaxation for over-relaxation iterations differs from the optimal value used for single-grid (standard) applications. If you want to use different procedures for pre- and post-smoothing, you will make use of the "MLSolverMode" flag in the "solveSubSystem" function of "MLSolverUDC". In the case of adaptively refined grids, the iteration can be restricted to the refined parts of the grid.
The "gamma" parameter of "MLSolver_prm" is used to choose the multigrid cycle type. "gamma"=1 is a V-cycle, which is one run from fine to coarse and reverse. "gamma"=2 is a W-cycle, which spends more operations on coarse grids. Higher "gamma" are defined recursively. If there are some convergence problems, which can not be overcome by improving the sub-domain solvers (or better transfer operators), it is usually a good idea to switch from a V-cycle to a W-cycle or even more expensive cycles. Note that using too expensive cycles ("gamma" too high) sacrifices the optimal complexity of the algorithm. This bound depends on the increase of points from one grid i to the finer grid i+1.
In the case you want to have a symmetric multigrid, take care that the transfers i to i+1 and i+1 to i are adjoint and that the pre-smoothing and the post-smoothing are adjoint, too. This can be useful for self-adjoint differential operators and symmetric solvers like "ConjGrad".
For further reading see e.g. W. Hackbusch "Multigrid Methods and Applications", Springer Verlag, 1985.
|
|
See class "MLSolver". |
|
|
|
|
|
Reimplemented from NonlinearMultigrid. Reimplemented in NestedFASDampedMultigrid, and FASDampedMultigrid. |
|
|
Reimplemented from NonlinearMultigrid. Reimplemented in FASMultigrid, NestedFASDampedMultigrid, and FASDampedMultigrid. |
|
|
solves the system. The function implements the algorithm and will probably never be called by the user directly. Data vectors have to be attached during initialization. The actual algorithm determines exactly, which vectors are needed and checks, whether they have been attached. The start vector is given by a value "StartVectorMode". Reimplemented from NonlinearMultigrid. Reimplemented in FASMultigrid. |