<ol>
+<li>
+New: We have added a brief section to the step-12 tutorial programs that
+compares the DG solution computed there with one that one would obtain by
+using a continuous finite element.
+<br>
+(Wolfgang Bangerth, 2012/03/25)
+
<li>
New: Added support for codimension 2, i.e. for dim-dimensional objects
embedded into spacedim=dim+2 dimensional space.
to <code>types::material_id_t</code>
resp. <code>types::boundary_id_t</code>, both typedefs of unsigned
char. Internal faces are now characterized by
-types::internal_face_boundary_id(<code>=static_cast<boundary_id_t>(-1)</code>)
+types::internal_face_boundary_id(<code>=static_cast@<boundary_id_t@>(-1)</code>)
instead of 255, so we get rid of that mysterious number in the source
code. Material_ids are also assumed to lie in the range from 0 to
types::invalid_material_id-1 (where <code>types::invalid_material_id =
@image html step-12.sol-5-3d.png
+<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
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-0.png
+ </td>
+
+ <td valign="top">
+ 1
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-1.png
+ </td>
+ </tr>
+
+ <tr>
+ <td valign="top">
+ 2
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-2.png
+ </td>
+
+ <td valign="top">
+ 3
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-3.png
+ </td>
+ </tr>
+
+ <tr>
+ <td valign="top">
+ 4
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-4.png
+ </td>
+
+ <td valign="top">
+ 5
+ </td>
+ <td valign="top">
+ @image html step-12.cg.sol-4.png
+ </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>