<a name="Intro"></a>
<h1>Introduction</h1>
-
-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":
-
-<p align="center">
- @image html "multigrid.png" ""
-</p>
-
-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.
<h3>The testcase</h3>
-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.
<h1>Results</h1>
-On the finest mesh, the solution looks like this:
+As in step-16, the solution looks like this on the finest mesh:
<p align="center">
<img src="https://www.dealii.org/images/steps/developer/step-16.solution.png" alt="">
</p>
-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:
<pre>
DEAL::Cycle 0
DEAL:: Number of active cells: 20
DEAL:cg::Convergence step 10 value 5.74965e-13
</pre>
-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.
-
<h3> Possible extensions </h3>
-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.
projects / dealii.git / commitdiff