do not use <h2> tag in tutorials

I am not quite sure why, but they don't show up in the table of
contents. We have been avoiding them, but a few tutorials seem to
violate this now.

diff --git a/examples/step-14/doc/results.dox b/examples/step-14/doc/results.dox
index df4df7eea1e5eda006720e835299b24822c8ffa8..8c6802717a3df5f0ede9401c73a139a84ebebb57 100644 (file)
--- a/examples/step-14/doc/results.dox
+++ b/examples/step-14/doc/results.dox
@@ -1,6 +1,6 @@
 <h1>Results</h1>
 
-<h2>Point values</h2>
+<h3>Point values</h3>
 
 
 This program offers a lot of possibilities to play around. We can thus
@@ -136,7 +136,7 @@ value:
 </table>
 
 
-<h2>Comparing refinement criteria</h2>
+<h3>Comparing refinement criteria</h3>
 
 
 Since we have accepted quite some effort when using the mesh
@@ -172,7 +172,7 @@ smaller errors.
 
 
 
-<h2>Evaluation of point stresses</h2>
+<h3>Evaluation of point stresses</h3>
 
 
 Besides evaluating the values of the solution at a certain point, the
@@ -290,7 +290,7 @@ computed value of $J(u_h)$.
 
 
 
-<h2>Step-13 revisited</h2>
+<h3>Step-13 revisited</h3>
 
 
 If instead of the <code>Exercise_2_3</code> data set, we choose
@@ -357,7 +357,7 @@ would remain.
 
 
 
-<h2>Conclusions and outlook</h2>
+<h3>Conclusions and outlook</h3>
 
 
 The results here are not too clearly indicating the superiority of the

diff --git a/examples/step-17/doc/intro.dox b/examples/step-17/doc/intro.dox
index 79b432bf6ae3c0405c23183bdf41e44896a3a039..342fb5b2225223d178c484824ba61b0708aed0d0 100644 (file)
--- a/examples/step-17/doc/intro.dox
+++ b/examples/step-17/doc/intro.dox
@@ -1,7 +1,7 @@
 <a name="Intro"></a>
 <h1>Introduction</h1>
 
-<h2>Overview</h2>
+<h3>Overview</h3>
 
 This program does not introduce any new mathematical ideas; in fact, all it
 does is to do the exact same computations that step-8
@@ -50,7 +50,7 @@ time, PETSc also provides dummy MPI stubs, so you can run this program on a
 single machine if PETSc was configured without MPI.
 
 
-<h2>Parallelizing software with MPI</h2>
+<h3>Parallelizing software with MPI</h3>
 
 Developing software to run in %parallel via MPI requires a bit of a change in
 mindset because one typically has to split up all data structures so that
@@ -172,7 +172,7 @@ function calls. That said, you do have to understand the general
 philosophy behind MPI as outlined above.
 
 
-<h2>What this program does</h2>
+<h3>What this program does</h3>
 
 The techniques this program then demonstrates are:
 - How to use the PETSc wrapper classes; this will already be visible in the

diff --git a/examples/step-36/doc/results.dox b/examples/step-36/doc/results.dox
index f913ce46df712a88da5a2a216e2387df19decb02..4e883ca09d23a209b2609c84037096c575754488 100644 (file)
--- a/examples/step-36/doc/results.dox
+++ b/examples/step-36/doc/results.dox
@@ -1,6 +1,6 @@
 <h1>Results</h1>
 
-<h2>Running the problem</h2>
+<h3>Running the problem</h3>
 
 The problem's input is parameterized by an input file <code>\step-36.prm</code>
 which could, for example, contain the following text:

diff --git a/examples/step-39/doc/results.dox b/examples/step-39/doc/results.dox
index c9263a17c75e44915812c20223804eb7e84e5d0d..c3531d9d4b8b977330c60e422a9a7383b5a5b0f8 100644 (file)
--- a/examples/step-39/doc/results.dox
+++ b/examples/step-39/doc/results.dox
@@ -1,6 +1,6 @@
 <h1>Results</h1>
 
-<h2>Logfile output</h2>
+<h3>Logfile output</h3>
 First, the program produces the usual logfile here stored in <tt>deallog</tt>. It reads (with omission of intermediate steps)
 
 @code
@@ -82,7 +82,7 @@ DEAL::
 This log for instance shows that the number of conjugate gradient
 iteration steps is constant at approximately 15.
 
-<h2>Postprocessing of the logfile</h2>
+<h3>Postprocessing of the logfile</h3>
 
 <img src="https://www.dealii.org/images/steps/developer/step-39-convergence.svg" alt="">
 Using the perl script <tt>postprocess.pl</tt>, we extract relevant

diff --git a/examples/step-47/doc/intro.dox b/examples/step-47/doc/intro.dox
index 34ebe19c524409f2290646e057d07e80abcc1e5a..9991a52c10f28509dc26d325177750d16ba5b0af 100644 (file)
--- a/examples/step-47/doc/intro.dox
+++ b/examples/step-47/doc/intro.dox
@@ -58,7 +58,7 @@ conditions on one part of the boundary, and the other on the
 remainder.
 
 
-<h2> What's the issue? </h2>
+<h3> What's the issue? </h3>
 
 The fundamental issue with the equation is that it takes four
 derivatives of the solution. In the case of the Laplace equation
@@ -122,7 +122,7 @@ consequence, they have largely fallen out of favor and deal.II currently
 does not contain implementations of these shape functions.
 
 
-<h2> What to do instead? </h2>
+<h3> What to do instead? </h3>
 
 So how does one approach solving such problems then? That depends a
 bit on the boundary conditions. If one has the first set of boundary
@@ -482,7 +482,7 @@ $\mathcal{A}(\cdot,\cdot)$ and $\mathcal{F}(\cdot)$ described in
 the book chapter @cite Brenner2011 .
 
 
-<h2>The testcase</h2>
+<h3>The testcase</h3>
 
 The last step that remains to describe is what this program solves
 for. As always, a trigonometric function is both a good and a bad

diff --git a/examples/step-47/doc/results.dox b/examples/step-47/doc/results.dox
index 6a7fc558aa83ef069f9687cd3ec804cc9f1581e2..d646e17318dcb6f4fb90dcd7273924368eb38479 100644 (file)
--- a/examples/step-47/doc/results.dox
+++ b/examples/step-47/doc/results.dox
@@ -191,7 +191,7 @@ is that $\gamma=p(p+1)$ yields the expected results. It is, consequently, what t
 uses as currently written.
 
 
-<h2> Possibilities for extensions </h2>
+<h3> Possibilities for extensions </h3>
 
 There are a number of obvious extensions to this program that would
 make sense:

diff --git a/examples/step-53/doc/intro.dox b/examples/step-53/doc/intro.dox
index 35f52a320ebb903ea15fabbd7960bd5e23fcda9c..c630d2f7559096963f093c4c971ac8e203eb6589 100644 (file)
--- a/examples/step-53/doc/intro.dox
+++ b/examples/step-53/doc/intro.dox
@@ -51,7 +51,7 @@ deal.II Frequently Asked Questions page referenced from http://www.dealii.org/
 provides resources to mesh generators.
 
 
-<h2>Where geometry and meshes intersect</h2>
+<h3>Where geometry and meshes intersect</h3>
 
 Let us assume that you have a complex domain and that you already have a
 coarse mesh that somehow represents the general features of the domain. Then
@@ -108,7 +108,7 @@ means providing a class derived from ChartManifold, and this is precisely what
 we will do in this program.
 
 
-<h2>The example case</h2>
+<h3>The example case</h3>
 
 To illustrate how one describes geometries using charts in deal.II, we will
 consider a case that originates in an application of the <a
@@ -228,7 +228,7 @@ awkward. We won't show the formula here but instead only provide the implementat
 in the program.
 
 
-<h2>Implementation</h2>
+<h3>Implementation</h3>
 
 There are a number of issues we need to address in the program. At the largest scale,
 we need to write a class that implements the interface of ChartManifold. This involves

diff --git a/examples/step-60/doc/results.dox b/examples/step-60/doc/results.dox
index 59627a376d0edbadbf5100e67693211bedd51f3d..ae9c27c51c8ff270d3d7786cd74f675cd1808329 100644 (file)
--- a/examples/step-60/doc/results.dox
+++ b/examples/step-60/doc/results.dox
@@ -202,7 +202,7 @@ end
 
 and you would obtain exactly the same results as in test case 1 below.
 
-<h2> Test case 1: </h2>
+<h3> Test case 1: </h3>
 
 For the default problem the value of $u$ on $\Gamma$ is set to the constant $1$:
 this is like imposing a constant Dirichlet boundary condition on $\Gamma$, seen
@@ -283,7 +283,7 @@ representatio of your domain (a much cheaper and easier mesh to produce).
 To play around a little bit, we are going to complicate a little the fictitious
 domain as well as the boundary conditions we impose on it.
 
-<h2> Test case 2 and 3: </h2>
+<h3> Test case 2 and 3: </h3>
 
 If we use the following parameter file:
 @code