Unify the spelling of a section name in the tutorial programs.

We use 'Possibilities for extensions' in about 40 existing tutorial programs. Use the
same heading in about a dozen others.

diff --git a/examples/step-1/doc/results.dox b/examples/step-1/doc/results.dox
index 83776a2c26c73eacf4b6adfe1c42cb9d5a01c45d..c9f893a650966ac7d4b8bb064b215a4b0132dfcc 100644 (file)
--- a/examples/step-1/doc/results.dox
+++ b/examples/step-1/doc/results.dox
@@ -32,7 +32,7 @@ has found its way into the literature: see @cite Mu05. Apparently it is
 good for some things at least.)
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 <h4> Different adaptive refinement strategies </h4>
 

diff --git a/examples/step-16/doc/results.dox b/examples/step-16/doc/results.dox
index 004d6d512a62c977e8102dd20bae7f91440608f5..962560ab34e6873630c08d973afe378423329f71 100644 (file)
--- a/examples/step-16/doc/results.dox
+++ b/examples/step-16/doc/results.dox
@@ -57,7 +57,7 @@ obviously in part due to the simple nature of the problem solved, but
 it shows the power of multigrid methods.
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 
 We encourage you to generate timings for the solve() call and compare to

diff --git a/examples/step-18/doc/results.dox b/examples/step-18/doc/results.dox
index 28f9c16dcb874e96804a159d76e21322f9ac0561..4d0f61e8cb0e33aa97584a9caaff64bbe6897bff 100644 (file)
--- a/examples/step-18/doc/results.dox
+++ b/examples/step-18/doc/results.dox
@@ -404,7 +404,7 @@ Without such a formulation we cannot expect anything to make physical sense,
 even if it produces nice pictures!
 
 
-<h3>Possible directions for extensions</h3>
+<h3>Possibilities for extensions</h3>
 
 The program as is does not really solve an equation that has many applications
 in practice: quasi-static material deformation based on a purely elastic law

diff --git a/examples/step-2/doc/results.dox b/examples/step-2/doc/results.dox
index 3f2f7542b87479e58b57a458ac18540037adcfcd..6fa3556c2a51ee7d8abbaf9088b3993e9babac1d 100644 (file)
--- a/examples/step-2/doc/results.dox
+++ b/examples/step-2/doc/results.dox
@@ -26,7 +26,7 @@ nonzero entries is the same in both pictures, of course.
 
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 Just as with step-1, you may want to play with the program a bit to
 familiarize yourself with deal.II. For example, in the

diff --git a/examples/step-22/doc/results.dox b/examples/step-22/doc/results.dox
index af3677b7dc1d7d469b810911e452bcd869b46d39..5fcd81f4254271dc84ceabacbe34339c44e1bc3f 100644 (file)
--- a/examples/step-22/doc/results.dox
+++ b/examples/step-22/doc/results.dox
@@ -278,7 +278,7 @@ is not a good choice in 3D - a full decomposition needs many new entries that
 
 
 
-<h3>Possible Extensions</h3>
+<h3>Possibilities for extensions</h3>
 
 <a name="improved-solver">
 <h4>Improved linear solver in 3D</h4>

diff --git a/examples/step-31/doc/results.dox b/examples/step-31/doc/results.dox
index 6f16187468398c1012f127f240bcb51fe0d04cbd..e2d8a0307a52543864be94b4d6ee738dc6f8871a 100644 (file)
--- a/examples/step-31/doc/results.dox
+++ b/examples/step-31/doc/results.dox
@@ -585,7 +585,7 @@ more accurate; the program therefore uses these higher order elements,
 despite the penalty we pay in terms of smaller time steps.
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 There are various ways to extend the current program. Of particular interest
 is, of course, to make it faster and/or increase the resolution of the

diff --git a/examples/step-35/doc/results.dox b/examples/step-35/doc/results.dox
index 5cb50255c0f641f55e7a9bcada06ab1fc9eed2a0..9d8ea02f783a0e0515dbe1116c258931ed365d55 100644 (file)
--- a/examples/step-35/doc/results.dox
+++ b/examples/step-35/doc/results.dox
@@ -131,7 +131,7 @@ resolutions, as described below.
 
 
 <a name="extensions"></a>
-<h3> Possible Extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 This program can be extended in the following directions:
 <ul>

diff --git a/examples/step-49/doc/results.dox b/examples/step-49/doc/results.dox
index afad98309426a48f392e82eb0cbc1ab5b709b7ce..27ae172399642fdeb48114c00194bcc0273d2208 100644 (file)
--- a/examples/step-49/doc/results.dox
+++ b/examples/step-49/doc/results.dox
@@ -334,7 +334,7 @@ the nice detail of the boundary fitted mesh if we refine two more times:
      alt="" width="400" height="355">
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 <h4> Assigning different boundary ids </h4>
 

diff --git a/examples/step-50/doc/results.dox b/examples/step-50/doc/results.dox
index 91148a04b41b8a64b024042249f30a70e14b1899..64a5b1095bae704aba6276bcbc70dfbbce3e3fa5 100644 (file)
--- a/examples/step-50/doc/results.dox
+++ b/examples/step-50/doc/results.dox
@@ -266,7 +266,7 @@ same problem on the same number of processors in about one eighth the
 time.
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 <h4> Testing convergence and higher order elements </h4>
 

diff --git a/examples/step-56/doc/results.dox b/examples/step-56/doc/results.dox
index e733a4c269293fb11922e69b7cb00f066594f685..1a152ed4e52914b3321b24d0437ab42747da019a 100644 (file)
--- a/examples/step-56/doc/results.dox
+++ b/examples/step-56/doc/results.dox
@@ -189,7 +189,7 @@ solve time.
 4. GMG needs slightly more memory than ILU to store the level and interface
 matrices.
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 <h4> Check higher order discretizations </h4>
 

diff --git a/examples/step-64/doc/results.dox b/examples/step-64/doc/results.dox
index b622aa0eae84c5bb643a4abfb4bd6feac3b70fca..e92e1053c80eb4bc565eb6fe62e8a0d8ff7f96d7 100644 (file)
--- a/examples/step-64/doc/results.dox
+++ b/examples/step-64/doc/results.dox
@@ -43,7 +43,7 @@ using a better preconditioner than the identity matrix we have used here.
 
 
 <a name="extensions"></a>
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 Currently, this program uses no preconditioner at all. This is mainly
 since constructing an efficient matrix-free preconditioner is

diff --git a/examples/step-7/doc/results.dox b/examples/step-7/doc/results.dox
index 7c8caa48292cec34c41660405650ba23bf93df7c..b4b756b5cee610c53ebd4f69f0230b92d33c868c 100644 (file)
--- a/examples/step-7/doc/results.dox
+++ b/examples/step-7/doc/results.dox
@@ -260,7 +260,7 @@ norms into one global norm as we already do in the program, by calling
 
 
 
-<h3> Possible extensions </h3>
+<h3> Possibilities for extensions </h3>
 
 <h4> Higher Order Elements </h4>