Write text.

git-svn-id: https://svn.dealii.org/trunk@8984 0785d39b-7218-0410-832d-ea1e28bc413d

diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-17.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-17.data/results.html
index e67fccc1c1403f0a550ec7d6f60ab4918aaf24b5..220fdd537bb90120f6279c2d7821a991184698e8 100644 (file)
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-17.data/results.html
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-17.data/results.html
@@ -1,2 +1,138 @@
 <a name="Results"></a>
 <h1>Results</h1>
+
+<p>
+If the program above is compiled and run on a single processor machine, it
+should generate results that are very similar to those that we already got
+with step-8. However, it becomes more interesting if we run it on a cluster of
+computers. Most clusters have some kind of scheduling system, all of which
+have different calling syntaxes - on my system, I have to use the command
+<code>bsub</code> with a whole host of options to run a job in parallel - so
+that the exact command line syntax varies. If you have found out how to run a
+job on your system, you should get output like this for a job on 8 processors,
+and with a few more refinement cycles than in the code above:
+<code><pre>
+Cycle 0:
+   Number of active cells:       64
+   Number of degrees of freedom: 162 (by partition: 22+22+20+20+18+16+20+24)
+   Solver converged in 23 iterations.
+Cycle 1:
+   Number of active cells:       124
+   Number of degrees of freedom: 302 (by partition: 38+42+36+34+44+44+36+28)
+   Solver converged in 35 iterations.
+Cycle 2:
+   Number of active cells:       238
+   Number of degrees of freedom: 570 (by partition: 68+80+66+74+58+68+78+78)
+   Solver converged in 46 iterations.
+Cycle 3:
+   Number of active cells:       454
+   Number of degrees of freedom: 1046 (by partition: 120+134+124+130+154+138+122+124)
+   Solver converged in 55 iterations.
+Cycle 4:
+   Number of active cells:       868
+   Number of degrees of freedom: 1926 (by partition: 232+276+214+248+230+224+234+268)
+   Solver converged in 77 iterations.
+Cycle 5:
+   Number of active cells:       1654
+   Number of degrees of freedom: 3550 (by partition: 418+466+432+470+442+474+424+424)
+   Solver converged in 93 iterations.
+Cycle 6:
+   Number of active cells:       3136
+   Number of degrees of freedom: 6702 (by partition: 838+796+828+892+866+798+878+806)
+   Solver converged in 127 iterations.
+Cycle 7:
+   Number of active cells:       5962
+   Number of degrees of freedom: 12446 (by partition: 1586+1484+1652+1552+1556+1576+1560+1480)
+   Solver converged in 158 iterations.
+Cycle 8:
+   Number of active cells:       11320
+   Number of degrees of freedom: 23586 (by partition: 2988+2924+2890+2868+2864+3042+2932+3078)
+   Solver converged in 225 iterations.
+Cycle 9:
+   Number of active cells:       21424
+   Number of degrees of freedom: 43986 (by partition: 5470+5376+5642+5450+5630+5470+5416+5532)
+   Solver converged in 282 iterations.
+Cycle 10:
+   Number of active cells:       40696
+   Number of degrees of freedom: 83754 (by partition: 10660+10606+10364+10258+10354+10322+10586+10604)
+   Solver converged in 392 iterations.
+Cycle 11:
+   Number of active cells:       76978
+   Number of degrees of freedom: 156490 (by partition: 19516+20148+19390+19390+19336+19450+19730+19530)
+   Solver converged in 509 iterations.
+Cycle 12:
+   Number of active cells:       146206
+   Number of degrees of freedom: 297994 (by partition: 37462+37780+37000+37060+37232+37328+36860+37272)
+   Solver converged in 705 iterations.
+Cycle 13:
+   Number of active cells:       276184
+   Number of degrees of freedom: 558766 (by partition: 69206+69404+69882+71266+70348+69616+69796+69248)
+   Solver converged in 945 iterations.
+Cycle 14:
+   Number of active cells:       523000
+   Number of degrees of freedom: 1060258 (by partition: 132928+132296+131626+132172+132170+133588+132252+133226)
+   Solver converged in 1282 iterations.
+Cycle 15:
+   Number of active cells:       987394
+   Number of degrees of freedom: 1994226 (by partition: 253276+249068+247430+248402+248496+251380+248272+247902)
+   Solver converged in 1760 iterations.
+</pre></code>
+</p>
+
+<p>
+As can be seen, we can easily get to almost two million unknowns. In fact, the
+code's runtime with 8 processes was less than 7 minutes up to (and including)
+cycle 14, and 14 minutes including the last step. This, if the debug flag in
+the Makefile was changed to "off", i.e. "optimized". Here is some output
+generated in the 12th cycle of the program, i.e. with roughly 300,000
+unknowns:
+</p>
+
+<p align="center">
+  <a href="step-17.data/solution-12-ux.png" target="_top"><img
+  src="step-17.data/solution-12-ux.png" alt="ux" width="45%"></a>
+  <a href="step-17.data/solution-12-uy.png" target="_top"><img
+  src="step-17.data/solution-12-uy.png" alt="uy" width="45%"></a>
+</p>
+
+<p>
+As one would hope for, the x- (left) and y-displacements (right) shown here
+closely match what we already saw in step-8. What may be more interesting,
+though, is to look at the mesh and partition at this step (to see the picture
+in its original size, simply click on it):
+</p>
+
+
+<p align="center">
+  <a href="step-17.data/solution-12-grid.png" target="_top"><img
+  src="step-17.data/solution-12-grid.png" alt="grid" width="45%"></a>
+  <a href="step-17.data/solution-12-partition.png" target="_top"><img
+  src="step-17.data/solution-12-partition.png" alt="partition"
+  width="45%"></a>
+</p>
+
+<p>
+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
+subdomains are smaller where mesh cells are small, a fact that needs to be
+expected given that the partitioning algorithm tries to equilibrate the number
+of cells in each subdomain; this equilibration is also easily identified in
+the output shown above, where the number of degrees per subdomain is roughly
+the same.
+</p>
+
+<p>
+It is worth noting that if we ran the same program with a different number of
+processes, that we would likely get slightly different output: a different
+mesh, different number of unknowns and iterations to convergence. The reason
+for this is that while the matrix and right hand side are the same independent
+of the number of processes used, the preconditioner is not: it performs an
+ILU(0) on the chunk of the matrix of <em>each processor separately</em>. Thus,
+it's effectiveness as a preconditioner diminishes as the number of processes
+increases, which makes the number of iterations increase. Since a different
+preconditioner leads to slight changes in the computed solution, this will
+then lead to slightly different mesh cells tagged for refinement, and larger
+differences in subsequent steps. The solution will always look very similar,
+though.
+</p>