The $(call get_basename,$@) tutorial program" >> $@
@echo "@htmlonly" >> $@
@cat generated/$(call get_basename, $@)_toc.combined >> $@
- @cat $(call get_basename, $@).data/intro.html | \
- $(PERL) -pi -e 's#(src|SRC|href|HREF)=\"([-a-zA-Z0-9]+.data)#\1=\"../../tutorial/chapter-2.step-by-step/\2#g; s/(href|HREF)=.step-(\d+)/href=\"step_\2/g;' >> $@
@echo "@endhtmlonly" >> $@
+ @if test -f $(call get_basename, $@).data/intro.dox ; then \
+ cat $(call get_basename, $@).data/intro.dox ; \
+ else \
+ echo "@htmlonly" ; \
+ cat $(call get_basename, $@).data/intro.html ; \
+ echo "@endhtmlonly" ; \
+ fi | \
+ $(PERL) -pi -e 's#(src|SRC|href|HREF)=\"([-a-zA-Z0-9]+.data)#\1=\"../../tutorial/chapter-2.step-by-step/\2#g; s/(href|HREF)=.step-(\d+)/href=\"step_\2/g;' >> $@
@cat generated/$(call get_basename, $@)_prog.dox >> $@
- @echo "@htmlonly" >> $@
- @cat $(call get_basename, $@).data/results.html | \
+ @if test -f $(call get_basename, $@).data/results.dox ; then \
+ cat $(call get_basename, $@).data/results.dox ; \
+ else \
+ echo "@htmlonly" ; \
+ cat $(call get_basename, $@).data/results.html ; \
+ echo "@endhtmlonly" ; \
+ fi | \
$(PERL) -pi -e 's#(src|SRC|href|HREF)=\"([-a-zA-Z0-9]+.data)#\1=\"../../tutorial/chapter-2.step-by-step/\2#g; s/(href|HREF)=.step-(\d+)/href=\"step_\2/g;' >> $@
- @echo "@endhtmlonly" >> $@
@cat generated/$(call get_basename, $@)_plain.dox >> $@
@echo " */" >> $@
<a name="Intro"></a>
<h1>Introduction</h1>
-<p>
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
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.
-</p>
<a name="Results"></a>
<h1>Results</h1>
-<p>
The program has, after having been run, produced two grids, which look
like this:
The left one, well, is not very exciting. The right one is — at least
— unconventional.
-</p>
+
<a name="Intro"></a>
<h1>Introduction</h1>
-<p>
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
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.
-</p>
-<p>
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.
-</p>
<a name="Results"></a>
<h1>Results</h1>
-<p>
The program has, after having been run, produced two sparsity
patterns. We can visualize them using GNUPLOT:
-<pre><code>
+@code
examples/step-2> gnuplot
G N U P L O T
Terminal type set to 'x11'
gnuplot> set data style points
gnuplot> plot "sparsity_pattern.1"
-</code></pre>
-</p>
+@endcode
-<p>
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
</td>
</tr>
</table>
-</p>
-<p>
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.
-</p>
-<p>
A common observation is that the more refined the grid is, the better
the clustering around the diagonal will get.
-</p>
+
<a name="Intro"></a>
<h1>Introduction</h1>
-<p>
+
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
<li> Solving the linear system of equations;
<li> Writing results to disk.
</ul>
-</p>
<a name="Results"></a>
<h1>Results</h1>
-<p>
The output of the program looks as follows:
-<pre><code>
+@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
-</code></pre>
+@endcode
The first three lines is what we wrote to <code>cout</code>. The last
two lines were generated without our intervention by the CG
show in the next program how to suppress this output, which is
sometimes useful for debugging purposes, but often clutters up the
screen display.
-</p>
-<p>
Apart from the output shown above, the program generated the file
<code>solution.gpl</code>, which is in GNUPLOT format. It can be
viewed as follows: invoke GNUPLOT and enter the following sequence of
commands at its prompt:
-<pre><code>
+@code
examples/step-3> gnuplot
G N U P L O T
Terminal type set to 'x11'
gnuplot> set data style lines
gnuplot> splot "solution.gpl"
-</code></pre>
+@endcode
This produces the picture of the solution below left. Alternatively,
you can order GNUPLOT to do some hidden line removal by the command
-<pre><code>
+@code
gnuplot> set hidden3d
-</code></pre>
+@endcode
to get the result at the right:
-</p>
-<p>
<TABLE WIDTH="100%">
<tr>
<td>
</td>
</tr>
</table>
-</p>
+
<a name="extensions"></a>
<h3>Possibilities for extensions</h3>
-<p>
If you want to play around a little bit with this program, here are a few
suggestions:
</p>
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 <code>interpolate_boundary_values</code> for boundary indicator one:
- <code><pre>
+ @code
VectorTools::interpolate_boundary_values (dof_handler,
1,
ConstantFunction<2>(1.),
boundary_values);
- </pre></code>
+ @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