From: Timo Heister Date: Thu, 26 Jul 2018 13:20:21 +0000 (+0200) Subject: update documentation X-Git-Tag: v9.1.0-rc1~739^2~4 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cbfb635407d7311d8eb3b9145a4591de63ce1dee;p=dealii.git update documentation --- diff --git a/examples/step-16b/doc/intro.dox b/examples/step-16b/doc/intro.dox index 85145b1051..594e00507d 100644 --- a/examples/step-16b/doc/intro.dox +++ b/examples/step-16b/doc/intro.dox @@ -3,58 +3,10 @@

Introduction

- -This example shows the basic usage of the multilevel functions in deal.II. It -solves almost the same problem as used in step-6, but demonstrating the things -one has to provide when using multigrid as a preconditioner. In particular, this -requires that we define a hierarchy of levels, provide transfer operators from -one level to the next and back, and provide representations of the Laplace -operator on each level. - -In order to allow sufficient flexibility in conjunction with systems of -differential equations and block preconditioners, quite a few different objects -have to be created before starting the multilevel method, although -most of what needs to be done is provided by deal.II itself. These are - - the object handling transfer between grids; we use the MGTransferPrebuilt - class for this that does almost all of the work inside the library, - - the solver on the coarsest level; here, we use MGCoarseGridHouseholder, - - the smoother on all other levels, which in our case will be the - mg::SmootherRelaxation class using SOR as the underlying method, - - and mg::Matrix, a class having a special level multiplication, i.e. we - basically store one matrix per grid level and allow multiplication with it. - -Most of these objects will only be needed inside the function that -actually solves the linear system. There, these objects are combined -in an object of type Multigrid, containing the implementation of the -V-cycle, which is in turn used by the preconditioner PreconditionMG, -ready for plug-in into a linear solver of the LAC library. - -The multigrid method implemented here for adaptively refined meshes follows the -outline in the @ref mg_paper "Multigrid paper", which describes the underlying -implementation in deal.II and also introduces a lot of the nomenclature. First, -we have to distinguish between level meshes, namely cells that have the same -refinement distance from the coarse mesh, and the leaf mesh consisting of active -cells of the hierarchy (in older work we refer to this as the global mesh, but -this term is overused). Most importantly, the leaf mesh is not identical with -the level mesh on the finest level. The following image shows what we consider -to be a "level mesh": - -

- @image html "multigrid.png" "" -

- -The fine level in this mesh consists only of the degrees of freedom that are -defined on the refined cells, but does not extend to that part of the domain -that is not refined. While this guarantees that the overall effort grows as -${\cal O}(N)$ as necessary for optimal multigrid complexity, it leads to -problems when defining where to smooth and what boundary conditions to pose for -the operators defined on individual levels if the level boundary is not an -external boundary. These questions are discussed in detail in the article cited -above. +This is a variant of step-16 with the only change that we are using the +MeshWorker framework with the pre-made LocalIntegrator helper classes instead +of manually assembling the matrices.

The testcase

-The problem we solve here is similar to step-6, with two main -differences: first, the multigrid preconditioner, obviously. We also -change the discontinuity of the coefficients such that the local -assembler does not look more complicated than necessary. +The problem we solve here is similar to step-16. diff --git a/examples/step-16b/doc/results.dox b/examples/step-16b/doc/results.dox index 1d6abc9b3e..c7e3f8fb58 100644 --- a/examples/step-16b/doc/results.dox +++ b/examples/step-16b/doc/results.dox @@ -1,14 +1,12 @@

Results

-On the finest mesh, the solution looks like this: +As in step-16, the solution looks like this on the finest mesh:

-More importantly, we would like to see if the multigrid method really improved -the solver performance. Therefore, here is the textual output: - +The output is formatted in a slightly different way compared to step-16: 
 DEAL::Cycle 0
 DEAL::   Number of active cells:       20
@@ -52,35 +50,7 @@ DEAL:cg::Starting value 0.141519
 DEAL:cg::Convergence step 10 value 5.74965e-13
-That's almost perfect multigrid performance: 12 orders of magnitude in -10 iteration steps, and almost independent of the mesh size. That's -obviously in part due to the simple nature of the problem solved, but -it shows the power of multigrid methods. -

Possible extensions

-We encourage you to switch on timing output by calling the function -LogStream::log_execution_time() of the deallog object and compare to -step 6. You will see that the multigrid method has quite an overhead -on coarse meshes, but that it always beats other methods on fine -meshes because of its optimal complexity. - -A close inspection of this program's performance shows that it is mostly -dominated by matrix-vector operations. step-37 shows one way -how this can be avoided by working with matrix-free methods. - -Another avenue would be to use algebraic multigrid methods. The geometric -multigrid method used here can at times be a bit awkward to implement because it -needs all those additional data structures, and it becomes even more difficult -if the program is to run in %parallel on machines coupled through MPI, for -example. In that case, it would be simpler if one could use a black-box -preconditioner that uses some sort of multigrid hierarchy for good performance -but can figure out level matrices and similar things by itself. Algebraic -multigrid methods do exactly this, and we will use them in step-31 for the -solution of a Stokes problem and in step-32 and step-40 for a parallel -variation. - -Finally, one may want to think how to use geometric multigrid for other kinds of -problems, specifically @ref vector_valued "vector valued problems". This is the -topic of step-56 where we use the techniques shown here for the Stokes equation. +See step-16.