From: Timo Heister Date: Mon, 13 May 2019 17:51:40 +0000 (-0600) Subject: lower case html tables X-Git-Tag: v9.1.0-rc1~23^2~1 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7c9abe8f96a716904897340b6b952e52aeda3f2c;p=dealii.git lower case html tables --- diff --git a/examples/step-1/doc/results.dox b/examples/step-1/doc/results.dox index dc64e8e973..d2e1b749a2 100644 --- a/examples/step-1/doc/results.dox +++ b/examples/step-1/doc/results.dox @@ -2,13 +2,13 @@ Running the program produces graphics of two grids (grid-1.eps and grid-2.eps). They look like this: - +
- - diff --git a/examples/step-22/doc/results.dox b/examples/step-22/doc/results.dox index a1f44fec28..92da01f044 100644 --- a/examples/step-22/doc/results.dox +++ b/examples/step-22/doc/results.dox @@ -73,33 +73,33 @@ and 1 in the right one, so there is an abrupt change at $x=0$. Likewise, there are changes from Dirichlet to Neumann data in the two upper corners, so there is need for refinement there as well: -
+ +
+
- - - - - - @@ -184,33 +184,33 @@ href="#improved-solver">below. As for the graphical output, the grids generated during the solution look as follow: -
+ +
+ +
+ +
+
- - - - - - @@ -791,13 +791,13 @@ $[-2,2]\times[-2,2]\times[-1,0]$ top_right); @endcode then we get images where the fault line is curved: -
+ +
+ +
+ +
+
- - diff --git a/examples/step-24/doc/results.dox b/examples/step-24/doc/results.dox index 83742a45a1..782671bdc0 100644 --- a/examples/step-24/doc/results.dox +++ b/examples/step-24/doc/results.dox @@ -45,7 +45,7 @@ experiments, and the right is the simulated data. In the experiment, a single small strong absorber was embedded in weaker absorbing tissue: -
+ +
+
@@ -90,7 +90,7 @@ thermoacoustic waves in the medium by multiple absorbers: Experimental data and our simulated data are compared in the following two figures: - +
@@ -113,7 +113,7 @@ As before, the numerical result better matches experimental ones by applying a bandwidth filter that matches the actual behavior of detectors (left) and by choosing a finer mesh (right): - +
diff --git a/examples/step-3/doc/results.dox b/examples/step-3/doc/results.dox index 6e61813cf7..acff9e72f6 100644 --- a/examples/step-3/doc/results.dox +++ b/examples/step-3/doc/results.dox @@ -52,13 +52,13 @@ gnuplot> set hidden3d @endcode to get the result at the right: - +
- - diff --git a/examples/step-30/doc/results.dox b/examples/step-30/doc/results.dox index a71e3208e0..3fee521397 100644 --- a/examples/step-30/doc/results.dox +++ b/examples/step-30/doc/results.dox @@ -105,22 +105,22 @@ Now we show the solutions on the mesh after one and after five adaptive refinement steps for both the isotropic (left) and anisotropic refinement algorithms (right). -
+ +
+
- - - - diff --git a/examples/step-4/doc/results.dox b/examples/step-4/doc/results.dox index 58d78a0fac..4c35ac210c 100644 --- a/examples/step-4/doc/results.dox +++ b/examples/step-4/doc/results.dox @@ -68,13 +68,13 @@ constant values (as indicated by the legend at the top left). Isosurface pictures look best if one makes the individual surfaces slightly transparent so that it is possible to see through them and see what's behind. -
+ +
+ +
+
- - diff --git a/examples/step-40/doc/results.dox b/examples/step-40/doc/results.dox index 858e709810..e5ff573179 100644 --- a/examples/step-40/doc/results.dox +++ b/examples/step-40/doc/results.dox @@ -63,7 +63,7 @@ such big problems can no longer be visualized, so we also ran the program on only 16 processors. Here are a mesh, along with its partitioning onto the 16 processors, and the corresponding solution: -
+ +
+
@@ -86,7 +86,7 @@ graphs are taken from an earlier version of the data of runs on even larger numbers of processors, and a lot more interpretation can be found in the final version of the paper): - +
@@ -114,7 +114,7 @@ interesting question may be how big problems can become so that they can still be solved within a reasonable time on a machine of a particular size. We show this in the following two graphs for 256 and 4096 processors: - +
diff --git a/examples/step-46/doc/results.dox b/examples/step-46/doc/results.dox index 5dd81a8992..f2a135216f 100644 --- a/examples/step-46/doc/results.dox +++ b/examples/step-46/doc/results.dox @@ -51,7 +51,7 @@ Refinement cycle 5 The results are easily visualized: - +
@@ -137,7 +137,7 @@ minutes). Clearly a better solver is needed here, a topic discussed below. The results can also be visualized and yield some good pictures: - +
diff --git a/examples/step-49/doc/intro.dox b/examples/step-49/doc/intro.dox index 3812034578..0efbd5a60f 100644 --- a/examples/step-49/doc/intro.dox +++ b/examples/step-49/doc/intro.dox @@ -148,46 +148,46 @@ results section of step-38 but let us show a simpler example here: In the function grid_5() of the current program, we perturb the y coordinate of a mesh with a sine curve: - +
- - -
+ regular input mesh + output mesh
+
Similarly, we can transform a regularly refined unit square to a wall-adapted mesh in y direction using the formula $(x,y) \mapsto (x,\tanh(2 y)/\tanh(2))$. This is done in grid_6() of this tutorial: - +
- - -
+ regular input mesh + wall-adapted output mesh
+
Finally, the function GridTools::distort_random allows you to move vertices in the mesh (optionally ignoring boundary nodes) by a random amount. This is demonstrated in grid_7() and the result is as follows: - +
- - -
+ regular input mesh + perturbed output mesh
+
This function is primarily intended to negate some of the superconvergence effects one gets when studying convergence on regular meshes, as well as to @@ -216,9 +216,9 @@ These are the input meshes and the output mesh: - - - + + +
input mesh 1input mesh 2merged meshinput mesh 1input mesh 2merged mesh
@@ -231,13 +231,13 @@ or inverted cells and you shouldn't expect anything useful to come of using such meshes. Here, we create a box with a cylindrical hole that is not exactly centered by moving the top vertices upwards: - +
- - @@ -257,13 +257,13 @@ GridGenerator::hyper_cube_with_cylindrical_hole(). The main usage is a 2d mesh, generated for example with Gmsh, that is read in from a .msh file as described above. This is the output from grid_4(): -
+ input mesh + top vertices moved upwards
+
- - diff --git a/examples/step-5/doc/results.dox b/examples/step-5/doc/results.dox index 0016af675a..a4114a26de 100644 --- a/examples/step-5/doc/results.dox +++ b/examples/step-5/doc/results.dox @@ -44,7 +44,7 @@ format. They are depicted in the following: -
+ input mesh + extruded output mesh
+
diff --git a/examples/step-57/doc/results.dox b/examples/step-57/doc/results.dox index ad70d60b3e..6dbb68d388 100644 --- a/examples/step-57/doc/results.dox +++ b/examples/step-57/doc/results.dox @@ -124,23 +124,23 @@ $8 \times 8$ mesh, and the mesh is refined adaptively. Between meshes, the solution from the coarse mesh is interpolated to the fine mesh to be used as an initial guess. - +
- - - - - @@ -299,23 +299,23 @@ mesh. The quadratic convergence is clearly visible in the table. The sequence of generated grids looks like this: -
+ + +
+ +
+
- - - - - diff --git a/examples/step-6/doc/results.dox b/examples/step-6/doc/results.dox index 90dc8223f9..37ae6b77e6 100644 --- a/examples/step-6/doc/results.dox +++ b/examples/step-6/doc/results.dox @@ -163,13 +163,13 @@ step-4) as well as CPU time needed (using the Timer class, discussed, for example, in step-12) and get the following results (left: iterations; right: CPU time): -
+ + +
+ +
+
- - @@ -187,13 +187,13 @@ The situation changes slightly when the finite element is not a bi-quadratic one as set in the constructor of this program, but a bi-linear one. If one makes this change, the results are as follows: -
+ +
+
- - diff --git a/examples/step-8/doc/results.dox b/examples/step-8/doc/results.dox index 5d0d4271c7..3179c1a22a 100644 --- a/examples/step-8/doc/results.dox +++ b/examples/step-8/doc/results.dox @@ -6,7 +6,7 @@ that they look nice. All images were made using Visit from the output files that the program wrote to disk. The first two pictures show the $x$- and $y$-displacements as scalar components: -
+ +
+