<h1>Results</h1>


The output of this program consist of the console output, the eps
files including the grids, and the solutions given in gnuplot format.
@code
DEAL::Cycle 0
DEAL::Number of active cells:       64
DEAL::Number of degrees of freedom: 256
DEAL:Richardson::Starting value 0.176777
DEAL:Richardson::Convergence step 4 value 3.33123e-17
DEAL::Writing grid to <grid-0.eps>
DEAL::Writing solution to <sol-0.gnuplot>
DEAL::Cycle 1
DEAL::Number of active cells:       112
DEAL::Number of degrees of freedom: 448
DEAL:Richardson::Starting value 0.153093
DEAL:Richardson::Convergence step 9 value 3.74479e-17
DEAL::Writing grid to <grid-1.eps>
DEAL::Writing solution to <sol-1.gnuplot>
DEAL::Cycle 2
DEAL::Number of active cells:       214
DEAL::Number of degrees of freedom: 856
DEAL:Richardson::Starting value 0.149870
DEAL:Richardson::Convergence step 16 value 1.41017e-14
DEAL::Writing grid to <grid-2.eps>
DEAL::Writing solution to <sol-2.gnuplot>
DEAL::Cycle 3
DEAL::Number of active cells:       415
DEAL::Number of degrees of freedom: 1660
DEAL:Richardson::Starting value 0.149053
DEAL:Richardson::Convergence step 26 value 4.92424e-15
DEAL::Writing grid to <grid-3.eps>
DEAL::Writing solution to <sol-3.gnuplot>
DEAL::Cycle 4
DEAL::Number of active cells:       796
DEAL::Number of degrees of freedom: 3184
DEAL:Richardson::Starting value 0.148848
DEAL:Richardson::Convergence step 44 value 5.80787e-14
DEAL::Writing grid to <grid-4.eps>
DEAL::Writing solution to <sol-4.gnuplot>
DEAL::Cycle 5
DEAL::Number of active cells:       1561
DEAL::Number of degrees of freedom: 6244
DEAL:Richardson::Starting value 0.131369
DEAL:Richardson::Convergence step 81 value 2.39812e-13
DEAL::Writing grid to <grid-5.eps>
DEAL::Writing solution to <sol-5.gnuplot>
@endcode

We show the solutions on the initial mesh, the mesh after two
and after five adaptive refinement steps.

<img src="https://www.dealii.org/images/steps/developer/step-12.sol-0.png" alt="">
<img src="https://www.dealii.org/images/steps/developer/step-12.sol-2.png" alt="">
<img src="https://www.dealii.org/images/steps/developer/step-12.sol-5.png" alt="">


Then we show the final grid (after 5 refinement steps) and the solution again,
this time with a nicer 3d rendering (obtained using the DataOutBase::write_vtk
function and the VTK-based VisIt visualization program) that better shows the
sharpness of the jump on the refined mesh and the over- and undershoots of the
solution along the interface:

<img src="https://www.dealii.org/images/steps/developer/step-12.grid-5.png" alt="">
<img src="https://www.dealii.org/images/steps/developer/step-12.3d-solution.png" alt="">


And finally we show a plot of a 3d computation.

<img src="https://www.dealii.org/images/steps/developer/step-12.sol-5-3d.png" alt="">


<a name="dg-vs-cg"></a>
<h3>Why use discontinuous elements</h3>

In this program we have used discontinuous elements. It is a legitimate
question to ask why not simply use the normal, continuous ones. Of course, to
everyone with a background in numerical methods, the answer is obvious: the
continuous Galerkin (cG) method is not stable for the transport equation,
unless one specifically adds stabilization terms. The DG method, however,
<i>is</i> stable. Illustrating this with the current program is not very
difficult; in fact, only the following minor modifications are necessary:
- Change the element to FE_Q instead of FE_DGQ.
- Add handling of hanging node constraints in exactly the same way as step-6.
- We need a different solver; the direct solver in step-29 is a convenient
  choice.
An experienced deal.II user will be able to do this in less than 10 minutes.

While the 2d solution has been shown above, containing a number of small
spikes at the interface that are, however, stable in height under mesh
refinement, results look much different when using a continuous element:

<table align="center">
  <tr>
    <td valign="top">
      0 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-0.png" alt="">
    </td>

    <td valign="top">
      1 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-1.png" alt="">
    </td>
  </tr>

  <tr>
    <td valign="top">
      2 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-2.png" alt="">
    </td>

    <td valign="top">
      3 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-3.png" alt="">
    </td>
  </tr>

  <tr>
    <td valign="top">
      4 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-4.png" alt="">
    </td>

    <td valign="top">
      5 &nbsp;
    </td>
    <td valign="top">
      <img src="https://www.dealii.org/images/steps/developer/step-12.cg.sol-5.png" alt="">
    </td>
  </tr>
</table>

In refinement iteration 5, the image can't be plotted in a reasonable way any
more as a 3d plot. We thus show a color plot with a range of $[-1,2]$ (the
solution values of the exact solution lie in $[0,1]$, of course). In any case,
it is clear that the continuous Galerkin solution exhibits oscillatory
behavior that gets worse and worse as the mesh is refined more and more.

There are a number of strategies to stabilize the cG method, if one wants to
use continuous elements for some reason. Discussing these methods is beyond
the scope of this tutorial program; an interested reader could, for example,
take a look at step-31.



<a name="extensions"></a>
<h3>Possibilities for extensions</h3>

Given that the exact solution is known in this case, one interesting
avenue for further extensions would be to confirm the order of
convergence for this program. In the current case, the solution is
non-smooth, and so we can not expect to get a particularly high order
of convergence, even if we used higher order elements. But even if the
solution <i>is</i> smooth, the equation is not elliptic and so it is not
immediately clear that we should obtain a convergence order that
equals that of the optimal interpolation estimates (i.e. for example
that we would get $h^3$ convergence in the $L^2$ norm by using
quadratic elements).

In fact, for hyperbolic equations, theoretical predictions often
indicate that the best one can hope for is an order one half below the
interpolation estimate. For example, for the streamline diffusion
method (an alternative method to the DG method used here to stabilize
the solution of the transport equation), one can prove that for
elements of degree $p$, the order of convergence is $p+\frac 12$ on
arbitrary meshes. While the observed order is frequently $p+1$ on
uniformly refined meshes, one can construct so-called Peterson meshes
on which the worse theoretical bound is actually attained. This should
be relatively simple to verify, for example using the
VectorTools::integrate_difference function.

A different direction is to observe that the solution of transport problems
often has discontinuities and that therefore a mesh in which we <i>bisect</i>
every cell in every coordinate direction may not be optimal. Rather, a better
strategy would be to only cut cells in the direction parallel to the
discontinuity. This is called <i>anisotropic mesh refinement</i> and is the
subject of step-30.
