From: Martin Kronbichler <kronbichler@lnm.mw.tum.de> Date: Tue, 17 Sep 2013 19:55:00 +0000 (+0000) Subject: Write section on results with solution pictures and convergence graphs. Now we only... X-Git-Tag: v8.1.0~786 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9256923b69ff05411ee61660e351ed110f72a092;p=dealii.git 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 --- 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 @@ <h1>Results</h1> +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 <i>p</i>=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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.sol_2.png" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.sol_3.png" alt=""> + </td> + </tr> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.sol_4.png" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.sol_8.png" alt=""> + </td> + </tr> +</table> + +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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.post_2.png" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.post_3.png" alt=""> + </td> + </tr> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.post_4.png" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.post_8.png" alt=""> + </td> + </tr> +</table> + +Finally, we look at the solution for <i>p</i>=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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.sol_q3_2.png" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.post_q3_2.png" alt=""> + </td> + </tr> +</table> + +<h4>Convergence tables</h4> + +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 +<h4>Comparison with continuous finite elements in 2D</h4> + +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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2d_plain.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2dt_plain.png" width="400" alt=""> + </td> + </tr> +</table> + +The results in the table show that the HDG method is slower than continuous +finite elements at <i>p</i>=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 <i>p</i>=3 and <i>p</i>=6, and about the same quality for <i>p</i>=1. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2d_post.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2dt_post.png" width="400" alt=""> + </td> + </tr> +</table> + +Since the HDG method actually produces results converging as +<i>h</i><sup><i>p</i>+2</sup>, we should compare it to a continuous Galerkin +solution with the same asymptotic convergence behavior, i.e., FE_Q with degree +<i>p</i>+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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2d_postb.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.2dt_postb.png" width="400" alt=""> + </td> + </tr> +</table> + +The results are in line with properties of DG methods in general: Best +performance is typically not achieved for linear elements, but rather around +<i>p</i>=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. + +<h4>Comparison with continuous finite elements in 3D</h4> + +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 +<i>u</i> for CG and HDG at order <i>p</i>, 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 <i>p</i>+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 <i>p</i> but Legendre polynomials of +<i>complete</i> degree <i>p</i>. 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. + +<table align="center" border="1" cellspacing="3" cellpadding="3"> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3d_plain.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3dt_plain.png" width="400" alt=""> + </td> + </tr> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3d_post.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3dt_post.png" width="400" alt=""> + </td> + </tr> + <tr> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3d_postb.png" width="400" alt=""> + </td> + <td> + <img src="http://www.dealii.org/images/steps/developer/step-51.3dt_postb.png" width="400" alt=""> + </td> + </tr> +</table> + +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 +<i>p</i>=3 and <i>p</i>=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. <h3>Possibilities for improvements</h3>