From: Timo Heister Date: Sun, 17 Jan 2016 19:46:27 +0000 (-0600) Subject: table layout and image fixes X-Git-Tag: v8.4.0-rc2~87^2~2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b73f27026660cda9db2aa4578d754bbc9d190672;p=dealii.git table layout and image fixes - fix weird case where doxygen shifts the last cell in a table downward causing them to be not correctly aligned - cleanup some image layout - do not break image tags (this will break various scripts) --- diff --git a/examples/step-10/doc/results.dox b/examples/step-10/doc/results.dox index dcc5dac011..cf8631b72e 100644 --- a/examples/step-10/doc/results.dox +++ b/examples/step-10/doc/results.dox @@ -25,52 +25,38 @@ The following table shows the triangulated computational domain for Q1, Q2, and Q3 mappings, for the original coarse grid (left), and a once uniformly refined grid (right). If your browser does not display these pictures in acceptable quality, view them one by one. - + +
- - + + - - + + - - + +
- - - -
- - - -
- - - -
+ These pictures show the obvious advantage of higher order mappings: they approximate the true boundary quite well also on rather coarse meshes. To demonstrate this a little further, the following table shows the upper right quarter of the circle of the coarse mesh, and with dashed lines the exact circle: - + +
- - - + + +
- - - - - -
+ Obviously the quadratic mapping approximates the boundary quite well, while for the cubic mapping the difference between approximated domain and true one is hardly visible already for the coarse grid. You can diff --git a/examples/step-14/doc/results.dox b/examples/step-14/doc/results.dox index 6601976f7d..1cb435b22d 100644 --- a/examples/step-14/doc/results.dox +++ b/examples/step-14/doc/results.dox @@ -71,38 +71,21 @@ differently. Looking at the grids that are produced in the course of subsequent -refinement, these are some of them: - - - - - - +refinement, here are some of them: +
- - - -
- - - + + + - - - - + + +
- - - -
- - - -
+ Note the subtle interplay between resolving the corner singularities, and resolving around the point of evaluation. It will be rather difficult to generate such a mesh by hand, as this would involve to @@ -141,15 +124,10 @@ close to each other, even for such a complicated quantity as the point value: - +
- - - + +
- - - -
@@ -255,37 +233,20 @@ evaluation shows this: This time, the grids in refinement cycles 0, 5, 6, 7, 8, and 9 look like this: - - - - - - +
- - - -
- - - + + + - - - - + + +
- - - -
- - - -
+ Note the asymmetry of the grids compared with those we obtained for the point evaluation, which is due to the directionality of the x-derivative for which we tailored the refinement criterion. @@ -306,17 +267,14 @@ in the result. In the left part of the following chart, you again see the convergence of the error towards this extrapolated value, while on the right you see a comparison of true and estimated error: - - - - +
- - - -
+ + +
+ After an initial phase where the true error changes its sign, the estimated error matches it quite well, again. Also note the dramatic improvement in the error when using the estimated error to correct the @@ -337,29 +295,26 @@ are better than those we had previously. First, the meshes after 9 and 10 adaptive refinement cycles, respectively, look like this: - - - - +
- - - -
+ + +
+ The features of the solution can still be seen slightly, but since the solution is smooth, the roughness of the dual solution entirely dominates the mesh refinement criterion, and leads to strongly concentrated meshes. The solution after the seventh refinement step is like so: - + +
- +
- -
+ Obviously, the solution is worse at some places, but the mesh refinement process should have taken care that these places are not important for computing the point value. diff --git a/examples/step-17/doc/results.dox b/examples/step-17/doc/results.dox index 4da8e77bd8..19c56e1a3e 100644 --- a/examples/step-17/doc/results.dox +++ b/examples/step-17/doc/results.dox @@ -120,19 +120,13 @@ entries locally or not. Here is some output generated in the 12th cycle of the program, i.e. with roughly 300,000 unknowns: - +
- - + +
- - - -
- - As one would hope for, the x- (left) and y-displacements (right) shown here closely match what we already saw in step-8. As shown there and in step-22, we could as well have produced a @@ -140,19 +134,13 @@ vector plot of the displacement field, rather than plotting it as two separate scalar fields. What may be more interesting, though, is to look at the mesh and partition at this step: - - +
- - + +
- - - -
- Again, the mesh (left) shows the same refinement pattern as seen previously. The right panel shows the partitioning of the domain across the 8 processes, each indicated by a different color. The picture shows that the @@ -229,14 +217,10 @@ graphical output generated by this job is rather large (cycle 5 already prints around 82 MB of data), so we contend ourselves with showing output from cycle 4: - +
- - + +
- - - -
diff --git a/examples/step-2/doc/results.dox b/examples/step-2/doc/results.dox index 9066dbb5b7..6fde7c7cc2 100644 --- a/examples/step-2/doc/results.dox +++ b/examples/step-2/doc/results.dox @@ -9,15 +9,10 @@ zero or not depends on the equation under consideration, but the indicated positions in the matrix tell us which shape functions can and which can't couple when discretizing a local, i.e. differential, equation): - +
- - - + +
- - - -
diff --git a/examples/step-20/doc/results.dox b/examples/step-20/doc/results.dox index 20ece4a3e2..1dcd7b176f 100644 --- a/examples/step-20/doc/results.dox +++ b/examples/step-20/doc/results.dox @@ -219,10 +219,12 @@ Remember that the function returns the inverse of the permeability tensor. With a significantly higher mesh resolution, we can visualize this, here with x- and y-velocity: - - - - + + + + + +
It is obvious how fluids flow essentially only along the middle line, and not anywhere else. @@ -298,9 +300,12 @@ looks as follows: With a permeability field like this, we would get x-velocities and pressures as follows: - - - + + + + + +
We will use these permeability fields again in step-21 and step-43. diff --git a/examples/step-23/doc/results.dox b/examples/step-23/doc/results.dox index 1c86e3eb7d..f630d8b8cb 100644 --- a/examples/step-23/doc/results.dox +++ b/examples/step-23/doc/results.dox @@ -65,9 +65,7 @@ In addition to the screen output, the program writes the solution of each time step to an output file. If we process them adequately and paste them into a movie, we get the following: - +Animation of the solution of step 23. The movie shows the generated wave nice traveling through the domain and back, being reflected at the clamped boundary. Some numerical noise is trailing the diff --git a/examples/step-26/doc/results.dox b/examples/step-26/doc/results.dox index 58a105902d..92c5396721 100644 --- a/examples/step-26/doc/results.dox +++ b/examples/step-26/doc/results.dox @@ -41,9 +41,7 @@ Number of degrees of freedom: 2109 Maybe of more interest is a visualization of the solution and the mesh on which it was computed: - +Animation of the solution of step 26. The movie shows how the two sources switch on and off and how the mesh reacts to this. It is quite obvious that the mesh as is is probably not the best we diff --git a/examples/step-27/doc/results.dox b/examples/step-27/doc/results.dox index bb721c292e..bc82a7067b 100644 --- a/examples/step-27/doc/results.dox +++ b/examples/step-27/doc/results.dox @@ -58,57 +58,34 @@ solution of the problem: Secondly, let us look at the sequence of meshes generated: - +
- - - + + + - - - - + + +
- - - - - -
- - - - - -
+ It is clearly visible how the mesh is refined near the corner singularities, as one would expect it. More interestingly, we should be curious to see the distribution of finite element polynomial degrees to these mesh cells: - + +
- - - + + + - - - + + +
- - - - - -
- - - - - -
@@ -123,29 +100,17 @@ This arrangement of polynomial degrees of course follows from our smoothness estimator. Here is the estimated smoothness of the solution, with blue colors indicating least smoothness and red indicating the smoothest areas: - +
- - - + + + - - - + + +
- - - - - -
- - - - - -
diff --git a/examples/step-36/doc/results.dox b/examples/step-36/doc/results.dox index 0644023a6b..dfe659761a 100644 --- a/examples/step-36/doc/results.dox +++ b/examples/step-36/doc/results.dox @@ -34,31 +34,17 @@ correspond to pairs $(m,n)=(1,1)$, $(1,2)$ and $(2,1)$, $(2,2)$, and $(3,1)$. A visualization of the corresponding eigenfunctions would look like this: - +
- - + + + - - - - - - - + + +
- - - -
- - - -
- - -
@@ -120,31 +106,17 @@ circle of the potential): The first five eigenfunctions are now like this: - - - - - - +
- - - -
- - + + + - - + + +
- - - -
- - -
diff --git a/examples/step-49/doc/intro.dox b/examples/step-49/doc/intro.dox index f6b14ff9ad..83f3239b76 100644 --- a/examples/step-49/doc/intro.dox +++ b/examples/step-49/doc/intro.dox @@ -147,6 +147,7 @@ given mesh using a smooth function. An example of its use is also given in the 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: +
@@ -176,6 +177,7 @@ of this tutorial: 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: +
@@ -211,20 +213,12 @@ to make sure that cells line up correctly and no unpaired nodes exist in the merged Triangulation. These are the input meshes and the output mesh: - - - - - +
- input mesh 1 - - input mesh 2 - - merged mesh -
+ + + +
input mesh 1input mesh 2merged mesh
diff --git a/examples/step-49/doc/results.dox b/examples/step-49/doc/results.dox index 31824d9630..ed20909c73 100644 --- a/examples/step-49/doc/results.dox +++ b/examples/step-49/doc/results.dox @@ -16,18 +16,14 @@ the coarse mesh. Several of the meshes shown in the introduction section fall into this category. For example, for this mesh the central hole is supposed to be round: - + On the other hand, if you simply refine it, the Triangulation class can not know whether you wanted the hole to be round or to be an octagon. The default is to place new points along existing edges. After two mesh refinement steps, this would yield the following mesh, which is not what we wanted: - + What needs to happen is that you tell the triangulation that you in fact want to use a curved boundary. The way to do this requires three steps: @@ -50,9 +46,7 @@ The goal was to generate (and use) a geometry that describes a microstructured electric device. In a CAD program, the geometry looks like this: - + In the following, we will walk you through the entire process of creating a mesh for this geometry, including a number of common pitfalls by showing the @@ -233,9 +227,7 @@ void create_3d_grid (Triangulation<3> &triangulation) With this code, you get a mesh that looks like this: - + The next step is to teach each of the top surfaces that they should be curved. We can do this by creating CylinderBoundary objects that @@ -291,9 +283,7 @@ describe this. A first attempt looks like this: With this code, we get a mesh that looks like this: - + This is clearly not correct: The new vertices that have been entered at mid-edge and mid-face points are not where they should have been. Upon some @@ -315,9 +305,7 @@ axis: This yields an improvement, though it is still not quite correct: - + Looking closely at this mesh, we realize that the new points on mid-face vertices are where they should be, though the new vertices inserted at @@ -329,9 +317,7 @@ easily fixed by using the function TriaAccessor::set_all_boundary_ids() instead of TriaAccessor::set_boundary_id() used above. With this change, the grid now looks like this: - + This is already better. However, something is still going wrong on the front left face. On second look, we can also see that the faces where @@ -386,15 +372,11 @@ code does the trick: With this, we finally get a mesh that looks good: - + We can then refine the mesh two more times to see in more detail what happens to the curved part of the boundary: - + So, yes!, this is finally what we were looking for! diff --git a/examples/step-51/doc/results.dox b/examples/step-51/doc/results.dox index 28300a4d9d..06ef541ea1 100644 --- a/examples/step-51/doc/results.dox +++ b/examples/step-51/doc/results.dox @@ -31,22 +31,14 @@ the interior variables do not exactly satisfy boundary conditions. On the lower and left boundaries, we set Neumann boundary conditions, whereas we set Dirichlet conditions on the right and top boundaries. - +
- - + + - - + +
- - - -
- - - -
@@ -57,22 +49,14 @@ cycle two, it looks much better for cycles three and four. As shown by the convergence table below, we find that is also converges more quickly to the analytical solution. - +
- - + + - - + +
- - - -
- - - -
@@ -82,14 +66,10 @@ to the linear solution (not post-processed) at cycle 8 with 4,096 cells. This clearly shows the superiority of high order methods for smooth solutions. - +
- - + +
- - - -
@@ -218,14 +198,10 @@ TrilinosWrappers::PreconditionAMG. For the HDG part, a wrapper around ChunkSparseMatrix for the trace variable has been used in order to utilize the block structure in the matrix on the finest level. - +
- - + +
- - - -
@@ -239,14 +215,10 @@ by $p=1^*$ for example). We now see a clear advantage of HDG for the same amount of work for both $p=3$ and $p=6$, and about the same quality for $p=1$. - +
- - + +
- - - -
@@ -257,14 +229,10 @@ $p+1$. If we do this, we get the convergence curves below. We see that CG with second order polynomials is again clearly better than HDG with linears. However, the advantage of HDG for higher orders remains. - +
- - + +
- - - -
@@ -294,30 +262,18 @@ degree $p$. There are fewer degrees of freedom on the skeleton variable for FE_FaceP for a given mesh size, but the solution quality (error vs. number of DoFs) is very similar to the results for FE_FaceQ. - +
- - + + - - + + - - + +
- - - -
- - - -
- - - -