From: wolf !\n
Table of contents
Step-by-Step overview
@@ -54,11 +54,24 @@
Step 5
+ Step 6
+
+ Back to the deal.II homepage
+ \n";
+
while (<>) {
# ignore cvs tag
next if m!/\*\s*\$Id:!;
# substitute special characters
+ s/&/&/g;
s/</g;
s/>/>/g;
s/\t/ /g;
@@ -25,12 +29,16 @@ while (<>) {
{
$state = $comment_mode;
print "\n";
+ print "\n";
+ print " \n";
}
# if in comment mode and no comment line: toggle state.
# don't do so, if only a blank line
elsif (($state == $comment_mode) && !m!^\s*//! && !m!^\s*$!)
{
$state = $program_mode;
+ print " " if $1 =~ m!^\s*$!;
+ print " " if $1 =~ m!^\s*$!;
}
else
{
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/program2plain b/deal.II/doc/tutorial/chapter-2.step-by-step/program2plain
index 4fe9180d9e..720819ba49 100644
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/program2plain
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/program2plain
@@ -4,12 +4,17 @@ while ( m!/\*\s*\$Id$!) {
$_ = <>;
}
-print "\n";
-print " \n";
+
+(The program can be found at PROGRAMPATH.)
+
+(.*)
!
!!gi; ' $@
+
+step-by-step.sgml: $(example-sgmls)
+ @echo ================== Concating $@
+ @cat step-by-step.header.sgml \
+ | perl -pi -e 's/TODAY/$(shell date)/;' \
+ > $@
+ @for step in $(example-names) ; do \
+ echo "!
+
+
+
+
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/program2html b/deal.II/doc/tutorial/chapter-2.step-by-step/program2html
index 8ac79e5549..c578e7474d 100644
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/program2html
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/program2html
@@ -12,11 +12,15 @@ while ( m!/\*\s*\$Id$!) {
$comment_mode = 0;
$program_mode = 1;
$state = $comment_mode;
+
+print "\n";
}
@@ -38,7 +46,7 @@ while (<>) {
{
m!\s*//\s*(.*)!;
print $1, "\n";
- print "
The plain program
\n";
+print < The plain program
-print "(The program can be found at PROGRAMPATH.)\n
\n\n";
+
";
+print "
+END
while (<>) {
@@ -20,6 +25,7 @@ while (<>) {
next if m!^\s*//!;
# substitute special characters
+ s/&/&/g;
s/</g;
s/>/>/g;
s/\t/ /g;
@@ -27,4 +33,4 @@ while (<>) {
print " $_";
}
-print "
In this first example, we do not so very much, but show two techniques: what is the syntax to generate triangulation objects, and some elements of simple loops over all cells. We create two grids, one @@ -10,3 +11,4 @@ ring-shaped domain, which is refined towards the inner edge. The latter is certainly not very useful and is certainly only rarely used in numerical analysis, but looks nice and illustrates how loops over cells are written and some of the things you can do with cells. +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.results index 56f0a1d19e..79c285ca51 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.results +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.results @@ -1,9 +1,10 @@The program has, after having been run, produced two grids, which look like this: -
+
@@ -14,6 +15,7 @@ like this: |
+ The left one, well, is not very exciting. The right one is - at least - unconventional. +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.intro index 1e4e2c71c1..3795cc5f49 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.intro +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.intro @@ -1,6 +1,7 @@After we have created a grid in the previous example, we now show how we can associate a degree of freedom with each vertex of the triangulation. This is a rather simple task, since the library does @@ -9,3 +10,4 @@ solvers, it is advantageous to have the degrees of freedom numbered in a certain sense, and we will use the algorithm of Cuthill and McKee to do so. The results are written to a file and visualized using GNUPLOT. +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.results index 8a1ea53bd1..9eb478fee1 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.results +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-2.results @@ -1,14 +1,14 @@The program has, after having been run, produced two sparsity patterns. We can visualize them using GNUPLOT: -
-
+
set data style points
plot "sparsity_pattern.1"
-
-
+
+
The results then look like this (every cross denotes an entry which @@ -17,7 +17,6 @@ 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, if the equation is a local, i.e. differential one): -
@@ -28,16 +27,19 @@ one): |
+
+The different regions in the left picture represent the degrees of freedom on the different refinement levels of the triangulation. As can be seen in the right picture, the sparsity pattern is much better clustered around the main diagonal of the matrix after renumbering. Although this might not be apparent, the number of nonzero entries is the same in both pictures, of course. +
- A common observation is that the more refined the grid is, the better the clustering around the diagonal will get. +
+ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.intro index fbca9526a3..8e8e458000 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.intro +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.intro @@ -1,6 +1,7 @@This is the first example where we actually use finite elements. We will solve a simple version of Laplace's equation witht zero boundary values, but a nonzero right hand side. This example is still quite @@ -12,3 +13,4 @@ element programs, which are along the following lines:
The output of the program looks as follows: -
-
+
Number of active cells: 1024
Total number of cells: 1365
Number of degrees of freedom: 1089
DEAL:cg::Starting value 0.121094
DEAL:cg::Starting value 0.323075
DEAL:cg::Convergence step 47 value 5.33692e-13
-
-
+
The first three lines is what we wrote to cout
. The last
three lines were generated without our interaction by the CG
@@ -22,27 +21,25 @@ the threshold 1e-12 which we have set in the `solve' function. We will
show in the next program how to suppress this output, which is
sometimes useful for debugging purposes, but often clutters up the
screen display.
+
-
Apart from the output shown above, the program generated the file
solution.gpl
, which is in GNUPLOT format. It can be
viewed as follows: invoke GNUPLOT and enter the following sequence of
commands at its prompt:
-
-
+
gnuplot> set data style lines
gnuplot> splot "solution.gpl"
-
-
+
This produces the picture of the solution below left. Alternatively,
you can order GNUPLOT to do some hidden line removal by the command
-
-
+
gnuplot> set hidden3d
-
-
+
to get the result at the right:
+
+
+
+ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.intro index 35c826cb31..2b68184950 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.intro +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.intro @@ -1,6 +1,7 @@
deal.II has a unique feature which we call
``dimension independent programming''. You may have noticed in the
previous examples that many classes had a number in angle brackets
@@ -22,9 +23,10 @@ working on Triangulation2d
and once working with a
programming and leads to a nuisance to keep the two function in synch
(at best) or difficult to find errors if the two versions get out of
synch (at worst; this would probably the more common case).
+
+
Such obstacles can be circumvented by using some template magic as provided by the C++ language: templatized classes and functions are not really classes or functions but only a pattern depending on an @@ -42,15 +44,17 @@ parameter. For example, consider the following piece of code: GridGenerator::hyper_cube (triangulation, -1, 1); }; +
+At the point where the compiler sees this function, it does not know anything about the value of ``dim'', by now there is a whole zoo of functions make_grid, one for every possible valueof ``dim''. But since the compiler can't know which might be used, it can not compile the function. +
- However, if later down a function would use the following sequence,
Triangulation<2> triangulation;
@@ -66,19 +70,18 @@ as
GridGenerator::hyper_cube (triangulation, -1, 1);
};
+
-
However, it is worth to note that the function
GridGenerator::hyper_cube
depends on the dimension as
well, so in this case, the compiler will call the function
GridGenerator::hyper_cube<2>
while if dim were 3,
it would call GridGenerator::hyper_cube<3>
which
might be (and actually is) a totally unrelated function.
-
+
- The same can be made with member variables. Consider the following function, which might in turn call the above one:
@@ -91,7 +94,6 @@ function, which might in turn call the above one:
...
};
-
This function has a member variable of type
DoFHandler<dim>
the size of which may (and does)
depend on the dimension we are working in. Again, the compiler can't
@@ -103,9 +105,9 @@ which it was called, and compile it. If you call the function several
times for different dimensions, it will compile it several times, each
time calling the right ``make_grid'' function and reserving the right
amount of memory for the member variable.
+
- The deal.II library is build around this concept and that allows you to program in way that will not need to distinguish between the space dimensions. It should be noted that in @@ -115,13 +117,14 @@ has to compile each function for each dimension separately, even there it knows the value of ``dim'' at the time of compilation and will therefore be able to optimize the ``if'' statement along with the unused branch. +
- In this example program, we will show how to program dimension independently (which in fact is even simpler than if you had to take care about the dimension) and we will extend the Laplace problem of the last example to a program that runs in two and three space dimensions at the same time. Other extensions are the use of a non-constant right hand side function and of non-zero boundary values. +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.results index 7514fac593..321c4f94a4 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.results +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.results @@ -1,12 +1,12 @@The output of the program looks as follows (the number of iterations may vary by one or two, depending on your computer, since this is often dependent on the round-off accuracy of floating point operations, which differs between micro-processors): -
-
+
Solving problem in 2 space dimensions.
Number of active cells: 256
Total number of cells: 341
@@ -17,8 +17,7 @@ Solving problem in 3 space dimensions.
Total number of cells: 4681
Number of degrees of freedom: 4913
29 CG iterations needed to obtain convergence.
-
-
+
It is obvious that in three spatial dimensions the number of cells and
therefore also the number of degrees of freedom is
much higher. What cannot be seen here, is that besides this higher
@@ -27,15 +26,16 @@ more entries per row of the matrix in three space
dimensions. Together, this leads to a much higher numerical effort for
solving the system of equation, which you can feel when you actually
run the program.
+
-
The program produces two files: solution-2d.gmv
and
solution-3d.gmv
, which can be viewed using the program
GMV (in case you do not have that program, you can easily change the
output format in the program to something which you can view more
easily). From the two-dimensional output, we have produced the
following two pictures:
+
+
+The left one shows the solution of the problem under consideration as a 3D plot. As can be seen, the solution is almost flat in the interior of the domain and has a higher curvature near the boundary. This, of @@ -59,23 +60,23 @@ a quartic polynomial which is nearly zero in the interior and is only rising sharply when approaching the boundaries of the domain; the maximal values of the right hand side function are at the corners of the domain, where also the solution is moving most rapidly. - It is also nice to see that the solution follows the desired quadratic boundary values along the boundaries of the domain. +
- The right picture shows the two dimensional grid, colorized by the values of the solution function. This is not very exciting, but the colors are nice. - -
+
+In three spatial dimensions, visualization is a bit more difficult. To the left, you can see the solution at three of the six outer faces of the cube in which we solved the equation, and on a plane through the origin. On some of the planes, the cut through the grid is also shown. +
+
+The right picture shows the three dimensional grid, colorized by the solutions values. 3D grids are difficult to visualize, which can be seen here already, even though the grid is not locally refined. - +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.intro index 362d757e28..70568cad31 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.intro +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.intro @@ -1,6 +1,7 @@This example does not show revolutionary new things, but it shows many small improvements over the previous examples, and also many small things that can usually be found in finite element programs. Among @@ -35,3 +36,4 @@ them are: preconditioned iterative solvers for the linear systems of equations. +
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.results index 4df7e28e3c..5277a927f6 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.results +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.results @@ -1,10 +1,9 @@The output of the program looks as follows: -
-
+
Cycle 0:
Number of active cells: 20
Total number of cells: 20
@@ -36,8 +35,8 @@ Cycle 5:
Number of degrees of freedom: 20609
200 CG iterations needed to obtain convergence.
--------------------------------------------------------
-An error occurred in line <206> of file in function
- void Coefficient<2>::value_list<2>(const class vector,__default_alloc_template > &, class vector > &, unsigned int = 0) const
+An error occurred in line <206> of file <step-5.cc> in function
+ void Coefficient<2>::value_list<2>(const class vector<Point<2>,__default_alloc_template<false,0> > &, class vector<double,__default_alloc_template<false,0> > &, unsigned int = 0) const
The violated condition was:
values.size() == n_points
The name and call sequence of the exception was:
@@ -45,17 +44,19 @@ The name and call sequence of the exception was:
Additional Information:
The vector has size 1 but should have 2 elements.
--------------------------------------------------------
-
-
+
+
+In each cycle, the number of cells quadruples and the number of CG iterations roughly doubles. The exception is only raised if the respective lines at the end of the programs are un-commented. +
- In each cycle, the program writes one output graphic file in EPS format. They are depicted in the following: +
+
+Due to the variable coefficient (the curvature there is reduced by the same factor by which the coefficient is increased), the top region of the solution is flattened. The gradient of the solution is discontinuous there, although this is not very clearly visible in the pictures above. We will look at this in more detail in the next example. +
+ + diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/final-solution.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/final-solution.jpg new file mode 100644 index 0000000000..376e4a6197 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/final-solution.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-0.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-0.jpg new file mode 100644 index 0000000000..87697d6cb1 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-0.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-1.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-1.jpg new file mode 100644 index 0000000000..77728cff7f Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-1.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-2.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-2.jpg new file mode 100644 index 0000000000..3ce4182510 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-2.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-3.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-3.jpg new file mode 100644 index 0000000000..c6312a15c9 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-3.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-4.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-4.jpg new file mode 100644 index 0000000000..f8a7670c5a Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-4.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-5.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-5.jpg new file mode 100644 index 0000000000..ed495d1ad1 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-5.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-6.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-6.jpg new file mode 100644 index 0000000000..71c34b5379 Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-6.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-7.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-7.jpg new file mode 100644 index 0000000000..4d9a0d027b Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/grid-7.jpg differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro new file mode 100644 index 0000000000..a3108dcb4c --- /dev/null +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro @@ -0,0 +1,5 @@ + ++
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results new file mode 100644 index 0000000000..26b30c11eb --- /dev/null +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results @@ -0,0 +1,95 @@ + ++The output of the program looks as follows: +
+Cycle 0:
+ Number of active cells: 20
+Cycle 1:
+ Number of active cells: 44
+Cycle 2:
+ Number of active cells: 86
+Cycle 3:
+ Number of active cells: 164
+Cycle 4:
+ Number of active cells: 344
+Cycle 5:
+ Number of active cells: 656
+Cycle 6:
+ Number of active cells: 1364
+Cycle 7:
+ Number of active cells: 2684
+
+
+
++As intended, the number of cells roughly doubles in each cycle. The +final solution, as written by the program, looks as follows: +
+ +
+
+
+In each cycle, the program furthermore writes the grid in EPS +format. These are depicted in the following: +
+ ++
+![]() |
+
+![]() |
+
+![]() |
+
+![]() |
+
+![]() |
+
+![]() |
+
+It is clearly visible that the region where the solution has a kink, +i.e. the circle at radial distance 0.5 from the center, is +refined most. Furthermore, the central region where the solution is +very smooth and almost flat, is almost not refined at all, but this +results from the fact that we did not take into account that the +coefficient is large there. The region outside is refined rather +randomly, since the second derivative is constant there and refinement +is therefore mostly based on the size of the cells and their deviation +from the optimal square. +
+ + + diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html b/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html index 2017634d8b..35973eff1c 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html @@ -20,20 +20,30 @@-In this chapter, we present a collecting of small programs, each more +In this chapter, we present a collection of small programs, each more or less built atop of the previous one, which demonstrate various aspects of the library. The general layout of each such example is as follows:
+The programs themselves can be found at a path which is indicated at +the beginning of the last section of each example. You can compile +them by typing ``make'' in the respective directory, and run them +using ``make run''. The latter command also compiles the program if +that has not already been done. +
+ +At present, the following programs exist:
@@ -73,6 +83,11 @@ At present, the following programs exist: the elliptic operator. Preconditioning of the CG solver for the linear system of equations. + +