From 85bb54d0de4bc7c6efe62c2c8b601775f16482dd Mon Sep 17 00:00:00 2001 From: kronbichler Date: Tue, 17 Sep 2013 19:55:00 +0000 Subject: [PATCH] Write section on results with solution pictures and convergence graphs. Now we only need to upload the images git-svn-id: https://svn.dealii.org/trunk@30779 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-51/doc/results.dox | 223 ++++++++++++++++++++++- 1 file changed, 220 insertions(+), 3 deletions(-) diff --git a/deal.II/examples/step-51/doc/results.dox b/deal.II/examples/step-51/doc/results.dox index 1bacb406d7..153b3317d1 100644 --- a/deal.II/examples/step-51/doc/results.dox +++ b/deal.II/examples/step-51/doc/results.dox @@ -1,9 +1,94 @@

Results

+We first have a look at the output generated by the program when run in 2D. In +the four images below, we show the solution for polynomial degree p=1 +and the cycle 2, 3, 4, and 8 of the program. In the plots, we overlay the data +generated from the internal data (DG part) with the skeleton part into the +same plot. We had to generate two different data sets because cells and faces +represent different geometric entities, the combination of which in the same +file are not supported in the VTK output of deal.II. -When the program is run, it outputs information about the respective steps and -convergence tables with errors in the various components in the end. In 2D, -the convergence tables look the following: +The images show the distinctive features of HDG: The cell solution (colored +surfaces) is discontinuous between the cells. The solution on the skeleton +variable sits on the faces and ties together the local parts. The skeleton +solution is not continuous on the vertices where the faces meet, even though +its values are quite close within lines in one direction. It can be +interpreted as a string between the two sides that balances the jumps in the +solution (or rather, the flux $\kappa \nabla u + \mathbf{c} u$). As the mesh +is refined, the jumps between the cells get small as we represent a smooth +solution, and the skeleton solution approaches the cell parts. For cycle 8, +there is no visible difference in the two variables. We also see how boundary +conditions are implemented weakly. On the lower and left boundaries, we set +Neumann boundary conditions, whereas we set Dirichlet conditions on the right +and top boundaries. + + + + + + + + + + +
+ + + +
+ + + +
+ +Next, we have a look at the post-processed solution, again at cycles 2, 3, 4, +and 8. This is a discontinuous solution that is locally described by second +order polynomials. While the solution does not look very good on the mesh of +cycle two, it looks much better for cycles three and four. As shown by the +convergence table below, we find that is also converges more quickly to the +analytical solution. + + + + + + + + + + +
+ + + +
+ + + +
+ +Finally, we look at the solution for p=3 at cycle 2. Despite the coarse +mesh with only 64 cells, the solution looks quite good. And the +post-processed solution is similar in quality than the linear solution (not +post-processed) at cycle 8 with 4,096 cells. This clearly shows the +superiority of high order methods for smooth solutions. + + + + + + +
+ + + +
+ +

Convergence tables

+ +When the program is run, it also outputs information about the respective +steps and convergence tables with errors in the various components in the +end. In 2D, the convergence tables look the following: @code Q1 elements, adaptive refinement: @@ -103,6 +188,138 @@ cells dofs val L2 grad L2 val L2-post 110592 5419008 3.482e-05 3.94 3.055e-04 3.95 7.374e-07 5.00 @endcode +

Comparison with continuous finite elements in 2D

+ +From the convergence tables, we see the expected convergence rates as +mentioned in the introduction. Now, we want to compare the computational +efficiency of the HDG method compared to a usual finite element (continuous +Galkerin) method on the problem of this tutorial. Of course, stability aspects +of the HDG method compared to continuous finite elements for +transport-dominated problems are also important in practice, which is an +aspect not present on a problem with smooth analytic solution. In the picture +below, we compare the $L_2$ error as a function of the number of degrees of +freedom (left) and of the computing time spent in the linear solver for two +space dimensions for continuous finite elements (CG) and the hybridized +discontinuous Galerkin method presented in this tutorial. As opposed to the +tutorial where we only use unpreconditioned BiCGStab, the times shown in the +figures below use the Trilinos algebraic multigrid preconditioner in +TrilinosWrappers::PreconditionAMG for the CG part and a wrapper around +ChunkSparseMatrix for the trace variable (in order to utilize the block +structure in the matrix), respectively. + + + + + + +
+ + + +
+ +The results in the table show that the HDG method is slower than continuous +finite elements at p=1, about equally fast for cubic elements and +faster for sixth order elements. However, we have seen above that the HDG +method actually produces solutions which are more accurate than what is +represented in the original variables. Therefore, in the next two plots below +we show how the post-processed solution for HDG performs (denoted by $p=1^*$ +for example). We now see a clear advantage of HDG for the same amount of work +for both p=3 and p=6, and about the same quality for p=1. + + + + + + +
+ + + +
+ +Since the HDG method actually produces results converging as +hp+2, we should compare it to a continuous Galerkin +solution with the same asymptotic convergence behavior, i.e., FE_Q with degree +p+1. If we do this, we get the convergence curves as below. We see that +CG with second order polynomials is again clearly better than HDG with +linears. However, for higher orders the advantage of HDG remains. + + + + + + +
+ + + +
+ +The results are in line with properties of DG methods in general: Best +performance is typically not achieved for linear elements, but rather around +p=3. This is because of a volume-to-surface effect for discontinuous +solutions with too much of the solution living on the surfaces and hence +duplicating work when the elements are linear. Put in other words, DG methods +are often most efficient when used at relatively high order, despite their +focus on discontinuous (and hence, seemingly low accurate) representation of +solutions. + +

Comparison with continuous finite elements in 3D

+ +We now show the same figures in 3D: The first row shows the number of degrees +of freedom and computing time versus the $L_2$ error in the scalar variable +u for CG and HDG at order p, the second row shows the +post-processed HDG solution instead of the original one, and the third row +compares the post-processed HDG solution with CG at order p+1. In 3D, +the volume-to-surface effect makes the cost of HDG somewhat higher and the CG +solution is clearly better than HDG for linears in any metric. For cubics, HDG +and CG are again of similar quality, whereas HDG is again more efficient for +sixth order polynomials. One can alternatively also use the combination of +FE_DGP and FE_FaceP instead of (FE_DGQ, FE_FaceQ), which do not use tensor +product polynomials of degree p but Legendre polynomials of +complete degree p. While there are less degrees of freedom on +the skeleton variable for FE_FaceP for a given mesh size, the solution quality +(error vs. number of DoFs) is very similar between the two. + + + + + + + + + + + + + + +
+ + + +
+ + + +
+ + + +
+ +One final note on the efficiency comparison: We tried to use similar solvers +(optimal AMG preconditioners for both without particular tuning of the AMG +parameters on any of the two) to give a fair picture of the two methods on a +toy example. It should be noted however that GMG for continuous finite +elements is about a factor four to five faster on this (easy) problem for +p=3 and p=6. The authors of this tutorial have not seen similar +solvers for the HDG linear system. Also, there are other implementation +aspects for CG available such as fast matrix-free approaches as shown in +step-37 that make higher order continuous elements more competitive. Again, it +is not clear to the authors of the tutorial whether similar improvements could +be made for HDG.

Possibilities for improvements

-- 2.39.5