From: Guido Kanschat Date: Tue, 4 Dec 2012 17:56:36 +0000 (+0000) Subject: more big output files removed X-Git-Tag: v8.0.0~1733 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e17d67c19becf368cddffbd7dae61892e95be192;p=dealii.git more big output files removed git-svn-id: https://svn.dealii.org/trunk@27756 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/examples/step-21/doc/results.dox b/deal.II/examples/step-21/doc/results.dox index ad0d87e96b..b8c7d7892c 100644 --- a/deal.II/examples/step-21/doc/results.dox +++ b/deal.II/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: -@image html step-21.centerline.gif + 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: -@image html step-21.random2d.gif + 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: -@image html step-21.random3d.gif + To repeat these computations, all you have to do is to change the line @code diff --git a/deal.II/examples/step-22/doc/results.dox b/deal.II/examples/step-22/doc/results.dox index 437c499c83..3524d69293 100644 --- a/deal.II/examples/step-22/doc/results.dox +++ b/deal.II/examples/step-22/doc/results.dox @@ -80,31 +80,31 @@ corners, so there is need for refinement there as well:
- @image html step-22.2d.mesh-0.png + - @image html step-22.2d.mesh-1.png +
- @image html step-22.2d.mesh-2.png + - @image html step-22.2d.mesh-3.png +
- @image html step-22.2d.mesh-4.png + - @image html step-22.2d.mesh-5.png +
@@ -113,7 +113,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: -@image html step-22.2d.solution.png + 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 @@ -191,31 +191,31 @@ look as follow:
- @image html step-22.3d.mesh-0.png + - @image html step-22.3d.mesh-1.png +
- @image html step-22.3d.mesh-2.png + - @image html step-22.3d.mesh-3.png +
- @image html step-22.3d.mesh-4.png + - @image html step-22.3d.mesh-5.png +
@@ -224,7 +224,7 @@ Again, they show essentially the location of singularities introduced by boundary conditions. The vector field computed makes for an interesting graph: -@image html step-22.3d.solution.png + The isocountours shown here as well are those of the pressure variable, showing the singularity at the point of discontinuous @@ -247,7 +247,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: -@image html step-22.2d.sparsity-nor.png + 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. @@ -268,7 +268,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: -@image html step-22.2d.sparsity-ren.png + 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 @@ -288,7 +288,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): -@image html step-22.3d.sparsity_uu-ren.png + @@ -798,11 +798,11 @@ then we get images where the the fault line is curved:
- @image html step-22.3d-extension.png + - @image html step-22.3d-grid-extension.png +
diff --git a/deal.II/examples/step-23/doc/results.dox b/deal.II/examples/step-23/doc/results.dox index 0fda35af8c..d24f2ea369 100644 --- a/deal.II/examples/step-23/doc/results.dox +++ b/deal.II/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: -@image html step-23.movie.gif "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