<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:
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>
projects / dealii-svn.git / commitdiff