From 963cfe566d4eba6c0f5b382e275a04ba7f59c149 Mon Sep 17 00:00:00 2001 From: Guido Kanschat Date: Sat, 19 Mar 2016 09:32:35 -0500 Subject: [PATCH] Use https to access images in tutorials --- examples/step-1/doc/results.dox | 4 +- examples/step-10/doc/results.dox | 18 ++++----- examples/step-12/doc/results.dox | 24 +++++------ examples/step-13/doc/results.dox | 24 +++++------ examples/step-14/doc/results.dox | 48 +++++++++++----------- examples/step-15/doc/results.dox | 18 ++++----- examples/step-16/doc/results.dox | 2 +- examples/step-17/doc/results.dox | 12 +++--- examples/step-18/doc/results.dox | 28 ++++++------- examples/step-19/doc/results.dox | 2 +- examples/step-2/doc/results.dox | 4 +- examples/step-20/doc/results.dox | 16 ++++---- examples/step-21/doc/results.dox | 6 +-- examples/step-22/doc/intro.dox | 4 +- examples/step-22/doc/results.dox | 38 +++++++++--------- examples/step-23/doc/results.dox | 2 +- examples/step-24/doc/results.dox | 22 +++++------ examples/step-25/doc/results.dox | 10 ++--- examples/step-26/doc/results.dox | 2 +- examples/step-27/doc/results.dox | 38 +++++++++--------- examples/step-28/doc/results.dox | 10 ++--- examples/step-29/doc/results.dox | 10 ++--- examples/step-3/doc/results.dox | 4 +- examples/step-30/doc/results.dox | 10 ++--- examples/step-31/doc/results.dox | 68 ++++++++++++++++---------------- examples/step-32/doc/intro.dox | 6 +-- examples/step-32/doc/results.dox | 58 +++++++++++++-------------- examples/step-34/doc/results.dox | 6 +-- examples/step-35/doc/intro.dox | 2 +- examples/step-35/doc/results.dox | 32 +++++++-------- examples/step-36/doc/results.dox | 22 +++++------ examples/step-37/doc/results.dox | 2 +- examples/step-38/doc/results.dox | 8 ++-- examples/step-39/doc/results.dox | 2 +- examples/step-4/doc/results.dox | 6 +-- examples/step-40/doc/results.dox | 12 +++--- examples/step-41/doc/intro.dox | 4 +- examples/step-41/doc/results.dox | 48 +++++++++++----------- examples/step-42/doc/intro.dox | 4 +- examples/step-42/doc/results.dox | 6 +-- examples/step-43/doc/results.dox | 8 ++-- examples/step-44/doc/intro.dox | 2 +- examples/step-44/doc/results.dox | 22 +++++------ examples/step-45/doc/results.dox | 4 +- examples/step-46/doc/intro.dox | 2 +- examples/step-46/doc/results.dox | 14 +++---- examples/step-49/doc/intro.dox | 30 +++++++------- examples/step-49/doc/results.dox | 18 ++++----- examples/step-5/doc/results.dox | 12 +++--- examples/step-51/doc/results.dox | 44 ++++++++++----------- examples/step-53/doc/intro.dox | 2 +- examples/step-53/doc/results.dox | 8 ++-- examples/step-54/doc/intro.dox | 12 +++--- examples/step-54/doc/results.dox | 54 ++++++++++++------------- examples/step-6/doc/results.dox | 44 ++++++++++----------- examples/step-7/doc/results.dox | 2 +- examples/step-8/doc/results.dox | 8 ++-- examples/step-9/doc/results.dox | 4 +- 58 files changed, 466 insertions(+), 466 deletions(-) diff --git a/examples/step-1/doc/results.dox b/examples/step-1/doc/results.dox index 68eabe3d80..5b5dcab46e 100644 --- a/examples/step-1/doc/results.dox +++ b/examples/step-1/doc/results.dox @@ -5,11 +5,11 @@ Running the program produces graphics of two grids (grid-1.eps and grid-2.eps).
- + - +
diff --git a/examples/step-10/doc/results.dox b/examples/step-10/doc/results.dox index cf8631b72e..693d33c604 100644 --- a/examples/step-10/doc/results.dox +++ b/examples/step-10/doc/results.dox @@ -28,18 +28,18 @@ these pictures in acceptable quality, view them one by one. - - + + - - + + - - + +
@@ -51,9 +51,9 @@ with dashed lines the exact circle: - - - + + +
diff --git a/examples/step-12/doc/results.dox b/examples/step-12/doc/results.dox index ed1a3f92fd..985eb2f657 100644 --- a/examples/step-12/doc/results.dox +++ b/examples/step-12/doc/results.dox @@ -51,9 +51,9 @@ DEAL::Writing solution to We show the solutions on the initial mesh, the mesh after two and after five adaptive refinement steps. - - - + + + Then we show the final grid (after 5 refinement steps) and the solution again, @@ -62,13 +62,13 @@ function and the VTK-based VisIt visualization program) that better shows the sharpness of the jump on the refined mesh and the over- and undershoots of the solution along the interface: - - + + And finally we show a plot of a 3d computation. - + @@ -97,14 +97,14 @@ refinement, results look much different when using a continuous element: 0   - + 1   - + @@ -113,14 +113,14 @@ refinement, results look much different when using a continuous element: 2   - + 3   - + @@ -129,14 +129,14 @@ refinement, results look much different when using a continuous element: 4   - + 5   - + diff --git a/examples/step-13/doc/results.dox b/examples/step-13/doc/results.dox index 228457ff59..1d95429259 100644 --- a/examples/step-13/doc/results.dox +++ b/examples/step-13/doc/results.dox @@ -58,46 +58,46 @@ first 9 refinement steps of the Kelly refinement indicator:
- + - +
- + - +
- + - +
- + - +
- + - +
@@ -107,7 +107,7 @@ While we're already at watching pictures, this is the eighth grid, as viewed from top: - + However, we are not yet finished with evaluation the point value @@ -116,7 +116,7 @@ $e=|u(x_0)-u_h(x_0)|$ for the two refinement criteria yields the following picture: - + diff --git a/examples/step-14/doc/results.dox b/examples/step-14/doc/results.dox index 1cb435b22d..84d375caf7 100644 --- a/examples/step-14/doc/results.dox +++ b/examples/step-14/doc/results.dox @@ -52,11 +52,11 @@ grid, primal and dual numerical solutions look like this:
- + - +
@@ -75,14 +75,14 @@ refinement, here are some of them: - - - + + + - - - + + +
@@ -126,8 +126,8 @@ value: - - + +
@@ -147,7 +147,7 @@ function $1/(r^2+0.1^2)$, where $r$ is the distance to the evaluation point; it can be shown that this is the optimal weight if we neglect the effects of boundaries): - + @@ -228,7 +228,7 @@ evaluation shows this:
- +
This time, the grids in refinement cycles 0, 5, 6, 7, 8, and 9 look @@ -236,14 +236,14 @@ like this: - - - + + + - - - + + +
@@ -270,8 +270,8 @@ see a comparison of true and estimated error: - - + +
@@ -298,8 +298,8 @@ respectively, look like this: - - + +
@@ -311,7 +311,7 @@ like so: - +
@@ -325,7 +325,7 @@ important for computing the point value. The next point is to compare the new (duality based) mesh refinement criterion with the old ones. These are the results: - + diff --git a/examples/step-15/doc/results.dox b/examples/step-15/doc/results.dox index 75e78a1104..b1eba5ec90 100644 --- a/examples/step-15/doc/results.dox +++ b/examples/step-15/doc/results.dox @@ -35,37 +35,37 @@ solution. This yields the following set of images:
- + - +
- + - +
- + - +
- + - +
@@ -85,7 +85,7 @@ the inside of the domain, where nothing interesting happens, because there isn't much change in the solution. The final solution and mesh are shown here: - + diff --git a/examples/step-16/doc/results.dox b/examples/step-16/doc/results.dox index 3de588e1c5..f1835761b5 100644 --- a/examples/step-16/doc/results.dox +++ b/examples/step-16/doc/results.dox @@ -3,7 +3,7 @@ On the finest mesh, the solution looks like this:

- +

More importantly, we would like to see if the multigrid method really diff --git a/examples/step-17/doc/results.dox b/examples/step-17/doc/results.dox index 19c56e1a3e..f8d96b5cd3 100644 --- a/examples/step-17/doc/results.dox +++ b/examples/step-17/doc/results.dox @@ -122,8 +122,8 @@ Here is some output generated in the 12th cycle of the program, i.e. with roughl - - + +
@@ -136,8 +136,8 @@ though, is to look at the mesh and partition at this step: - - + +
@@ -219,8 +219,8 @@ we contend ourselves with showing output from cycle 4: - - + +
diff --git a/examples/step-18/doc/results.dox b/examples/step-18/doc/results.dox index 18cdad961e..17a7059a21 100644 --- a/examples/step-18/doc/results.dox +++ b/examples/step-18/doc/results.dox @@ -135,34 +135,34 @@ images encode the norm of the stress in the material): @@ -265,11 +265,11 @@ for the 16 processors:
- + Time = 2 - + Time = 5 - + Time = 7
- + Time = 8 - + Time = 9 - + Time = 10
- + - +
@@ -282,34 +282,34 @@ sequential case: diff --git a/examples/step-19/doc/results.dox b/examples/step-19/doc/results.dox index 39fe3634b4..a9fcd3babe 100644 --- a/examples/step-19/doc/results.dox +++ b/examples/step-19/doc/results.dox @@ -209,7 +209,7 @@ examples/\step-19> ls -l solution-0005.gnuplot We can then visualize this one file with gnuplot, obtaining something like this: - + That's not particularly exciting, but the file we're looking at has only one 32nd of the entire domain anyway, so we can't expect much. diff --git a/examples/step-2/doc/results.dox b/examples/step-2/doc/results.dox index 6fde7c7cc2..99d18e512b 100644 --- a/examples/step-2/doc/results.dox +++ b/examples/step-2/doc/results.dox @@ -11,8 +11,8 @@ and which can't couple when discretizing a local, i.e. differential, equation):
- + Time = 2 - + Time = 5 - + Time = 7
- + Time = 8 - + Time = 9 - + Time = 10
- - + +
diff --git a/examples/step-20/doc/results.dox b/examples/step-20/doc/results.dox index 3566e5ea0e..42dbf45171 100644 --- a/examples/step-20/doc/results.dox +++ b/examples/step-20/doc/results.dox @@ -27,9 +27,9 @@ The fact that the number of iterations is so small, of course, is due to good solution, let us take a look at it. The following three images show (from left to right) the x-velocity, the y-velocity, and the pressure: - - - + + + @@ -221,8 +221,8 @@ x- and y-velocity: - - + +
@@ -294,7 +294,7 @@ A piecewise constant interpolation of the diagonal elements of the inverse of this tensor (i.e., of normalized_permeability) looks as follows: - + With a permeability field like this, we would get x-velocities and pressures as @@ -302,8 +302,8 @@ follows: - - + +
diff --git a/examples/step-21/doc/results.dox b/examples/step-21/doc/results.dox index b8c7d7892c..cf2fb3232d 100644 --- a/examples/step-21/doc/results.dox +++ b/examples/step-21/doc/results.dox @@ -52,7 +52,7 @@ With all this, here are a few movies that show how the saturation progresses over time. First, this is for the single crack model, as implemented in the SingleCurvingCrack::KInverse class: - + As can be seen, the water rich fluid snakes its way mostly along the high-permeability zone in the middle of the domain, whereas the rest of the @@ -66,14 +66,14 @@ The second movie shows the saturation for the random medium model of class centers of high permeability and fluid hops from one of these zones to the next: - + Finally, here is the same situation in three space dimensions, on a mesh with n_refinement_steps=5, which produces a mesh of some 32,000 cells and 167,000 degrees of freedom: - + To repeat these computations, all you have to do is to change the line @code diff --git a/examples/step-22/doc/intro.dox b/examples/step-22/doc/intro.dox index 5c0ce904dd..be9ba4ae35 100644 --- a/examples/step-22/doc/intro.dox +++ b/examples/step-22/doc/intro.dox @@ -787,7 +787,7 @@ A profile of how many CPU instructions are spent at the various different places in the program during refinement cycles zero through three in 3d is shown here: - + As can be seen, at this refinement level approximately three quarters of the instruction count is spent on the actual solver (the SparseILU::vmult calls @@ -816,7 +816,7 @@ discussion of results below as well. As a final point, and as a point of reference, the following picture also shows how the profile looked at an early stage of optimizing this program: - + As mentioned above, the runtime of this version was about four times as long as for the first profile, with the SparseILU decomposition taking up about diff --git a/examples/step-22/doc/results.dox b/examples/step-22/doc/results.dox index f115fd9b58..a858d39ab9 100644 --- a/examples/step-22/doc/results.dox +++ b/examples/step-22/doc/results.dox @@ -75,31 +75,31 @@ corners, so there is need for refinement there as well:
- + - +
- + - +
- + - +
@@ -108,7 +108,7 @@ Finally, following is a plot of the flow field. It shows fluid transported along with the moving upper boundary and being replaced by material coming from below: - + This plot uses the capability of VTK-based visualization programs (in this case of VisIt) to show vector data; this is the result of us @@ -186,31 +186,31 @@ look as follow:
- + - +
- + - +
- + - +
@@ -219,7 +219,7 @@ Again, they show essentially the location of singularities introduced by boundary conditions. The vector field computed makes for an interesting graph: - + The isocontours shown here as well are those of the pressure variable, showing the singularity at the point of discontinuous @@ -242,7 +242,7 @@ appropriately sorted into their corresponding blocks of the matrix and vector), then we get the following image after the first adaptive refinement in two dimensions: - + In order to generate such a graph, you have to insert a piece of code like the following to the end of the setup step. @@ -263,7 +263,7 @@ In this program, we have thus chosen a more advanced renumbering of components. The renumbering with DoFRenumbering::Cuthill_McKee and grouping the components into velocity and pressure yields the following output: - + It is apparent that the situation has improved a lot. Most of the elements are now concentrated around the diagonal in the (0,0) block in the matrix. Similar @@ -283,7 +283,7 @@ considerable amount of tentative fill-in elements. This illustrates why UMFPACK is not a good choice in 3D - a full decomposition needs many new entries that eventually won't fit into the physical memory (RAM): - + @@ -793,11 +793,11 @@ then we get images where the the fault line is curved:
- + - +
diff --git a/examples/step-23/doc/results.dox b/examples/step-23/doc/results.dox index f630d8b8cb..11dffad4c0 100644 --- a/examples/step-23/doc/results.dox +++ b/examples/step-23/doc/results.dox @@ -65,7 +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. +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-24/doc/results.dox b/examples/step-24/doc/results.dox index 67101997f1..a5db76bb9c 100644 --- a/examples/step-24/doc/results.dox +++ b/examples/step-24/doc/results.dox @@ -16,7 +16,7 @@ This movie shows the thermoacoustic waves generated by a single small absorber propagating in the medium (in our simulation, we assume the medium is mineral oil, which has a acoustic speed of 1.437 $\frac{mm}{\mu s}$): - + For a single absorber, we of course have to change the InitialValuesP class accordingly. @@ -30,7 +30,7 @@ microseconds running from left to right) using the source setup used in the program, to make things a bit more interesting compared to the present case of only a single source: - + One thing that can be seen, for example, is that the arrival of the second and fourth signals shifts to earlier times for greater detector numbers (i.e. the @@ -49,10 +49,10 @@ weaker absorbing tissue:
- + - +
@@ -70,13 +70,13 @@ through the detector will therefore be filtered. By using a high-pass filter the simulated results can be made to look closer to the experimental data: - + In our simulations, we see spurious signals behind the main wave that result from numerical artifacts. This problem can be alleviated by using finer mesh, resulting in the following plot: - + @@ -87,17 +87,17 @@ multiple absorbers. This corresponds to the case that is actually implemented in the program. The following movie shows the propagation of the generated thermoacoustic waves in the medium by multiple absorbers: - + Experimental data and our simulated data are compared in the following two figures:
- + - +
@@ -117,10 +117,10 @@ choosing a finer mesh (right):
- + - +
diff --git a/examples/step-25/doc/results.dox b/examples/step-25/doc/results.dox index f8e8bdffb2..51e0c5ee93 100644 --- a/examples/step-25/doc/results.dox +++ b/examples/step-25/doc/results.dox @@ -15,7 +15,7 @@ u_{\mathrm{breather}}(x,t) = -4\arctan \left(\frac{m}{\sqrt{1-m^2}} \frac{\sin\l \f] where $c_1$, $c_2$ and $m<1$ are constants. In the simulation below, we have chosen $c_1=0$, $c_2=0$, $m=0.5$. Moreover, it is know that the period of oscillation of the breather is $2\pi\sqrt{1-m^2}$, hence we have chosen $t_0=-5.4414$ and $t_f=2.7207$ so that we can observe three oscillations of the solution. Then, taking $u_0(x) = u_{\mathrm{breather}}(x,t_0)$, $\theta=0$ and $k=h/10$, the program computed the following solution. -Animation of the 1D stationary breather. +Animation of the 1D stationary breather. Though not shown how to do this in the program, another way to visualize the (1+1)-d solution is to use output generated by the DataOutStack class; it @@ -24,7 +24,7 @@ allows to "stack" the solutions of individual time steps, so that we get solutions. This produces the space-time plot below instead of the animation above. -A space-time plot of the 1D stationary breather. +A space-time plot of the 1D stationary breather. Furthermore, since the breather is an analytical solution of the sine-Gordon equation, we can use it to validate our code, although we have to assume that @@ -57,7 +57,7 @@ domain occur. The simulation shown below was performed with $u_0(x) = u_{\mathrm{kink}}(x,t_0)$, $\theta=\frac{1}{2}$, $k=20h$, $t_0=1$ and $t_f=500$. The $L^2$ norm of the error of the finite element solution at each time step remained on the order of $10^{-2}$, showing that the program is working correctly in 2D, as well as 1D. Unfortunately, the solution is not very interesting, nonetheless we have included a snapshot of it below for completeness. -Stationary 2D kink. +Stationary 2D kink. Now that we have validated the code in 1D and 2D, we move to a problem where the analytical solution is unknown. @@ -73,7 +73,7 @@ and not the equation, thus picking a value of $\theta$ a good bit into the "exponentially damped" spectrum of the time stepping schemes assures these oscillations are not created. -Animation of a moving 2D kink, at 45 degrees to the axes of the grid, showing boundary effects. +Animation of a moving 2D kink, at 45 degrees to the axes of the grid, showing boundary effects. Another interesting solution to the sine-Gordon equation (which cannot be obtained analytically) can be produced by using two 1D breathers to construct @@ -94,7 +94,7 @@ $k=10h$, $t_0=-5.4414$ and $t_f=2.7207$. The solution is pretty interesting --- it acts like a breather (as far as the pictures are concerned); however, it appears to break up and reassemble, rather than just oscillate. -Animation of a 2D pseudobreather. +Animation of a 2D pseudobreather. diff --git a/examples/step-26/doc/results.dox b/examples/step-26/doc/results.dox index 92c5396721..6c45c86fe7 100644 --- a/examples/step-26/doc/results.dox +++ b/examples/step-26/doc/results.dox @@ -41,7 +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. +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 bc82a7067b..6f6c745a22 100644 --- a/examples/step-27/doc/results.dox +++ b/examples/step-27/doc/results.dox @@ -54,20 +54,20 @@ boundary conditions. Of maybe more interest is to look at the graphical output. First, here is the solution of the problem: - + Secondly, let us look at the sequence of meshes generated: - - - + + + - - - + + +
@@ -77,15 +77,15 @@ distribution of finite element polynomial degrees to these mesh cells: - - - + + + - - - + + +
@@ -102,15 +102,15 @@ indicating least smoothness and red indicating the smoothest areas: - - - + + + - - - + + +
diff --git a/examples/step-28/doc/results.dox b/examples/step-28/doc/results.dox index 390bb1feb5..728763f23a 100644 --- a/examples/step-28/doc/results.dox +++ b/examples/step-28/doc/results.dox @@ -57,21 +57,21 @@ k-effective and the ratio between maximum of fast flux and maximum of thermal on The grids of fast and thermal energy groups at mesh iteration #9 are shown in following figure. - + - + We see that the grid of thermal group is much finer than the one of fast group. The solutions on these grids are, (Note: flux are normalized with total fission source equal to 1) - + - + Then we plot the convergence data with polynomial order being equal to 1,2 and 3. - + The estimated ``exact'' k-effective = 0.906834721253 which is simply from last mesh iteration of polynomial order 3 minus 2e-10. We see that h-adaptive calculations diff --git a/examples/step-29/doc/results.dox b/examples/step-29/doc/results.dox index 6a8ad54a69..04a039f10e 100644 --- a/examples/step-29/doc/results.dox +++ b/examples/step-29/doc/results.dox @@ -78,16 +78,16 @@ The graphical output of the program looks as follows:
- v = Re(u) + v = Re(u) - w = Im(u) + w = Im(u)
- |u| + |u|
@@ -107,10 +107,10 @@ the intensity is actually focused in $x$-direction:
- |u| + |u| - |u| + |u|
diff --git a/examples/step-3/doc/results.dox b/examples/step-3/doc/results.dox index a890cadee4..e2054cee20 100644 --- a/examples/step-3/doc/results.dox +++ b/examples/step-3/doc/results.dox @@ -55,11 +55,11 @@ to get the result at the right:
- + - +
diff --git a/examples/step-30/doc/results.dox b/examples/step-30/doc/results.dox index a98bb187c4..63d73aea48 100644 --- a/examples/step-30/doc/results.dox +++ b/examples/step-30/doc/results.dox @@ -108,20 +108,20 @@ algorithms (right).
- + - +
- + - +
@@ -132,7 +132,7 @@ indicator seems to effectively select the appropriate cells for anisotropic refinement. This observation is strengthened by the plot of the an adapted anisotropic grid, e.g. the grid after three refinement steps. - + In the whole left part of the domain refinement is only performed along the y-axis of cells. In the right part of the domain the refinement is dominated by diff --git a/examples/step-31/doc/results.dox b/examples/step-31/doc/results.dox index acccb42087..2dfeed24a5 100644 --- a/examples/step-31/doc/results.dox +++ b/examples/step-31/doc/results.dox @@ -89,31 +89,31 @@ the color scale used for the temperature is not always the same):
- + - + - + - +
- + - + - + - +
@@ -137,31 +137,31 @@ adaptive mesh and the flow field at the same time steps:
- + - + - + - +
- + - + - + - +
@@ -242,43 +242,43 @@ following plots: @@ -411,19 +411,19 @@ bilinear elements (temperature_degree=1) in 2d:
- + - + - + - +
- + - + - + - +
- + - + - +
- + - +
- + - +
@@ -488,16 +488,16 @@ retain the $Q_2/Q_1$ stable Taylor-Hood element for the Stokes system:
- + - +
- +
diff --git a/examples/step-32/doc/intro.dox b/examples/step-32/doc/intro.dox index 46a21c1b61..8c178c6509 100644 --- a/examples/step-32/doc/intro.dox +++ b/examples/step-32/doc/intro.dox @@ -515,7 +515,7 @@ program, and with a different viscosity that affects transport velocities and therefore time step sizes) in 2d will produce the following graph: - + As can be seen, values $\beta \le 0.05$ are too small whereas $\beta=0.052$ appears to work, at least to the time horizon shown @@ -545,7 +545,7 @@ viscosity $\nu$ and play with the constant $c_R$, making it as large as possible in order to make $\nu$ as small as possible. This gives us a picture like this: - + Consequently, $c_R=0.1$ would appear to be the right value here. While this graph has been obtained for an exponent $\alpha=1$, in the program we use @@ -924,7 +924,7 @@ the following quantities: href="http://www.wolframalpha.com/input/?i=plot+%28sqrt%28x^2%2By^2%29%2B0.2*%28sqrt%28x^2%2By^2%29*%281-sqrt%28x^2%2By^2%29%29*sin%286*atan2%28x%2Cy%29%29%29%2C+x%3D-1+to+1%2C+y%3D-1+to+1">this page): - + The point of this profile is that if we had used $s$ instead of $\tau$ in the definition of $T(\mathbf x)$ then it would simply be a linear diff --git a/examples/step-32/doc/results.dox b/examples/step-32/doc/results.dox index 722fbfbc33..20274729d7 100644 --- a/examples/step-32/doc/results.dox +++ b/examples/step-32/doc/results.dox @@ -22,12 +22,12 @@ magnitude more than we had available in step-31:
- +
- +
@@ -188,114 +188,114 @@ the current version):
- + - + - +
- + - + - +
- + - + - +
- + - + - +
- + - + - +
- + - + - +
- + - + - +
- + - + - +
@@ -324,7 +324,7 @@ continues to dominate flow. These different phases can also be identified if we look at the maximal velocity as a function of time in the simulation: - + Here, the velocity (shown in centimeters per year) becomes very large, to the order of several meters per year) at the beginning when the @@ -349,9 +349,9 @@ isocontours of the temperature and the partition of the domain (along with the mesh) onto 512 processors:

- + - +

diff --git a/examples/step-34/doc/results.dox b/examples/step-34/doc/results.dox index dec4c54823..7507e6bfff 100644 --- a/examples/step-34/doc/results.dox +++ b/examples/step-34/doc/results.dox @@ -197,16 +197,16 @@ element surface, and the potential extended to the outer and inner domain. The combination of the two for the two dimensional case looks like - + while in three dimensions we show first the potential on the surface, together with a contour plot, - + and then the external contour plot of the potential, with opacity set to 25%: - + diff --git a/examples/step-35/doc/intro.dox b/examples/step-35/doc/intro.dox index 6a05992541..f5fe3d6490 100644 --- a/examples/step-35/doc/intro.dox +++ b/examples/step-35/doc/intro.dox @@ -218,7 +218,7 @@ vector-valued functions (e.g. divergences) becomes a little awkward, and others. The testcase that we use for this program consists of the flow around a square obstacle. The geometry is as follows: - + with $H=4.1$, making the geometry slightly non-symmetric. diff --git a/examples/step-35/doc/results.dox b/examples/step-35/doc/results.dox index c7da3a39fc..88a21e0e36 100644 --- a/examples/step-35/doc/results.dox +++ b/examples/step-35/doc/results.dox @@ -63,24 +63,24 @@ vorticity and in the right the velocity field: - - + + - - + + - - + + - - + + - - + +
@@ -98,12 +98,12 @@ yields the following images at times $t=20,40$: - - + + - - + +
@@ -116,7 +116,7 @@ small scale dynamics. The riddle is easily solved, however, by looking at a zoom at the region behind the obstacle, and the mesh size we have there: - + It is clear here that the flow is still reasonably well resolved in the immediate wake of the obstacle, where the mesh is relatively fine, @@ -128,7 +128,7 @@ finer mesh. A rerun with one more mesh refinement set in the parameter file confirms that results look much more sensible now: - + Here, the zone where the mesh becomes coarser is immediately downstream of the big red blob at the bottom of the wake behind the diff --git a/examples/step-36/doc/results.dox b/examples/step-36/doc/results.dox index dfe659761a..5643013888 100644 --- a/examples/step-36/doc/results.dox +++ b/examples/step-36/doc/results.dox @@ -36,14 +36,14 @@ look like this: - - - + + + - - + +
@@ -102,20 +102,20 @@ probability densities $|\Psi(\mathbf x)|^2$ that are significant only where the potential is the lowest, i.e. in the top right and bottom left sector of inner circle of the potential): - + The first five eigenfunctions are now like this: - - - + + + - - + +
diff --git a/examples/step-37/doc/results.dox b/examples/step-37/doc/results.dox index 0244754b53..512e41a65c 100644 --- a/examples/step-37/doc/results.dox +++ b/examples/step-37/doc/results.dox @@ -7,7 +7,7 @@ a different coefficient), there is little to say about the solution. We show a picture anyway, illustrating the size of the solution through both isocontours and volume rendering: - + Of more interest is to evaluate some aspects of the multigrid solver. When we run this program in 2D for quadratic ($Q_2$) elements, we get the diff --git a/examples/step-38/doc/results.dox b/examples/step-38/doc/results.dox index 1ea337f571..d177a169e6 100644 --- a/examples/step-38/doc/results.dox +++ b/examples/step-38/doc/results.dox @@ -36,7 +36,7 @@ this, neatly following the theoretically predicted pattern: Finally, the program produces graphical output that we can visualize. Here is a plot of the results: - + The program also works for 1d curves in 2d, not just 2d surfaces in 3d. You can test this by changing the template argument in main() like @@ -50,7 +50,7 @@ then looks like so (the white curve is the domain, the colored curve is the solution extruded into the third dimension, clearly showing the change in sign as the curve moves from one quadrant of the domain into the adjacent one): - + @@ -67,9 +67,9 @@ before, we stretch it by a factor of 10 in the z-direction, and then we jumble the x- and y-coordinates a bit. Let's show the computational domain and the solution first before we go into details of the implementation below: - + - + The way to produce such a mesh is by using the GridTools::transform function. It needs a way to transform each individual mesh point to a diff --git a/examples/step-39/doc/results.dox b/examples/step-39/doc/results.dox index 1e7de4afd1..1928dbd24c 100644 --- a/examples/step-39/doc/results.dox +++ b/examples/step-39/doc/results.dox @@ -79,7 +79,7 @@ iteration steps is constant at approximately 17.

Postprocessing of the logfile

- + Using the perl script postprocess.pl, we extract relevant data into output.dat, which can be used to plot graphs with gnuplot. The graph above for instance was produced with diff --git a/examples/step-4/doc/results.dox b/examples/step-4/doc/results.dox index 3b9a95c900..58d78a0fac 100644 --- a/examples/step-4/doc/results.dox +++ b/examples/step-4/doc/results.dox @@ -38,7 +38,7 @@ you should play around with your favorite visualization tool to get familiar with its functionality. Here's what I have come up with for the 2d solution:

- +

(@dealiiVideoLectureSeeAlso{11,32}) @@ -71,11 +71,11 @@ 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 8e887c0917..5bf9a699e6 100644 --- a/examples/step-40/doc/results.dox +++ b/examples/step-40/doc/results.dox @@ -66,10 +66,10 @@ partitioning onto the 16 processors, and the corresponding solution:
- + - +
@@ -89,10 +89,10 @@ more interpretation can be found in the final version of the paper):
- + - +
@@ -113,10 +113,10 @@ this in the following two graphs for 256 and 4096 processors:
- + - +
diff --git a/examples/step-41/doc/intro.dox b/examples/step-41/doc/intro.dox index 62e8876b0b..066e6c7768 100644 --- a/examples/step-41/doc/intro.dox +++ b/examples/step-41/doc/intro.dox @@ -31,10 +31,10 @@ we should expect:
- + - +
diff --git a/examples/step-41/doc/results.dox b/examples/step-41/doc/results.dox index 7810a569ab..6f9afa3bb2 100644 --- a/examples/step-41/doc/results.dox +++ b/examples/step-41/doc/results.dox @@ -62,13 +62,13 @@ leftmost column): 0   - + - + - + @@ -77,13 +77,13 @@ leftmost column): 3   - + - + - + @@ -92,13 +92,13 @@ leftmost column): 6   - + - + - + @@ -107,13 +107,13 @@ leftmost column): 9   - + - + - + @@ -122,13 +122,13 @@ leftmost column): 12   - + - + - + @@ -137,13 +137,13 @@ leftmost column): 15   - + - + - + @@ -152,13 +152,13 @@ leftmost column): 18   - + - + - + @@ -183,13 +183,13 @@ blue for negative values. diff --git a/examples/step-42/doc/intro.dox b/examples/step-42/doc/intro.dox index 93573cbff0..3c19469ca0 100644 --- a/examples/step-42/doc/intro.dox +++ b/examples/step-42/doc/intro.dox @@ -29,7 +29,7 @@ solution will look like (the deformable body is a cube - only half of which is actually shown -, the obstacle corresponds to a Chinese character that is discussed below): - + This problem description implies that we have to take care of an additional @@ -405,7 +405,7 @@ Compared to step-41, the programs has a few new classes: looks as follows (see also the picture at the top of this section on how the end result looks like): - + Other than that, let us comment only on the following aspects: diff --git a/examples/step-42/doc/results.dox b/examples/step-42/doc/results.dox index 6f34deccbb..4f23ba6c84 100644 --- a/examples/step-42/doc/results.dox +++ b/examples/step-42/doc/results.dox @@ -155,16 +155,16 @@ inequality is active):
- + - + - +
- + - +   - +
diff --git a/examples/step-43/doc/results.dox b/examples/step-43/doc/results.dox index eec7e7732a..53842a7d9d 100644 --- a/examples/step-43/doc/results.dox +++ b/examples/step-43/doc/results.dox @@ -14,7 +14,7 @@ pictures, so here is some output of a run in 3d:
- +

Velocity vectors of flow through the porous medium with random permeability model. Streaming paths of high permeability and resulting @@ -22,7 +22,7 @@ pictures, so here is some output of a run in 3d:

- +

Streamlines colored by the saturation along the streamline path. Blue streamlines indicate low saturations, i.e., the flow along these @@ -36,14 +36,14 @@ pictures, so here is some output of a run in 3d:

- +

Streamlines with a volume rendering of the saturation, showing how far the fluid front has advanced at this time.

- +

Surface of the mesh showing the adaptive refinement along the front.

diff --git a/examples/step-44/doc/intro.dox b/examples/step-44/doc/intro.dox index d33136b696..1e7bbc4847 100644 --- a/examples/step-44/doc/intro.dox +++ b/examples/step-44/doc/intro.dox @@ -669,7 +669,7 @@ This benchmark problem is taken from 75 , 291-304. - + The material is quasi-incompressible neo-Hookean with shear modulus $\mu = 80.194e6$ and $\nu = 0.4999$. For such a choice of material properties a conventional single-field $Q_1$ approach would lock. diff --git a/examples/step-44/doc/results.dox b/examples/step-44/doc/results.dox index af87209594..93ff4e3475 100644 --- a/examples/step-44/doc/results.dox +++ b/examples/step-44/doc/results.dox @@ -16,13 +16,13 @@ as it should.
- +

Convergence of the $Q_1-DGPM_0-DGPM_0$ formulation in 3-d.

- +

Convergence of the $Q_2-DGPM_1-DGPM_1$ formulation in 3-d.

@@ -138,19 +138,19 @@ and is opposite to the physically realistic interpretation of pressure.
- +

Z-displacement solution for the 3-d problem.

- +

Discontinuous piece-wise constant pressure field.

- +

Discontinuous piece-wise constant dilatation field.

@@ -180,19 +180,19 @@ and could be smoothed on a continuous grid for the post-processing purposes.
- +

Z-displacement solution for the 3-d problem.

- +

Discontinuous linear pressure field.

- +

Discontinuous linear dilatation field.

@@ -225,7 +225,7 @@ some finite-strain problems involving alternative constitutive models.
- +

Runtime on a 4-core machine, normalised against the lowest grid resolution $Q_1-DGPM_0-DGPM_0$ solution that utilised a SSOR preconditioner.

@@ -244,13 +244,13 @@ displacement field, although qualitatively similar, is different to that of the
- +

Y-displacement solution in 2-d for 2 global grid refinement levels.

- +

Y-displacement solution in 2-d for 5 global grid refinement levels.

diff --git a/examples/step-45/doc/results.dox b/examples/step-45/doc/results.dox index 900ae319cf..9b24ee054e 100644 --- a/examples/step-45/doc/results.dox +++ b/examples/step-45/doc/results.dox @@ -3,8 +3,8 @@ The created output is not very surprising. We simply see that the solution is periodic with respect to the left and lower boundary: - + Without the periodicity constraints we would have ended up with the following solution: - + diff --git a/examples/step-46/doc/intro.dox b/examples/step-46/doc/intro.dox index 45d36183a7..720d1aa788 100644 --- a/examples/step-46/doc/intro.dox +++ b/examples/step-46/doc/intro.dox @@ -540,7 +540,7 @@ introduction. We will consider the following situation as a testcase: - + As discussed at the top of this document, we need to assume in a few places that a cell is either entirely in the fluid or solid part of the domain and, diff --git a/examples/step-46/doc/results.dox b/examples/step-46/doc/results.dox index 560002d05f..5dd81a8992 100644 --- a/examples/step-46/doc/results.dox +++ b/examples/step-46/doc/results.dox @@ -54,7 +54,7 @@ The results are easily visualized:
- +

Magnitude of the fluid velocity. @@ -62,7 +62,7 @@ The results are easily visualized:

- +

Fluid pressure. The dynamic range has been truncated to cut off the @@ -74,7 +74,7 @@ The results are easily visualized:

- +

Fluid velocity. @@ -82,7 +82,7 @@ The results are easily visualized:

- +

Solid displacement. @@ -140,7 +140,7 @@ The results can also be visualized and yield some good pictures:
- +

Vectors of the fluid velocity and magnitude of the @@ -149,7 +149,7 @@ The results can also be visualized and yield some good pictures:

- +

Streamlines of the velocity, with the mesh superimposed. @@ -158,7 +158,7 @@ The results can also be visualized and yield some good pictures:

- +

Solid displacement. diff --git a/examples/step-49/doc/intro.dox b/examples/step-49/doc/intro.dox index 83f3239b76..c570b4c1d8 100644 --- a/examples/step-49/doc/intro.dox +++ b/examples/step-49/doc/intro.dox @@ -96,7 +96,7 @@ with two objects cut out in the interior. This is how untitled.geo looks like in gmsh (displaying the boundary indicators as well as the mesh discussed further down below): - + You might want to open the untitled.geo file in a text editor (it is located in the same directory as the step-49.cc source file) to @@ -125,7 +125,7 @@ loading the file. Now this is the mesh read from the .msh file and saved again by deal.II as an image (see the grid_1 function of the current program): - +

Modifying a Mesh

@@ -151,10 +151,10 @@ coordinate of a mesh with a sine curve:
- regular input mesh + regular input mesh - output mesh + output mesh
@@ -166,10 +166,10 @@ of this tutorial:
- regular input mesh + regular input mesh - wall-adapted output mesh + wall-adapted output mesh
@@ -181,10 +181,10 @@ demonstrated in grid_7() and the result is as follows:
- regular input mesh + regular input mesh - perturbed output mesh + perturbed output mesh
@@ -216,9 +216,9 @@ These are the input meshes and the output mesh: - - - + + +
input mesh 1input mesh 2merged meshinput mesh 1input mesh 2merged mesh
@@ -234,11 +234,11 @@ centered by moving the top vertices upwards:
- input mesh + input mesh - top vertices moved upwards + top vertices moved upwards
@@ -260,11 +260,11 @@ mesh, generated for example with gmsh, that is read in from a
- input mesh + input mesh - extruded output mesh + extruded output mesh
diff --git a/examples/step-49/doc/results.dox b/examples/step-49/doc/results.dox index ed20909c73..a392ccc3aa 100644 --- a/examples/step-49/doc/results.dox +++ b/examples/step-49/doc/results.dox @@ -16,14 +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: @@ -46,7 +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 @@ -227,7 +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 @@ -283,7 +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 @@ -305,7 +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 @@ -317,7 +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 @@ -372,11 +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-5/doc/results.dox b/examples/step-5/doc/results.dox index dec392e77b..fc777ef58d 100644 --- a/examples/step-5/doc/results.dox +++ b/examples/step-5/doc/results.dox @@ -66,28 +66,28 @@ format. They are depicted in the following:
- + - +
- + - +
- + - +
diff --git a/examples/step-51/doc/results.dox b/examples/step-51/doc/results.dox index 06ef541ea1..d24090bfb8 100644 --- a/examples/step-51/doc/results.dox +++ b/examples/step-51/doc/results.dox @@ -33,12 +33,12 @@ Dirichlet conditions on the right and top boundaries. - - + + - - + +
@@ -51,12 +51,12 @@ analytical solution. - - + + - - + +
@@ -68,8 +68,8 @@ solutions. - - + +
@@ -200,8 +200,8 @@ block structure in the matrix on the finest level. - - + +
@@ -217,8 +217,8 @@ for $p=1$. - - + +
@@ -231,8 +231,8 @@ linears. However, the advantage of HDG for higher orders remains. - - + +
@@ -264,16 +264,16 @@ of DoFs) is very similar to the results for FE_FaceQ. - - + + - - + + - - + +
diff --git a/examples/step-53/doc/intro.dox b/examples/step-53/doc/intro.dox index f86e5b6d2d..cfe64dd35f 100644 --- a/examples/step-53/doc/intro.dox +++ b/examples/step-53/doc/intro.dox @@ -119,7 +119,7 @@ href="http://en.wikipedia.org/wiki/East_African_rift">East African Rift, a zone where two continental plates drift apart. Not to beat around the bush, the geometry we want to describe looks like this: - + In particular, though you cannot see this here, the top surface is not just colored by the elevation but is, in fact, deformed to follow the diff --git a/examples/step-53/doc/results.dox b/examples/step-53/doc/results.dox index beaaf746e8..d953814176 100644 --- a/examples/step-53/doc/results.dox +++ b/examples/step-53/doc/results.dox @@ -14,14 +14,14 @@ along the top surface and something for the visualization programs to apply their shading algorithms to (because the top surfaces of the cells are now no longer just tangential to a sphere but tilted): - + Yet, at least as far as visualizations are concerned, this is still not too impressive. Rather, let us visualize things in a way so that we show the actual elevation along the top surface. In other words, we want a picture like this, with an incredible amount of detail: - + A zoom-in of this picture shows the vertical displacement quite clearly (here, looking from the West-Northwest over the rift valley, the triple peaks @@ -36,7 +36,7 @@ George and toward the great flatness of Lake Victoria): - + These image were produced with three small modifications: @@ -130,7 +130,7 @@ neighboring cell. This can be shown more clearly by using a different surface description in which we enlarge the vertical topography to enhance the effect (courtesy of Alexander Grayver): - + So what is happening here? Partly, this is only a result of visualization, but there is an underlying real cause as well: diff --git a/examples/step-54/doc/intro.dox b/examples/step-54/doc/intro.dox index bcd257cf47..e4d234b032 100644 --- a/examples/step-54/doc/intro.dox +++ b/examples/step-54/doc/intro.dox @@ -96,7 +96,7 @@ refines a mesh edge finding the new vertex as the point splitting in two even parts the curvilinear length of the CAD curve portion that lies between the vertices of the original edge. - + A different projection strategy has been implemented in the @@ -111,8 +111,8 @@ shape---typically lying on the shape boundary---is selected. If the shape is composed of several sub-shapes, the projection is carried out onto every single sub-shape, and the closest projection point point is selected. - - + + As we are about to experience, for some shapes, setting the projection direction as that normal to the CAD surface will not lead to surface mesh @@ -129,7 +129,7 @@ the direction used at construction time. In this way, the user will have a higher control on the projection direction to be enforced to ensure good mesh quality. - + Of course the latter approach is effective only when the orientation of the @@ -170,7 +170,7 @@ arbitrarily shaped surfaces are considered, and unless you have a geometry for which a more specific approach is known to be appropriate. - +

The testcase

@@ -183,7 +183,7 @@ flow of water around the ship (in a way similar to step-34) but we will not try to do this here. To already give you an idea of the geometry we consider, here is a picture: - + In the program, we read both the geometry and a coarse mesh from files, and then employ several of the options discussed above to place new vertices for a diff --git a/examples/step-54/doc/results.dox b/examples/step-54/doc/results.dox index ebf94fb9cb..fee51db117 100644 --- a/examples/step-54/doc/results.dox +++ b/examples/step-54/doc/results.dox @@ -16,19 +16,19 @@ same grids shown in the second row. - - - + + + - - - + + + - - - + + +
@@ -45,19 +45,19 @@ is indicated with a small yellow arrow at the bottom left of each image). - - - + + + - - - + + + - - - + + +
@@ -69,19 +69,19 @@ The final test shows results using instead the projection normal to the faces: - - - + + + - - - + + + - - - + + +
diff --git a/examples/step-6/doc/results.dox b/examples/step-6/doc/results.dox index eae0cb6cec..6051cdada9 100644 --- a/examples/step-6/doc/results.dox +++ b/examples/step-6/doc/results.dox @@ -48,7 +48,7 @@ The final solution, as written by the program at the end of the - + @@ -60,37 +60,37 @@ format. These are shown in the following:
- + - +
- + - +
- + - +
- + - +
@@ -214,11 +214,11 @@ following results (left: iterations; right: CPU time):
- + - +
@@ -238,11 +238,11 @@ bi-linear one. If one makes this change, the results are as follows:
- + - +
@@ -343,7 +343,7 @@ center of the mesh only fails for the central square of the mesh): After a few global refinement steps, this would lead to a mesh of the following kind: - + This is not a good mesh: the central cell has been refined in such a way that the children located in the four corners of the original central cell @@ -446,37 +446,37 @@ This code then generates the following, much better sequence of meshes:
- + - +
- + - +
- + - +
- + - +
diff --git a/examples/step-7/doc/results.dox b/examples/step-7/doc/results.dox index e5fbede05b..6671886260 100644 --- a/examples/step-7/doc/results.dox +++ b/examples/step-7/doc/results.dox @@ -8,7 +8,7 @@ files solution-adaptive-q1.vtk, here: - + diff --git a/examples/step-8/doc/results.dox b/examples/step-8/doc/results.dox index 1a021ca735..d9e0ab361c 100644 --- a/examples/step-8/doc/results.dox +++ b/examples/step-8/doc/results.dox @@ -9,10 +9,10 @@ the $x$- and $y$-displacements as a scalar components:
- + - +
@@ -22,7 +22,7 @@ You can clearly see the sources of $x$-displacement around $x=0.5$ and $x=-0.5$, and of $y$-displacement at the origin. The next image shows the final grid after eight steps of refinement: - + What one frequently would like to do is to show the displacement as a vector @@ -46,7 +46,7 @@ step-22. The vector field then looks like this (Visit randomly selects a few hundred vertices from which to draw the vectors; drawing them from each individual vertex would make the picture unreadable): - + We note that one may have intuitively expected the diff --git a/examples/step-9/doc/results.dox b/examples/step-9/doc/results.dox index d0e541a513..8b7f9c4719 100644 --- a/examples/step-9/doc/results.dox +++ b/examples/step-9/doc/results.dox @@ -29,7 +29,7 @@ resolve the features of the solution. The final grid showing this is displayed in the following picture: - + @@ -37,7 +37,7 @@ The structure of the grid will be understandable by looking at the solution itself: - + -- 2.39.5