From b3c90a872a0139dd6db7bcd0ce152f9bb6f0ecf6 Mon Sep 17 00:00:00 2001
From: wolf
Date: Thu, 2 Feb 2006 07:08:58 +0000
Subject: [PATCH] Small improvements
git-svn-id: https://svn.dealii.org/trunk@12222 0785d39b-7218-0410-832d-ea1e28bc413d
---
.../step-3.data/results.html | 75 +++++++++++++++++++
.../step-5.data/intro.html | 6 +-
.../tutorial/chapter-2.step-by-step/toc.html | 2 +-
3 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/results.html
index 836212f226..f5f17b202d 100644
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/results.html
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-3.data/results.html
@@ -71,3 +71,78 @@ to get the result at the right:
+
+
+Possibilities for extensions
+
+
+If you want to play around a little bit with this program, here are a few
+suggestions:
+
+
+
+ -
+ Change the geometry and mesh: In the program, we have generated a square
+ domain and mesh by using the
GridGenerator::hyper_cube
+ function. However, the GridGenerator
has a good number of other
+ functions as well. Try an L-shaped domain, a ring, or other domains you find
+ there.
+
+
+ -
+ Change the boundary condition: The code uses the
ZeroFunction
+ function to generate zero boundary conditions. However, you may want to try
+ non-zero constant boundary values using ConstantFunction<2>
+ (1)
instead of ZeroFunction<2> ()
to have unit
+ Dirichlet boundary values. More exotic functions are described in the
+ documentation of the Functions
namespace, and you may pick one
+ to describe your particular boundary values.
+
+
+ -
+ Modify the type of boundary condition: Presently, what happens is that we use
+ Dirichlet boundary values all around, since the default is that all boundary
+ parts have boundary indicator zero, and then we tell the
+
VectorTools::interpolate_boundary_values
function to interpolate
+ boundary values to zero on all boundary components with indicator zero.
+
+ We can change this behavior if we assign parts of the boundary different
+ indicators. For example, try this immediately after calling
+ GridGenerator::hyper_cube
:
+
+ triangulation.begin_active()->face(0)->set_boundary_indicator(1);
+
+ What this does is it first asks the triangulation to return an iterator that
+ points to the first active cell. Of course, this being the coarse mesh for
+ the triangulation of a square, the triangulation has only a single cell at
+ this moment, and it is active. Next, we ask the cell to return an iterator to
+ its first face, and then we ask the face to reset the boundary indicator of
+ that face to 1. What then follows is this: When the mesh is refined, faces of
+ child cells inherit the boundary indicator of their parents, i.e. even on the
+ finest mesh, the faces on one side of the square have boundary indicator
+ 1. Later, when we get to interpolating boundary conditions, the
+ interpolate_boundary_values
will only produce boundary values
+ for those faces that have zero boundary indicator, and leave those faces
+ alone that have a different boundary indicator. Keeping with the theory of
+ the Laplace equation, this will then lead to homogenous Neumann conditions on
+ this side, i.e. a zero normal derivative of the solution. You will see this
+ if you run the program.
+
+
-
+ A slight variation of the last point would be to set different boundary
+ 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 to
interpolate_boundary_values
for boundary indicator one:
+
+ VectorTools::interpolate_boundary_values (dof_handler,
+ 1,
+ ConstantFunction<2>(1.),
+ boundary_values);
+
+ 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
+ computed for boundary indicator 0. The result will be that we will get
+ discontinuous boundary values, zero on three sides of the square, and one on
+ the fourth.
+
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html
index 812de2a8ec..2de8f398a9 100644
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html
@@ -9,9 +9,9 @@ them are:
- Computations on successively refined grids. At least in the
mathematical sciences, it is common to compute solutions on
- a hierarchy of grids, in order to get a fealing of the accuracy
- of the solution; if you only have one solution on one grid, you
- usually can't give a guess with respect to the accuracy of the
+ a hierarchy of grids, in order to get a feeling for the accuracy
+ of the solution; if you only have one solution on a single grid, you
+ usually can't guess the accuracy of the
solution. Furthermore, deal.II is designed to support adaptive
algorithms where iterative solution on successively refined
grids is at the heart of algorithms. Although adaptive grids
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 0c90cff17a..5a11cf0bee 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
@@ -81,7 +81,7 @@ At present, the following programs exist:
- What's new: Computations on successively
refined grids. Reading a grid from disk. Some optimizations.
Using assertions. Non-constant coefficient in
- the elliptic operator. Preconditioning of the CG solver for the
+ the elliptic operator. Preconditioning the CG solver for the
linear system of equations.
--
2.39.5