From f3e8f35216dee88e7f08ae81da8c0c8db841f7e2 Mon Sep 17 00:00:00 2001
From: wolf
In this first example, we don't actually do 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,9 +9,8 @@ starting grid for some problems), and one more geometric attempt: a
ring-shaped domain, which is refined towards the inner edge. The
latter is certainly not very useful and is probably only rarely used
in numerical analysis for PDEs (although, to everyone's surprise, it
-has actually found its way into the literature, see the paper by M. My
+has actually found its way into the literature, see the paper by M. Mu
titled "PDE.MART: A network-based problem-solving environment", ACM
Trans. Math. Software, vol. 31, pp. 508-531, 2005 :-), but looks nice
and illustrates how loops over cells are written and some of the
things you can do with cells.
-
The program has, after having been run, produced two grids, which look
like this:
@@ -18,4 +17,4 @@ like this:
The left one, well, is not very exciting. The right one is — at least
— unconventional.
-
After we have created a grid in the previous example, we now show how
to define degrees of freedom on this mesh. For this example, we
will use the lowest order (Q1) finite elements, for which the degrees
@@ -9,13 +8,10 @@ of freedom are associated with the vertices of the mesh. Later
examples will demonstrate higher order elements where degrees of freedom are
not necessarily associated with vertices any more, but can be associated
with edges, faces, or cells.
-
Defining degrees of freedom ("DoF"s in short) on a mesh is a rather
simple task, since the library does all the work for you. However, for
some algorithms, especially for some linear solvers, it is
advantageous to have the degrees of freedom numbered in a certain
order, and we will use the algorithm of Cuthill and McKee to do
so. The results are written to a file and visualized using GNUPLOT.
-
The program has, after having been run, produced two sparsity
patterns. We can visualize them using GNUPLOT:
-Introduction
-Results
-Introduction
-Results
-
-
+@code
examples/step-2> gnuplot
G N U P L O T
@@ -26,10 +25,8 @@ examples/step-2> gnuplot
Terminal type set to 'x11'
gnuplot> set data style points
gnuplot> plot "sparsity_pattern.1"
-
The results then look like this (every cross denotes an entry which might be nonzero; of course the fact whether the entry actually is zero or not depends on the equation under consideration, but the @@ -52,19 +49,15 @@ WIDTH="300"> -
-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.data/intro.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/intro.dox similarity index 98% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/intro.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/intro.dox index 0588c6fd37..222a263a56 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/intro.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/intro.dox @@ -1,7 +1,7 @@+ This is the first example where we actually use finite elements to compute something. We will solve a simple version of Laplace's equation with zero boundary @@ -14,4 +14,3 @@ element programs, which are along the following lines:
The output of the program looks as follows: -
+@code
Number of active cells: 1024
Total number of cells: 1365
Number of degrees of freedom: 1089
DEAL:cg::Starting value 0.121094
DEAL:cg::Convergence step 48 value 5.33692e-13
-
+@endcode
The first three lines is what we wrote to cout
. The last
two lines were generated without our intervention by the CG
@@ -20,14 +19,12 @@ 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:
-
+@code
examples/step-3> gnuplot
G N U P L O T
@@ -49,16 +46,14 @@ examples/step-3> gnuplot
Terminal type set to 'x11'
gnuplot> set data style lines
gnuplot> splot "solution.gpl"
-
+@endcode
This produces the picture of the solution below left. Alternatively,
you can order GNUPLOT to do some hidden line removal by the command
-
+@code
gnuplot> set hidden3d
-
+@endcode
to get the result at the right:
-
-
@@ -69,13 +64,12 @@ to get the result at the right: |
If you want to play around a little bit with this program, here are a few suggestions:
@@ -133,12 +127,12 @@ suggestions: values as above, but then use a different boundary value function for boundary indicator one. In practice, what you have to do is to add a second call tointerpolate_boundary_values
for boundary indicator one:
-
+ @code
VectorTools::interpolate_boundary_values (dof_handler,
1,
ConstantFunction<2>(1.),
boundary_values);
-
+ @endcode
If you have this call immediately after the first one to this function, then
it will interpolate boundary values on faces with boundary indicator 1 to the
unit value, and merge these interpolated values with those previously
--
2.39.5