--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Footnotes</TITLE>
+<META NAME="description" CONTENT="Footnotes">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="previous" HREF="node6.html">
+<LINK REL="up" HREF="main.html">
+</HEAD>
+<BODY >
+
+<DL>
+<DT><A NAME="foot400">...tex2html_comment_mark</A><A NAME="foot400"
+ HREF="node3.html#tex2html3"><SUP>1</SUP></A>
+<DD>We get a similar problem if we have different finite elements on two
+ adjacent elements. Since the treatment of this problem is along the same
+ lines as for <I>h</I>-refinement, we do not make explicit reference to
+ <I>p</I>-refinement in the following.
+<PRE>.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+</PRE>
+<DT><A NAME="foot479">...tex2html_comment_mark</A><A NAME="foot479"
+ HREF="node3.html#tex2html4"><SUP>2</SUP></A>
+<DD>For nonconforming finite element spaces, the continuity
+ requirement has to be substituted by a generalized compatibility
+ condition, cf. [<A
+ HREF="node6.html#KS99c">11</A>].
+<PRE>.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+</PRE>
+</DL><ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>No Title</TITLE>
+<META NAME="description" CONTENT="No Title">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node1.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html9"
+ HREF="node1.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif_gr.gif">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif_gr.gif">
+<BR>
+<B> Next:</B> <A NAME="tex2html10"
+ HREF="node1.html">Design and evolution of</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+
+<P>
+<DIV ALIGN="CENTER">
+<FONT SIZE="+3"><B>Concepts for Object-Oriented</B></FONT>
+
+<P>
+<FONT SIZE="+3"><B>Finite Element Software - the</B></FONT>
+
+<P>
+<FONT SIZE="+3"><B><TT>deal.II</TT> Library</B></FONT>
+
+
+<P>
+<BR>
+<BR>
+
+<P>
+<FONT SIZE="+1">Wolfgang Bangerth and Guido Kanschat</FONT>
+
+<P>
+<BR>
+<BR>
+<BR>
+
+<P>
+Institute of Applied Mathematics
+<BR>
+University of Heidelberg
+<BR>
+Germany
+
+<P>
+Email:
+ <TT>wolfgang.bangerth@iwr.uni-heidelberg.de, kanschat@iwr.uni-heidelberg.de</TT>
+</DIV>
+<P>
+
+<H3>Abstract:</H3>
+<DIV>
+An overview of the <TT>deal.II</TT> library is given. This library provides
+ the functionality needed by modern numerical software used in the finite
+ element solution of partial differential equations, offering adaptively
+ refined meshes, different finite element classes, multigrid solvers and
+ support for one, two and three spatial dimensions.
+
+ We give a description of the basic design criteria used in the
+ development of the library and how they were transformed into actual
+ code, and some examples of the use of the library in numerical
+ analysis.
+</DIV>
+<P>
+<P>
+<BR><HR>
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"> </A>
+<UL>
+<LI><A NAME="tex2html11"
+ HREF="node1.html">Design and evolution of <TT>deal.II</TT></A>
+<UL>
+<LI><A NAME="tex2html12"
+ HREF="node1.html#SECTION00011000000000000000">Design criteria</A>
+<LI><A NAME="tex2html13"
+ HREF="node1.html#SECTION00012000000000000000">Programming model</A>
+<UL>
+<LI><A NAME="tex2html14"
+ HREF="node1.html#SECTION00012010000000000000">Iterators and accessors.</A>
+<LI><A NAME="tex2html15"
+ HREF="node1.html#SECTION00012020000000000000">Logical addressing of objects.</A>
+<LI><A NAME="tex2html16"
+ HREF="node1.html#SECTION00012030000000000000">Dimension independent programming.</A>
+</UL>
+<LI><A NAME="tex2html17"
+ HREF="node1.html#SECTION00013000000000000000">History</A>
+</UL>
+<LI><A NAME="tex2html18"
+ HREF="node2.html">Grid handling</A>
+<UL>
+<LI><A NAME="tex2html19"
+ HREF="node2.html#SECTION00021000000000000000">Hierarchical cell representation</A>
+<LI><A NAME="tex2html20"
+ HREF="node2.html#SECTION00022000000000000000">Hierarchical grid refinement</A>
+</UL>
+<LI><A NAME="tex2html21"
+ HREF="node3.html">Finite element spaces</A>
+<UL>
+<LI><A NAME="tex2html22"
+ HREF="node3.html#SECTION00031000000000000000">Finite element objects</A>
+<LI><A NAME="tex2html23"
+ HREF="node3.html#SECTION00032000000000000000">Computation of shape function values</A>
+<LI><A NAME="tex2html24"
+ HREF="node3.html#SECTION00033000000000000000">Hanging nodes</A>
+</UL>
+<LI><A NAME="tex2html25"
+ HREF="node4.html">Iterative solvers</A>
+<UL>
+<LI><A NAME="tex2html26"
+ HREF="node4.html#SECTION00041000000000000000">Iterative linear solvers of <I>LAC</I></A>
+<UL>
+<LI><A NAME="tex2html27"
+ HREF="node4.html#SECTION00041100000000000000">Requirements on template parameters</A>
+<LI><A NAME="tex2html28"
+ HREF="node4.html#SECTION00041200000000000000">Administrative classes</A>
+</UL>
+</UL>
+<LI><A NAME="tex2html29"
+ HREF="node5.html">Example applications</A>
+<UL>
+<LI><A NAME="tex2html30"
+ HREF="node5.html#SECTION00051000000000000000">Conservation Laws</A>
+<LI><A NAME="tex2html31"
+ HREF="node5.html#SECTION00052000000000000000">Parameter estimation</A>
+<LI><A NAME="tex2html32"
+ HREF="node5.html#SECTION00053000000000000000">Wave equation</A>
+<LI><A NAME="tex2html33"
+ HREF="node5.html#SECTION00054000000000000000">Boundary approximation</A>
+</UL>
+<LI><A NAME="tex2html34"
+ HREF="node6.html">Bibliography</A>
+</UL>
+<!--End of Table of Child-Links-->
+<BR><HR>
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Design and evolution of deal.II</TITLE>
+<META NAME="description" CONTENT="Design and evolution of deal.II">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node2.html">
+<LINK REL="previous" HREF="main.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node2.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html44"
+ HREF="node2.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html42"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html36"
+ HREF="main.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html45"
+ HREF="node2.html">Grid handling</A>
+<B> Up:</B> <A NAME="tex2html43"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html37"
+ HREF="main.html">No Title</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
+<UL>
+<LI><A NAME="tex2html46"
+ HREF="node1.html#SECTION00011000000000000000">Design criteria</A>
+<LI><A NAME="tex2html47"
+ HREF="node1.html#SECTION00012000000000000000">Programming model</A>
+<UL>
+<LI><A NAME="tex2html48"
+ HREF="node1.html#SECTION00012010000000000000">Iterators and accessors.</A>
+<LI><A NAME="tex2html49"
+ HREF="node1.html#SECTION00012020000000000000">Logical addressing of objects.</A>
+<LI><A NAME="tex2html50"
+ HREF="node1.html#SECTION00012030000000000000">Dimension independent programming.</A>
+</UL>
+<LI><A NAME="tex2html51"
+ HREF="node1.html#SECTION00013000000000000000">History</A>
+</UL>
+<!--End of Table of Child-Links-->
+<HR>
+
+<H1><A NAME="SECTION00010000000000000000"> </A>
+<A NAME="sec:general"> </A>
+<BR>
+Design and evolution of <TT>deal.II</TT>
+</H1>
+
+The <I>DEAL</I> project, short for <I>D</I>ifferential
+<I>E</I>quations <I>A</I>nalysis <I>L</I>ibrary, was started to
+provide means for the implementation of adaptive finite element
+methods. In fact, the development of <I>DEAL</I> and adaptive
+methods at the Institute of Applied Mathematics in Heidelberg are
+closely linked. From this starting point, a finite element library was
+needed, that is able to handle grids with strongly varying mesh width
+and supports strategies for the computation of error estimates based
+on dual problems.
+
+<P>
+While <I>DEAL</I> was a library developed since 1993, this article gives an
+overview of the design criteria, programming models and fields of application
+of its successor library, <TT>deal.II</TT>.
+
+<P>
+
+<H2><A NAME="SECTION00011000000000000000">
+Design criteria</A>
+</H2>
+
+<P>
+<TT>deal.II</TT> was written with the following aims in mind:
+<UL>
+<LI><I>Flexibility:</I> Our aim was to produce a library which
+ enables us to try and test our ideas in a way as quick as possible.
+ The library should thus be easily extendible with respect to the
+ most common approaches in numerical analysis, i.e., different variational formulations, different space dimensions, different finite
+ element spaces, different linear solvers.
+<LI><I>High level interfaces:</I> The library should be as simple
+ to use as possible. Quite complex data structures are necessary for
+ using different finite elements on locally refined grids. The
+ interface is designed to hide and shield these structures from the
+ user. This way, programmers applying the library do not have to know
+ about the grid handling details and - more important - cannot interfere
+ with essential data needed by the library functions.
+<LI><I>Efficiency:</I> The computations involved in finite element
+ calculations are often highly time-consuming. Furthermore, the
+ memory requirements are enormous and they will fill up any machine we have.
+ Therefore, efficiency has to be considered as well.
+</UL>Obviously, some of these criteria are contradictory and must be traded against
+each other. In almost all cases, we traded efficiency in favor of
+safety and flexibility. However, some decisions were also made with
+the performance aspect in mind.
+These do not so much affect the
+complicated grid handling, which is not overly time-critical, but are
+especially found in the use of finite element objects and in the linear algebra
+sub-library.
+
+<P>
+Another important decision for simplicity against flexibility was the
+reduction to hypercube (line, quadrilateral, hexahedron) cells and
+their transformations to the physical space only.
+The previous <I>DEAL</I> library featured the possibility of
+combining simplicial (triangle, tetrahedron) and hypercube elements and in the
+end this
+additional flexibility caused very complicated data structures and violations
+of type safety. Since
+in all our experiments hypercube cells proved superior to simplicial ones,
+the decision was made against the latter. An immediate result of this
+decision is the absence of closure cells. Treatment of hanging nodes
+is much better done in the numerical than in the geometrical context
+(cf. Section <A HREF="node3.html#sub:hnodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>).
+
+<P>
+Two other important criteria in the design of the library, unfortunately not
+widely followed in the academic world, were:
+<UL>
+<LI><I>Safety:</I> Run-time checks of function parameters and the internal
+ consistency of the library have proven an invaluable means of finding
+ programming errors as early as possible. Even for experienced users of a
+ library, at least 90% of errors are violations of constraints on
+ parameters and variables, and similar problems. A library that does not
+ accept such parameters during development makes programming much faster
+ and significantly less tedious; in a non-debug mode, the error checking
+ assertions are taken out of the code before compilation, so no performance
+ penalty is imposed for production computations.
+
+<P>
+<LI><I>Documentation:</I> Within the academic sector, too many projects
+ still fail in the long term due to insufficient documentation; at the latest
+ when the initial developers leave the institute, i.e. usually after about
+ five years, a program is destined to die if not properly documented.
+</UL>
+<P>
+The design goals described above need a programming language with a
+high level of abstraction. We chose <TT>C++</TT> for implementing the
+library. The main reasons for this were:
+<UL>
+<LI><I>Availability:</I> <TT>C++</TT> is widely available and with
+ <TT>gcc</TT> there is a compiler that runs on almost any platform,
+ including personal computers for home use, workstations and
+ supercomputers. Besides this, <TT>C++</TT> is a popular language in
+ nearly all fields of computing, so acquiring skilled programmers
+ is less difficult than with other programming languages.
+
+<P>
+<LI><I>Standardization:</I> <TT>C++</TT> is a standardized language, so
+ the programmer is able to rely on language features and can write portable
+ programs that are guaranteed to run in the future as well. Furthermore, the
+ standard includes a large library of generic data containers and algorithms
+ which allow to program significantly faster than using most other
+ languages.
+
+<P>
+<LI><I>Data encapsulation:</I> The complex data structures
+ required by locally refined meshes need to be encapsulated and be made
+ visible in a more structured and readily available form than using the raw
+ data. This is done using wrapper classes that distribute the access to the
+ different parts of the data structures providing a uniform interface to the
+ user. These classes have the advantage to shield the user from the actual
+ data structures as well as from changes therein, allowing optimizations to
+ be implemented without the need to change application programs.
+<LI><I>Flexible and strong data typing:</I> <TT>C++</TT> provides, through
+ the concept of templates, the use of generic data types for algorithms and
+ data structures. Still, neither speed nor strong data typing is
+ sacrificed for this. This is an important advantage over many other
+ languages where either no genericity is available, leading to duplication of
+ code (including more possibilities for data type errors and additional
+ effort for coding) or where the type system is relaxed in order to allow
+ genericity, leading to errors which are harder to track down, and
+ slower programs. Genericity is an
+ important part of complex numerical software since the choice of data types
+ often involves a trade-off between accuracy and computing time or memory;
+ this choice has often to be made for each case again, so a library should
+ not settle on one data type (say, double precision) beforehand.
+<LI><I>Speed:</I> As opposed to teaching focused languages like
+ <TT>Pascal</TT> and languages for network and interactive
+ applications like <TT>Java</TT>, <TT>C++</TT> was developed with the
+ aim of allowing highly structured software that still is fast.
+ Therefore, it offers features like templates and inline functions,
+ that enable a good compiler to mostly eliminate structural overhead.
+<LI><I>In-code documentation:</I> In practice, for a rather small
+ group of developers it is impossible to keep a good technical documentation up
+ to date unless this can happen within the source code itself. With
+ the advent of a standard for the documentation of <TT>Java</TT>
+ programs, there have also appeared several programs to extract
+ documentation directly from <TT>C++</TT> source code. Using these
+ programs, documentation is written directly at the point where
+ modifications occur, making it much easier to keep program and
+ documentation in a matching state.
+
+ At present, if printed the <TT>deal.II</TT> documentation comprises about
+ 800 pages of function and class references, along with several dozens of
+ pages of technical documentation. All information is available on the World
+ Wide Web as well and is updated every night (cf. [<A
+ HREF="node6.html#DEAL">2</A>]).
+</UL>
+<P>
+These ingredients of the programming language have enabled us to use a
+programming model that resembles the style of the <TT>C++</TT> standard
+library and makes use of templates to support several space dimensions at
+once. These points will be explained in detail below.
+
+<P>
+
+<H2><A NAME="SECTION00012000000000000000">
+Programming model</A>
+</H2>
+
+<P>
+
+<H4><A NAME="SECTION00012010000000000000">
+Iterators and accessors.</A>
+</H4>
+The standard template library (STL) introduced the notion of iterators to
+<TT>C++</TT> from 1993 on. This model, abstracting pointers and, in general,
+elements of containers has since then gained wide support in the <TT>C++</TT>
+world. For a library making heavy use of the standard container classes, it is
+therefore natural to offer its data structures in a similar way. In the
+present context, a triangulation can be considered a container holding points,
+lines, quadrilaterals, etc. accessible like the elements of a
+list.
+
+<P>
+In fact, this mode of addressing elements of a triangulation is a major
+abstraction, since the data elements making up one of the objects mentioned
+above are distributed over a number of different arrays and other
+containers.
+By providing classes called iterators, programs can be written as
+if data collections were arrays of data; in particular, these classes offer
+operators <TT>++</TT> and <TT>-</TT> that move the pointer-like variable to
+the next or previous element, respectively, just like a pointer would behave,
+and as do the iterator classes of the standard library.
+
+<P>
+While pointers in the original sense pointed to actual data which is organized
+in a linear fashion in memory, iterators need not do so. For example iterators
+may point to the elements of a linked list, which need not have any special
+order in physical memory apart from the pointers that link the
+different elements.
+
+<P>
+In the <TT>deal.II</TT> library, iterators actually point to no data at all.
+Dereferenced, they return an object called <I>accessor</I> having
+no data elements itself apart from some numbers identifying the line or
+quadrilateral it is to represent; it is a collection of functions knowing
+how to obtain and manipulate data related to that object.
+A typical function, setting a bit for a
+quadrilateral in the triangulation that might be used by application programs
+would then look like the following extract:
+<PRE>
+ void QuadAccessor::set_user_flag () const
+ {
+ tria->levels[level]->quads.user_flags[index] = true;
+ }
+</PRE><TT>level</TT> and <TT>index</TT> denote the address of
+the quadrilateral represented by this accessor object within the
+hierarchical triangulation. It is obvious that shielding this multiple
+dereferencing from the user makes the library much more robust with
+regard to changes in the internal data structures. Furthermore, it
+allows us to write programs in a much simpler way than by using the
+internals directly. They will be much better readable, too.
+
+<P>
+Using this concept of offering data centralized in an accessor class while
+still storing it decentralized in many complex data structures, it is possible
+to use the advantages of more
+flexible data structures while still having the simplicity of programming
+applications on top of these; in addition, the user needs not know anything
+about the actual representation of the data, which may thus be changed at any
+time as long as the accessor classes are changed accordingly. The actual
+knowledge of the data structures is restricted to very small parts of the
+library (a few hundred statements), the rest of the library and all user
+programs use iterators and accessors to address these data.
+
+<P>
+
+<H4><A NAME="SECTION00012020000000000000">
+Logical addressing of objects.</A>
+</H4>
+The most often used operation in finite element programs is looping over all
+quadrilaterals within a triangulation of a two dimensional domain and
+performing some operations on each of them; an example would be to
+compute the contributions of each quadrilateral to the global system matrix.
+From this point of view, a
+triangulation is composed of vertices, lines, quadrilaterals, etc.
+
+<P>
+Alternatively, it can be regarded as a collection of cells, faces, etc.;
+we call this the
+<I>dual topology</I>. This view, which depends on the dimension (a cell
+is a line in one space dimension, a quadrilateral in 2d and a hexahedron in
+3d) is more natural to the programming of numerical software since
+assembling of matrices, computation of error estimators, and so on are done on cells
+and their faces.
+
+<P>
+A typical loop, in this case marking all cells for some future operation,
+therefore looks like this:
+<PRE>
+ Triangulation<dim> triangulation;
+ ... // triangulate a domain
+ Triangulation<dim>::cell_iterator cell;
+ for (cell=triangulation.begin();
+ cell != triangulation.end();
+ ++cell)
+ {
+ cell->set_user_flag ();
+ };
+</PRE>Remember that if <TT>cell</TT> is dereferenced, we obtain an accessor which
+has the member function shown above to perform the wanted operation.
+
+<P>
+The <TT>deal.II</TT> library offers both ways of addressing elements of
+triangulations. While the first one centered on the dimension of an object is
+most often used in the interior of the library, the second way, focused on the
+dimension of an object relative to what a cell constitutes, is most helpful for
+numerical algorithms and in fact allows to write programs and algorithms
+in a dimension independent way. Operations work cell by cell, choosing
+finite element shape functions, quadrature rules and the like according to the dimension of the cell. All the application programs presently implemented with
+<TT>deal.II</TT> exclusively use the dual topology instead of the primal one.
+
+<P>
+
+<H4><A NAME="SECTION00012030000000000000">
+Dimension independent programming.</A>
+</H4>
+In this approach to programming, the program is actually formed when
+the compiler associates a concrete data type, such as a
+<I>quadrilateral</I>, to an abstract data type like a <I>cell</I>. This is
+done using template manipulations as provided by <TT>C++</TT>. It
+allows to write a function or algorithm in a way that does not depend on the
+dimension by using <I>logical</I> data types like cells or faces, which are
+parameterized aliases (i.e. <TT>typedef</TT>s) to concrete data types; the
+mapping between these data types depends on the dimension (which is a template
+parameter) for which a program is presently compiled. For example, in the
+piece of code shown above, if the template parameter <TT>dim</TT> equals one,
+two, or three, the objects marked are lines, quadrilaterals, and cells,
+respectively. The code to switch these data types looks roughly like this:
+<PRE>
+ class TriaDimensionInfo<2>
+ {
+ typedef quad_iterator cell_iterator;
+ typedef line_iterator face_iterator;
+ //...
+ };
+
+ class TriaDimensionInfo<3>
+ {
+ typedef hex_iterator cell_iterator;
+ typedef quad_iterator face_iterator;
+ //...
+ };
+
+
+ template <int dim>
+ class Triangulation : public TriaDimensionInfo<dim>
+ {
+ typedef TriaDimensionInfo<dim>::cell_iterator cell_iterator;
+ typedef TriaDimensionInfo<dim>::face_iterator face_iterator;
+ //...
+ };
+</PRE>By preferring a template
+parameter over preprocessor variables, it is possible to retain a greater
+amount of type safety as well as the possibility to use parts of programs with
+different space dimensions together at the same time.
+
+<P>
+If an algorithm is not dimension independent, it is possible to specialize
+it for some or all dimensions where its form deviates from the general
+template. This is typically the case in one space dimension, where algorithms
+often work a bit different, since no proper faces exist (we do not
+consider points proper objects in the same sense as lines, quadrilaterals, etc.
+since their lack of extension in any direction does not permit to define shape
+functions on them).
+
+<P>
+Being called from some dimension independent part of the code, the
+compiler automatically figures out which version of a function to
+call; dimension independent and dimension dependent code therefore
+work together smoothly without the intervention of the programmer.
+This approach has proven useful when several programs originally
+written for two-dimensional computations ran by mere recompilation in
+three space dimension as well when the three dimensional support
+within the library became available.
+
+<P>
+
+<H2><A NAME="SECTION00013000000000000000">
+History</A>
+</H2>
+
+<P>
+As a last note before we start with the actual description of the library, we
+want to give a brief historical overview of the evolution of the project. The
+following are some of the more important milestones that should be mentioned:
+
+<P>
+<I>1991-1992:</I> Needing finite element software for their diploma
+theses, Guido Kanschat and Franz-Theo Suttmeier start to develop
+finite element codes, first in P<SMALL>ASCAL</SMALL>, later in <TT>C++</TT>. Working
+on quasi-regular solutions to variational systems, the need for grid
+adaption becomes obvious. A finite element code for solving
+two-dimensional problems in plasticity and quasi-linear elliptic
+systems evolves [<A
+ HREF="node6.html#KS92">10</A>].
+
+<P>
+<I>Since 1993:</I> <I>DEAL</I>, short for <I>D</I>ifferential
+<I>E</I>quations <I>A</I>nalysis <I>L</I>ibrary, is developed by
+Guido Kanschat and Franz-Theo Suttmeier. <TT>C++</TT> becomes the
+language of choice for the reasons mentioned in the introduction and
+because it is the only advanced programming language portable to a
+T805 parallel computer.
+
+<P>
+<I>1995-1996:</I> Roland Becker joins and the implementation of the
+multigrid method allows fast solution of PDE problems. The concept of
+a posteriori error estimates based on dual solutions is developed and
+used in the theses of the three programmers [<A
+ HREF="node6.html#Bec95">4</A>,<A
+ HREF="node6.html#Kan96">9</A>,<A
+ HREF="node6.html#Sut96">16</A>]
+and the article [<A
+ HREF="node6.html#BR95">5</A>]. By this time, the library had grown quite
+complex and no documentation was available. Also, some of the
+structures had turned out too complicated to allow further
+development.
+
+<P>
+<I>End of 1997:</I> At the time that the first author of this paper
+was about to start working on his thesis, it was decided that it was
+in time to do a major redesign of the library. The urge for other than
+<I>Q</I><SUB>1</SUB> finite element spaces and the code reduplication in error
+estimators demanded for a more flexible structure, while mixed
+triangular/quadrilateral grids were not used anymore. We decided to
+rewrite the library from scratch, then called <TT>deal.II</TT>.
+
+<P>
+Design and implementation of the core of the library, i.e. handling of grids
+and degrees of freedom, was done entirely by W. Bangerth, applying the
+knowledge accumulated in the use of the predecessor library, <I>DEAL</I>.
+
+<P>
+<I>Since 1998:</I> Many tools for numerical simulations are added. This
+includes, among others, output for different visualization tools,
+discontinuous elements, finite elements for systems and mixed discretizations,
+and grid transfer operators for time-dependent problems. Multi-level
+algorithms are about to be finished by now.
+
+<P>
+At present, the <TT>deal.II</TT> library is maintained by W. Bangerth and G.
+Kanschat. It is used by several postdoctoral scientists and graduate students
+at the Institute of Applied Mathematics and several undergraduate students; it
+is also used in teaching at the universities of Heidelberg and Minnesota.
+
+<P>
+<HR>
+<!--Navigation Panel-->
+<A NAME="tex2html44"
+ HREF="node2.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html42"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html36"
+ HREF="main.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html45"
+ HREF="node2.html">Grid handling</A>
+<B> Up:</B> <A NAME="tex2html43"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html37"
+ HREF="main.html">No Title</A>
+<!--End of Navigation Panel-->
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Grid handling</TITLE>
+<META NAME="description" CONTENT="Grid handling">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node3.html">
+<LINK REL="previous" HREF="node1.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node3.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html60"
+ HREF="node3.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html58"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html52"
+ HREF="node1.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html61"
+ HREF="node3.html">Finite element spaces</A>
+<B> Up:</B> <A NAME="tex2html59"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html53"
+ HREF="node1.html">Design and evolution of</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
+<UL>
+<LI><A NAME="tex2html62"
+ HREF="node2.html#SECTION00021000000000000000">Hierarchical cell representation</A>
+<LI><A NAME="tex2html63"
+ HREF="node2.html#SECTION00022000000000000000">Hierarchical grid refinement</A>
+</UL>
+<!--End of Table of Child-Links-->
+<HR>
+
+<H1><A NAME="SECTION00020000000000000000"> </A>
+<A NAME="sec:grid"> </A>
+<BR>
+Grid handling
+</H1>
+
+Since the stated goals of the library included adaptive grids that are easy
+to program and should still be fast, hierarchical grids were the only choice
+possible. By hierarchical we here mean that the structures of the grid are
+described hierarchically (points, lines, quadrilaterals, ...) and that
+refinement has to be made hierarchically as well, as opposed to unstructured
+grids. The first point, hierarchical description, serves the simplicity of
+programming, while the second, hierarchical refinement, allows to use fast
+algorithms for grid refinement and in the numerics, such as multigrid solvers.
+These two concepts are outlined in the following subsections.
+
+<P>
+
+<H2><A NAME="SECTION00021000000000000000">
+Hierarchical cell representation</A>
+</H2>
+
+<P>
+As has been outlined above, one of the design criteria was to focus on
+quadrilaterals in two, and hexahedra in three space dimensions. A
+triangulation is therefore made up of the objects in Figure
+<A HREF="node2.html#fig:topology"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>.
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:topology"> </A><A NAME="262"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>Topological constituents of a mesh</CAPTION>
+<TR><TD><IMG
+ WIDTH="510" HEIGHT="147"
+ SRC="img2.gif"
+ ALT="\begin{figure}
+\begin{center}
+\unitlength.08\textwidth
+\begin{picture}
+(12,4)...
+...}}
+\put(9,-.2){\makebox(0,0)[t]{3. Hex}}
+\end{picture} \end{center}\end{figure}"></I></I></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+If the space dimension is lower than three, this sequence is truncated; if
+anyone chooses to implement a finite element code in more than three space
+dimensions (e.g. for general relativity), the sequence may be prolonged.
+
+<P>
+Each of the objects can be made up of a
+number of objects of lower level. They are thus hierarchic and one only
+needs to store pointers to four lines to characterize a quadrilateral, which
+are themselves characterized by two vertices each. A hexahedron is
+characterized by six quadrilaterals which are themselves characterized by four
+lines each and so on.
+
+<P>
+Storing objects this way has advantages over the other possibility, i.e.
+storing the vertices only, because it is possible to do computations on faces
+if they exist as independent objects. This, though obviously also
+possible if only vertices are stored, makes the evaluation of jump terms (in
+error estimators or using discontinuous finite elements), the handling of
+hanging nodes and many more things much simpler, at the expense of a slightly
+increased memory consumption.
+
+<P>
+
+<H2><A NAME="SECTION00022000000000000000">
+Hierarchical grid refinement</A>
+</H2>
+
+<P>
+The other hierarchical property of grids that is applied in <TT>deal.II</TT>
+is hierarchical refinement. At present, there are two concurrent approaches
+to adaptive meshes:
+<UL>
+<LI><I>Unstructured meshes:</I> Using this approach, after
+ computing a refinement indicator, a mesh is created according to this criterion
+ that is not based on the previous grid at all. This can, for example, be done
+ by scattering points onto the domain where the density of points is
+ determined by the error indicator or other criteria. The new grid is now
+ generated using, for example, the Voronoi cells of the point cloud.
+
+ It should be noted that this approach suffers from the expensive
+ computations required for the generation of totally unrelated grids, but is
+ able to produce meshes with smooth transitions of the mesh size parameter
+ <I>h</I>(<I>x</I>).
+<LI><I>Structured meshes:</I> Refining those cells in an existing
+ triangulation with the largest
+ refinement indicator, yields meshes that are hierarchical because every
+ cell, unless belonging to the coarsest mesh, has a mother cell and may be
+ refined further. Usually, the refinement of a cell is done in a way that
+ does not deteriorate the aspect ratio of the cells, i.e. refinement into
+ four congruent triangles for triangular meshes or splitting quadrilaterals into four
+ children. In three space dimensions, the subdivision of
+ tetrahedra may be done using several different possibilities, while the
+ subdivision of a hexahedron is canonical, if no anisotropic refinement is
+ required. This way of constructing adaptive grids was considered already in [<A
+ HREF="node6.html#RM80">15</A>].
+
+ The problem with this approach is that, refining one cell, there
+ remains an unbalanced vertex on each side if the respective neighbor is not
+ refined as well. There are basically two strategies to handle these:
+ Using special refinement rules for the neighbor to eliminate these
+ hanging nodes (e.g. red-green refinement of triangles) or allowing for
+ hanging nodes and treat them in a special way to ensure continuity of finite
+ element functions at these points (e.g. by formulating the continuity
+ requirement as a constraint and inserting this into the matrices and
+ vectors).
+
+ It should be noted that the grids produced using this approach usually have
+ relatively steep gradients at the boundaries between two regions of
+ different refinement depths, but refinement can be made very fast. Furthermore, transfer of data between meshes is highly accurate and fast.
+</UL>Since the additional information in structured meshes can be favorably
+used in multigrid algorithms as well as in the fast generation of new
+meshes from a given one, we chose the second approach. Furthermore,
+because the generation of red-green-like refinement rules for
+quadrilaterals is relatively complex without recourse to triangles and
+because any of these special refinements of some elements destroys the
+regularity in the data structures, we chose to impose the
+compatibility conditions at interfaces of cells of different
+refinement depths as constraints to the system of equations. It should
+be noted that these constraints need not be incorporated using a
+Lagrangian multiplier (which would lead to saddle point problems), but
+can be inserted into the matrix and right hand side, thus retaining
+the properties of the matrices (cf. Section <A HREF="node3.html#sub:hnodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>). In
+particular, symmetric and positive definite matrices retain these properties.
+
+<P>
+Using the described approach, all lines, quadrilaterals, etc. are refined in a
+uniform fashion thus allowing for fast algorithms exploiting this structure.
+For these, multigrid algorithms based on hierarchical bases come to mind.
+However, the structure is also particularly suited for time dependent problems
+with grids that may differ between any two time steps and where the transfer
+of the old solution to the new grid can only be done efficiently if the two
+grids are related in some way; such a relationship can be obtained by using
+the same coarse grid with different refinement depths on the different time
+steps. In that case, integration of the old solution with the new test
+functions can even be done exactly, leading to both higher accuracy and
+dramatic speed improvements compared with unstructured mesh approaches.
+
+<P>
+<HR>
+<!--Navigation Panel-->
+<A NAME="tex2html60"
+ HREF="node3.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html58"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html52"
+ HREF="node1.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html61"
+ HREF="node3.html">Finite element spaces</A>
+<B> Up:</B> <A NAME="tex2html59"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html53"
+ HREF="node1.html">Design and evolution of</A>
+<!--End of Navigation Panel-->
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Finite element spaces</TITLE>
+<META NAME="description" CONTENT="Finite element spaces">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node4.html">
+<LINK REL="previous" HREF="node2.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node4.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html72"
+ HREF="node4.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html70"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html64"
+ HREF="node2.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html73"
+ HREF="node4.html">Iterative solvers</A>
+<B> Up:</B> <A NAME="tex2html71"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html65"
+ HREF="node2.html">Grid handling</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
+<UL>
+<LI><A NAME="tex2html74"
+ HREF="node3.html#SECTION00031000000000000000">Finite element objects</A>
+<LI><A NAME="tex2html75"
+ HREF="node3.html#SECTION00032000000000000000">Computation of shape function values</A>
+<LI><A NAME="tex2html76"
+ HREF="node3.html#SECTION00033000000000000000">Hanging nodes</A>
+</UL>
+<!--End of Table of Child-Links-->
+<HR>
+
+<H1><A NAME="SECTION00030000000000000000"> </A>
+<A NAME="sec:fe"> </A>
+<BR>
+Finite element spaces
+</H1>
+
+In finite element theory, the discrete function spaces are represented by the
+vector space of node values. Each node value denotes one degree of freedom in
+this vector space. The functionals defining the degrees of freedom, for
+example the interpolation points of Lagrangian elements or face integrals for
+some nonconforming elements, may be associated with any of the basic topological
+objects of a mesh, as shown in Figure <A HREF="node2.html#fig:topology"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>. The <TT>FiniteElement</TT>
+class describing a certain finite element states the objects on which these
+functionals are defined. For neighboring cells, these nodes may coincide, in
+which case they are identified.
+
+<P>
+In case of local refinement (<I>h</I> or <I>p</I>), an interface between two cells might
+carry different node values, which we call <EM>hanging nodes</EM>. Then,
+additional compatibility conditions have to be imposed numerically, as we will
+explain below in Section <A HREF="node3.html#sub:hnodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>.
+
+<P>
+
+<H2><A NAME="SECTION00031000000000000000">
+Finite element objects</A>
+</H2>
+
+<P>
+A finite element space can be viewed as the function space spanned by a
+number of relatively simple basis functions. These basis functions are chosen
+such that they have a small support, in general at most as many cells as may
+be adjacent at any one vertex in the triangulation. Furthermore, they are
+usually defined on each cell within their domain of support separately, with
+some compatibility condition for the interfaces between these subdomains;
+compatibility conditions may be e.g. continuity along a face between two cells (for
+<I>H</I><SUP>1</SUP>-conforming elements), equality of the mean value of the shape function on both
+sides of a face (Crouzeix-Raviart [<A
+ HREF="node6.html#CR73">8</A>], Rannacher-Turek [<A
+ HREF="node6.html#RT92">13</A>])
+or its normal component (Raviart-Thomas [<A
+ HREF="node6.html#RT77">14</A>], Brezzi-Douglas-Marini [<A
+ HREF="node6.html#BF91">7</A>]).
+
+<P>
+Due to these properties, it is convenient for the implementation to consider a
+finite element space as consisting of a set of shape functions defined on a
+cell and compatibility conditions at the boundaries of the cell; this
+viewpoint stresses a purely local description of the space which enables us to
+do computations on each cell separately in most
+cases. A further abstraction is possible in some cases, where the shape
+functions can be computed on the unit cell and only afterwards need to be
+transformed to the actual grid cell; this is possible for interpolation
+elements, but not for all elements involving line integrals, normal
+derivatives, etc.
+
+<P>
+With these considerations in mind, the representation of a finite element in
+<TT>deal.II</TT> is a class that provides the shape functions and its
+derivatives on the unit cell (if possible, otherwise on the actual grid cell),
+and the transformation from unit to real cell and its derivatives. Furthermore,
+it provides necessary information to the class managing global degrees of freedom.
+This includes the kind of topological object
+ (i.e. on vertices, line,
+quadrilaterals, etc.) a degree of freedom is associated with and the type of
+compatibility conditions between adjacent elements.
+
+<P>
+However, looking at actual finite element programs, one notes that most of the
+information listed above is not necessary to application programs. While
+compatibility and transformations are of interest to the internal functions of
+the library, application programs almost always are only interested in the
+restriction of a finite element field or shape function to a grid cell.
+Here, however, it is important to note that one usually is not interested in
+the finite element as a continuous function, but only at a specified set of
+points, for example in quadrature points located on a cell or a face. Since
+codes for finite element applications usually do not use the analytical representation of
+the shape functions (which can be rather complicated on the cells), but
+computations are done using quadrature formulæ.
+
+<P>
+In order to make access to actual finite elements more efficient and
+structured, <TT>deal.II</TT> offers an abstraction of a finite
+element restricted to a set of points on a cell. This interface is provided by
+the <TT>FEValues</TT> class described in the next subsection. The actual finite
+element class is hardly ever accessed directly by application programs and
+indeed by none of the existing applications built upon <TT>deal.II</TT>.
+
+<P>
+
+<H2><A NAME="SECTION00032000000000000000">
+Computation of shape function values</A>
+</H2>
+Integrating and assembling matrices and right hand sides can consume a
+considerable amount of time during the execution of a finite element
+program. This is especially true in non-linear applications, where the
+process of solving the linear system is not necessarily predominant anymore.
+Therefore, the access to finite element shape functions is not only a
+question of defining a well structured interface, it is also
+a matter of run-time efficiency.
+
+<P>
+Analyzing finite element software, we observe that shape functions are
+always used in the same context: integration on a grid cell. This
+means, that shape functions are always used in combination with a
+quadrature rule. We exploit this relationship by introducing a special
+class <TT>FEValues</TT> combining quadrature and shape functions; in
+fact it can be considered to be the restriction of the trial space on
+the whole mesh to the quadrature points of a given quadrature rule
+applied to a single element of the triangulation. An object of this
+class will compute all values of the shape functions at the
+appropriate time and store them in arrays.
+These values come basically in two categories:
+<DL COMPACT>
+<DT>1.
+<DD>Values only depending on the quadrature point on the unit
+cell. These are for instance the function values of standard
+ Lagrangian elements.
+<DT>2.
+<DD>Values depending on the actual grid cell. In this class are for example
+ values of derivatives, since they have to be transformed by
+ the tangent mapping of the transformation between unit cell and
+ actual cell, but also the actual locations of the quadrature points in physical
+ space.
+</DL>It should be remarked here that the category a certain value belongs
+to is dependent on the type of finite element. While for standard
+Lagrangian elements, values of the shape functions belong to the
+first, in the case of Raviart-Thomas type elements e.g. they are of the
+second kind.
+
+<P>
+The two kinds of behavior are reflected in the fact that the tables of
+<TT>FEValues</TT> are built at different times. Tables of the first
+category are already filled upon construction, where <TT>FEValues</TT> objects
+obtain
+information about quadrature points and finite element shape functions. This
+is usually done before a loop over all cells starts. The second type of
+values is computed in a function that has to be
+called within the loop for each grid cell before any evaluations are done.
+
+<P>
+It is up to the interaction of <TT>FiniteElement</TT> and <TT>FEValues</TT> to do
+these computations as efficiently as possible. The user should give some
+hints though: <TT>FEValues</TT> takes a group of flags, telling it
+which fields need to be computed on each cell; if second derivatives are
+not used in a loop, they will not be computed on each element.
+
+<P>
+
+<H2><A NAME="SECTION00033000000000000000"> </A>
+<A NAME="sub:hnodes"> </A>
+<BR>
+Hanging nodes
+</H2>
+
+<P>
+As mentioned briefly above, we obtain hanging nodes at interfaces between
+cells of differing refinement,
+<A NAME="tex2html3"
+ HREF="footnode.html#foot400"><SUP>1</SUP></A>
+see Figure <A HREF="node3.html#fig:hanging-nodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>. The
+degrees of freedom on the refined side of a face (for example the left side of
+the face with end points <I>P</I><SUB>1</SUB> and <I>P</I><SUB>2</SUB> in the figure) are not all matched by
+degrees of freedom on the coarse side, so in order to guarantee continuity
+<A NAME="tex2html4"
+ HREF="footnode.html#foot479"><SUP>2</SUP></A>
+of the finite element space along
+this face we need to impose additional constraints. In order to
+illustrate the process, let <I>V</I><SUB><I>h</I></SUB> be
+the original trial space including the continuity requirement on its
+members, while
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+be a finite element space that is
+constructed from the union of the same shape functions as in <I>V</I><SUB><I>h</I></SUB>, but
+restricted to each cell separately;
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+therefore may contain
+functions that are discontinuous along refined faces. While hanging
+nodes carry degrees of freedom in
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">,
+they do not do so in <I>V</I><SUB><I>h</I></SUB>.
+
+<P>
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:hanging-nodes"> </A><A NAME="439"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>A simple grid with a hanging node.</CAPTION>
+<TR><TD><IMG
+ WIDTH="321" HEIGHT="173"
+ SRC="img4.gif"
+ ALT="\begin{figure}\unitlength1.5cm
+\begin{center}
+\begin{picture}
+(4,2.5)
+\thinlines...
+...{$Q_4$ }}
+\put(0,0){\makebox(1,1){$Q_1$ }}
+\end{picture}\end{center}\end{figure}"></I></I></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+<P>
+Since doing computations with functions from
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+is much simpler
+(because it can be done locally on each cell without taking care that there
+may be coarser or finer cells around, and because we would like to associate
+degrees of freedom to all vertices and lines, irrespective of their
+neighborhood), we would like to use
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+as long as possible and use the
+constraints that <I>V</I><SUB><I>h</I></SUB> has over
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+as late as possible in the solution
+of the problem. This can be done in the following way (cf. [<A
+ HREF="node6.html#Kan96">9</A>,<A
+ HREF="node6.html#Koz94">12</A>];
+[<A
+ HREF="node6.html#RM80">15</A>] also shows how to do this, but the algorithms are significantly
+more complex since more than one irregular node is allowed per face).
+
+<P>
+Assume we had to solve the problem: <I>find <IMG
+ WIDTH="58" HEIGHT="34" ALIGN="MIDDLE" BORDER="0"
+ SRC="img5.gif"
+ ALT="$u\in V_h$">,
+such that for all
+ <IMG
+ WIDTH="57" HEIGHT="34" ALIGN="MIDDLE" BORDER="0"
+ SRC="img6.gif"
+ ALT="$v\in V_h$"></I>
+<BR>
+<IMG
+ WIDTH="121" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
+ SRC="img7.gif"
+ ALT="\begin{gather*}a(v, u) = (v,f)
+\end{gather*}">
+<BR>
+with a bilinear form
+<!-- MATH: $a(\cdot,\cdot)$ -->
+<IMG
+ WIDTH="48" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img8.gif"
+ ALT="$a(\cdot,\cdot)$">
+and the <I>L</I><SUB>2</SUB> scalar product
+
+<!-- MATH: $(\cdot,\cdot)$ -->
+<IMG
+ WIDTH="38" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img9.gif"
+ ALT="$(\cdot,\cdot)$">.
+We would like to state this problem in
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+instead of
+<I>V</I><SUB><I>h</I></SUB>. We take the standard finite element bases
+<!-- MATH: $\{\varphi_i\}$ -->
+<IMG
+ WIDTH="41" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img10.gif"
+ ALT="$\{\varphi_i\}$">
+of <I>V</I><SUB><I>h</I></SUB> and
+<!-- MATH: $\{\tilde\varphi_i\}$ -->
+<IMG
+ WIDTH="41" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img11.gif"
+ ALT="$\{\tilde\varphi_i\}$">
+of
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">.
+Now, because <I>V</I><SUB><I>h</I></SUB> is a subspace of
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">(it is
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">
+with some constraints) every function <IMG
+ WIDTH="22" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
+ SRC="img12.gif"
+ ALT="$\varphi_i$">
+can be
+written as a linear combination of basis functions of
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">:
+
+<!-- MATH: $\varphi_i = \sum_{j=1}^{\tilde
+N}C_{ij}\tilde\varphi_i$ -->
+<IMG
+ WIDTH="138" HEIGHT="50" ALIGN="MIDDLE" BORDER="0"
+ SRC="img13.gif"
+ ALT="$\varphi_i = \sum_{j=1}^{\tilde
+N}C_{ij}\tilde\varphi_i$">.
+This defines a matrix <I>C</I><SUB><I>ij</I></SUB>. For example, for
+bilinear shape functions the function <IMG
+ WIDTH="25" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
+ SRC="img14.gif"
+ ALT="$\varphi_1$">
+associated with node <I>P</I><SUB>1</SUB>in Figure <A HREF="node3.html#fig:hanging-nodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A> can be written as
+
+<!-- MATH: $\varphi_1=\tilde\varphi_1+\tfrac 12\tilde\varphi_{10}$ -->
+<IMG
+ WIDTH="130" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
+ SRC="img15.gif"
+ ALT="$\varphi_1=\tilde\varphi_1+\tfrac 12\tilde\varphi_{10}$">;
+the support of these
+three shape functions are
+<!-- MATH: $\mathrm{supp}(\varphi_1)=Q_0\cup Q_2\cup Q_2$ -->
+<IMG
+ WIDTH="212" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img16.gif"
+ ALT="$\mathrm{supp}(\varphi_1)=Q_0\cup Q_2\cup Q_2$">,
+
+<!-- MATH: $\mathrm{supp}(\tilde \varphi_1)=Q_0\cup Q_2$ -->
+<IMG
+ WIDTH="169" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img17.gif"
+ ALT="$\mathrm{supp}(\tilde \varphi_1)=Q_0\cup Q_2$">,
+and
+
+<!-- MATH: $\mathrm{supp}(\tilde\varphi_{10})=Q_2\cup Q_3$ -->
+<IMG
+ WIDTH="176" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img18.gif"
+ ALT="$\mathrm{supp}(\tilde\varphi_{10})=Q_2\cup Q_3$">,
+respectively.
+<!-- MATH: $\tilde\varphi_1$ -->
+<IMG
+ WIDTH="25" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
+ SRC="img19.gif"
+ ALT="$\tilde\varphi_1$">
+is
+discontinuous along the line <I>P</I><SUB>1</SUB>-<I>P</I><SUB>10</SUB>, while
+<!-- MATH: $\tilde\varphi_{10}$ -->
+<IMG
+ WIDTH="31" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
+ SRC="img20.gif"
+ ALT="$\tilde\varphi_{10}$">
+is
+discontinuous along the whole line <I>P</I><SUB>1</SUB>-<I>P</I><SUB>2</SUB>, because
+
+<!-- MATH: $\tilde\varphi_{10}|_{Q_0}\equiv 0$ -->
+<IMG
+ WIDTH="90" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
+ SRC="img21.gif"
+ ALT="$\tilde\varphi_{10}\vert _{Q_0}\equiv 0$">.
+
+<P>
+This representation of basis functions
+implies that a function <IMG
+ WIDTH="58" HEIGHT="34" ALIGN="MIDDLE" BORDER="0"
+ SRC="img5.gif"
+ ALT="$u\in V_h$">
+must be representable as
+<!-- MATH: $u=C\tilde u$ -->
+<IMG
+ WIDTH="66" HEIGHT="18" ALIGN="BOTTOM" BORDER="0"
+ SRC="img22.gif"
+ ALT="$u=C\tilde u$">
+with
+some function
+<!-- MATH: $\tilde u\in\tilde V_h$ -->
+<IMG
+ WIDTH="58" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img23.gif"
+ ALT="$\tilde u\in\tilde V_h$">,
+where in the latter representation we
+identified the function <I>u</I> by the vector of its nodal
+values. For the grid in Figure <A HREF="node3.html#fig:hanging-nodes"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A> and bilinear elements,
+the matrix <I>C</I> has the following form:
+<BR><P></P>
+<DIV ALIGN="CENTER">
+<!-- MATH: \begin{equation*}
+C \in R^{10 \times 11}, \qquad
+C_{ii}=1, \qquad
+ C_{1,10} = C_{2,10} = \tfrac 12.
+\end{equation*} -->
+
+
+<IMG
+ WIDTH="382" HEIGHT="35"
+ SRC="img24.gif"
+ ALT="\begin{displaymath}C \in R^{10 \times 11}, \qquad
+C_{ii}=1, \qquad
+C_{1,10} = C_{2,10} = \tfrac 12.
+\end{displaymath}">
+</DIV>
+<BR CLEAR="ALL">
+<P></P>
+All other entries are zero. Since most of the columns (notably those belonging to
+non-constrained nodes) consist only of the diagonal entry, we only need store
+those columns that deviate from this form. Note that for simplicity we have here
+numbered the only constrained node such that it is the last one. This way,
+nodal numbers for <I>V</I><SUB><I>h</I></SUB> can be chosen to be the same as for
+<!-- MATH: $\tilde V_h$ -->
+<IMG
+ WIDTH="24" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img3.gif"
+ ALT="$\tilde V_h$">,
+simply
+dropping the numbers of constrained nodes following those of unconstrained
+ones. If we had not chosen this numbering, we would need to permute the rows
+in <I>C</I>, which would move the entries in rows of unconstrained nodes to
+nondiagonal places.
+
+<P>
+We can now restate the problem as follows: <I>find
+<!-- MATH: $\tilde u\in \tilde V_h$ -->
+<IMG
+ WIDTH="58" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img23.gif"
+ ALT="$\tilde u\in\tilde V_h$">
+such that for all
+<!-- MATH: $\tilde v\in \tilde V_h$ -->
+<IMG
+ WIDTH="57" HEIGHT="43" ALIGN="MIDDLE" BORDER="0"
+ SRC="img25.gif"
+ ALT="$\tilde v\in \tilde V_h$"></I>
+<BR>
+<IMG
+ WIDTH="279" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
+ SRC="img26.gif"
+ ALT="\begin{gather*}\tilde v_i C_{i j} a(\tilde\varphi_j,\tilde\varphi_k) C_{l k}\tilde u_k
+=
+\tilde v_i C_{i j} (\varphi_j,f),
+\end{gather*}">
+<BR>
+which amounts to solving the linear system of equations
+<BR>
+<IMG
+ WIDTH="120" HEIGHT="22" ALIGN="BOTTOM" BORDER="0"
+ SRC="img27.gif"
+ ALT="\begin{gather*}C\tilde A C^T \tilde u = C \tilde f.
+\end{gather*}">
+<BR>
+It should be noted that <IMG
+ WIDTH="19" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
+ SRC="img28.gif"
+ ALT="$\tilde A$">
+is assembled as usual, i.e. cell-wise
+without the need to look at the neighboring cells, and that it is relatively
+simple to generate
+<!-- MATH: $C\tilde A C^T$ -->
+<IMG
+ WIDTH="59" HEIGHT="22" ALIGN="BOTTOM" BORDER="0"
+ SRC="img29.gif"
+ ALT="$C\tilde A C^T$">
+in-place, i.e. without the need for another
+matrix where we copy the result into. In particular, the sparsity pattern of
+<IMG
+ WIDTH="19" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
+ SRC="img28.gif"
+ ALT="$\tilde A$">
+can be obtained from that of <I>A</I> by filling in some additional
+places that can be computed beforehand. The same holds for the right hand
+side. These properties result from the fact that each hanging node may only be
+constrained once, which however limits the difference in refinement to one
+level of cells in three space dimensions that are adjacent at one edge only.
+
+In order to see how this property-conservation can be obtained, we use another
+matrix <IMG
+ WIDTH="20" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img30.gif"
+ ALT="$\hat C$">
+instead of <I>C</I>, where we add additional rows for each
+constrained node such that it becomes square. In doing so, there is no need to
+renumber the degrees of freedom in a way as to order constrained nodes to the
+end. The additional rows in <IMG
+ WIDTH="20" HEIGHT="22" ALIGN="BOTTOM" BORDER="0"
+ SRC="img31.gif"
+ ALT="$\tilde C$">
+are set to zero only and the diagonal
+elements of all rows apart from the newly added ones are equal to one, which
+allows for very efficient storage mechanisms. Multiplying <IMG
+ WIDTH="19" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
+ SRC="img28.gif"
+ ALT="$\tilde A$">by <IMG
+ WIDTH="30" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img32.gif"
+ ALT="$\hat C^T$">
+from the right, only multiplication with rows in <IMG
+ WIDTH="20" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img30.gif"
+ ALT="$\hat C$">
+have
+to be taken care of that contain either only zeroes (resulting in a blanked
+out column in
+<!-- MATH: $\tilde A\hat C^T$ -->
+<IMG
+ WIDTH="44" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img33.gif"
+ ALT="$\tilde A\hat C^T$">
+for each constrained node) or that contain
+entries other than only the diagonal entry, which are nodes that constrain
+another one (resulting in multiples of some columns being added to other
+columns). The multiplication with <IMG
+ WIDTH="20" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img30.gif"
+ ALT="$\hat C$">
+from the left can be done along
+the same lines.
+
+<P>
+In practice, due to the special structure of <IMG
+ WIDTH="20" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img30.gif"
+ ALT="$\hat C$">,
+multiplication by <IMG
+ WIDTH="20" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img30.gif"
+ ALT="$\hat C$">
+from the left and <IMG
+ WIDTH="30" HEIGHT="23" ALIGN="BOTTOM" BORDER="0"
+ SRC="img32.gif"
+ ALT="$\hat C^T$">
+from the right can be done at the same time
+and with writing the results into the same matrix where previously <IMG
+ WIDTH="19" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
+ SRC="img28.gif"
+ ALT="$\tilde A$">was stored. We call this process <I>condensation</I>. Lines and columns
+belonging to constrained nodes are filled with zeroes, effectively eliminating
+these degrees of freedom from the system of equations in the same way as if we
+used the original matrix <I>C</I>.
+
+<P>
+<HR>
+<!--Navigation Panel-->
+<A NAME="tex2html72"
+ HREF="node4.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html70"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html64"
+ HREF="node2.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html73"
+ HREF="node4.html">Iterative solvers</A>
+<B> Up:</B> <A NAME="tex2html71"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html65"
+ HREF="node2.html">Grid handling</A>
+<!--End of Navigation Panel-->
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Iterative solvers</TITLE>
+<META NAME="description" CONTENT="Iterative solvers">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node5.html">
+<LINK REL="previous" HREF="node3.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node5.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html85"
+ HREF="node5.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html83"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html77"
+ HREF="node3.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html86"
+ HREF="node5.html">Example applications</A>
+<B> Up:</B> <A NAME="tex2html84"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html78"
+ HREF="node3.html">Finite element spaces</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
+<UL>
+<LI><A NAME="tex2html87"
+ HREF="node4.html#SECTION00041000000000000000">Iterative linear solvers of <I>LAC</I></A>
+<UL>
+<LI><A NAME="tex2html88"
+ HREF="node4.html#SECTION00041100000000000000">Requirements on template parameters</A>
+<LI><A NAME="tex2html89"
+ HREF="node4.html#SECTION00041200000000000000">Administrative classes</A>
+</UL></UL>
+<!--End of Table of Child-Links-->
+<HR>
+
+<H1><A NAME="SECTION00040000000000000000"> </A>
+<A NAME="sec:solver"> </A>
+<BR>
+Iterative solvers
+</H1>
+
+Solution methods for finite equations are quite generally
+iterative. This is true for non-linear equations, where we use
+different variations of Newton's method, and linear equations. Even
+time-stepping methods fit into this framework.
+
+<P>
+Since solution methods are used in many different contexts, but are
+usually time-critical, they should be implemented as general as is
+possible without loosing efficiency. Therefore, linear solvers and
+matrix classes are extracted into a separate library called
+<I>LAC</I>, short for <I>L</I>inear <I>A</I>lgebra <I>C</I>lasses.
+
+<P>
+
+<H2><A NAME="SECTION00041000000000000000">
+Iterative linear solvers of <I>LAC</I></A>
+</H2>
+
+<P>
+Solvers in <TT>LAC</TT> are supposed to be basic multi-purpose tools. In
+particular, the requirements for matrix and vector classes involved should be
+as low as possible. In <I>LAC</I> we chose to not use abstract base classes
+to state these interface requirements. Instead, matrix and vector are template
+arguments to the solvers, e.g. <code>SolverCG<Matrix, Vector></code>.
+
+<P>
+
+<H3><A NAME="SECTION00041100000000000000">
+Requirements on template parameters</A>
+</H3>
+A minimal interface for a matrix class used for <TT>LAC</TT> Solvers
+is
+<PRE>
+class Matrix
+{
+ public:
+ void vmult (Vector& dst, const Vector& src) const;
+
+ double residual (Vector& dst, const Vector& src,
+ const Vector& right_hand_side) const;
+};
+</PRE>Here, <TT>vmult</TT> for a matrix <I>A</I> should perform
+<!-- MATH: $v_{dst} = A
+v_{src}$ -->
+<I>v</I><SUB><I>dst</I></SUB> = <I>A</I>
+<I>v</I><SUB><I>src</I></SUB>, while <TT>residual</TT> performs
+<!-- MATH: $v_{dst} = v_{rhs} - A
+v_{src}$ -->
+<I>v</I><SUB><I>dst</I></SUB> = <I>v</I><SUB><I>rhs</I></SUB> - <I>A</I>
+<I>v</I><SUB><I>src</I></SUB> and returns the Euclidean norm of the result.
+
+<P>
+The requirements for a preconditioner are even simpler:
+<PRE>
+class Precondition
+{
+ public:
+ void operator() (Vector& dst, const Vector& src) const;
+};
+</PRE>
+<P>
+Unfortunately, the interface of the vector class is more complex. To
+avoid a lot of unnecessary loops, there are different redundant scaled vector
+additions used in the iterative methods.
+
+<P>
+
+<H3><A NAME="SECTION00041200000000000000">
+Administrative classes</A>
+</H3>
+The <I>LAC</I>-solvers do not check for the stopping criterion
+themselves. Instead, they compute the value used by this
+criterion, e.g. the norm of the residual, and hand it over to an
+object of a class called <TT>SolverControl</TT>. This class now decides,
+whether the iteration
+<UL>
+<LI>failed, because for example the maximum number of iteration steps is
+ exceeded;
+<LI>terminates successfully, because the aimed stopping criterion
+ was reached;
+<LI>continues, until one of the first two conditions is reached.
+</UL>The provided class <TT>SolverControl</TT> has a standard version of
+this virtual function <TT>check</TT> built in. It can be replaced by a
+derived class, for instance to balance convergence of the linear
+solver with some outer iteration.
+
+<P>
+Most solvers need auxiliary vectors. Since it might be advisable in
+many cases that these vectors are pre-allocated and retrieved from a
+special memory, the class <TT>VectorMemory</TT> was introduced. It is
+an abstract base class for a memory handler. If more sophisticated
+allocation methods are needed, a derived class can implement a vector
+pool, where vectors are not deallocated after use, e.g. to avoid
+fragmentation of heap memory or to speed up allocation.
+
+<P>
+<HR>
+<!--Navigation Panel-->
+<A NAME="tex2html85"
+ HREF="node5.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html83"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html77"
+ HREF="node3.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html86"
+ HREF="node5.html">Example applications</A>
+<B> Up:</B> <A NAME="tex2html84"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html78"
+ HREF="node3.html">Finite element spaces</A>
+<!--End of Navigation Panel-->
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Example applications</TITLE>
+<META NAME="description" CONTENT="Example applications">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node6.html">
+<LINK REL="previous" HREF="node4.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node6.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html98"
+ HREF="node6.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html96"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html90"
+ HREF="node4.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html99"
+ HREF="node6.html">Bibliography</A>
+<B> Up:</B> <A NAME="tex2html97"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html91"
+ HREF="node4.html">Iterative solvers</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+<!--Table of Child-Links-->
+<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
+<UL>
+<LI><A NAME="tex2html100"
+ HREF="node5.html#SECTION00051000000000000000">Conservation Laws</A>
+<LI><A NAME="tex2html101"
+ HREF="node5.html#SECTION00052000000000000000">Parameter estimation</A>
+<LI><A NAME="tex2html102"
+ HREF="node5.html#SECTION00053000000000000000">Wave equation</A>
+<LI><A NAME="tex2html103"
+ HREF="node5.html#SECTION00054000000000000000">Boundary approximation</A>
+</UL>
+<!--End of Table of Child-Links-->
+<HR>
+
+<H1><A NAME="SECTION00050000000000000000"> </A>
+<A NAME="sec:examples"> </A>
+<BR>
+Example applications
+</H1>
+
+<P>
+In this section, we give a brief overview of some applications already implemented
+with <TT>deal.II</TT>, to show the range of applicability and to give an idea
+of what our motives were to write such a library.
+
+<P>
+
+<H2><A NAME="SECTION00051000000000000000">
+Conservation Laws</A>
+</H2>
+
+<P>
+The solution of the nonlinear Burgers equation
+<BR>
+<IMG
+ WIDTH="103" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
+ SRC="img34.gif"
+ ALT="\begin{align*}u_t + u u_x = 0
+\end{align*}">
+<BR>
+with given initial and boundary conditions in space and time often yields
+discontinuous solutions, usually even if the data are smooth. Resolving
+these discontinuities without recourse to a globally refined grid is a major
+challenge, especially in view of the fact that the same problems with
+discontinuous solutions occur with other and more important equations as well,
+such as the Euler equations of inviscid, eventually transonic flow.
+
+<P>
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:conservation"> </A><A NAME="819"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>Examples of solutions of conservation laws. Computation: R. Hartmann.</CAPTION>
+<TR><TD>
+<DIV ALIGN="CENTER">
+
+<!-- MATH: $\includegraphics[width=0.4\textwidth]
+{pictures/conservation/burgers1.eps}$ -->
+<IMG
+ WIDTH="138" HEIGHT="112" ALIGN="BOTTOM" BORDER="0"
+ SRC="img35.gif"
+ ALT="\includegraphics[width=0.4\textwidth]
+{pictures/conservation/burgers1.eps}">
+
+
+<!-- MATH: $\includegraphics[width=0.4\textwidth]
+{pictures/conservation/burgers2.eps}$ -->
+<IMG
+ WIDTH="138" HEIGHT="109" ALIGN="BOTTOM" BORDER="0"
+ SRC="img36.gif"
+ ALT="\includegraphics[width=0.4\textwidth]
+{pictures/conservation/burgers2.eps}">
+
+
+<!-- MATH: $\includegraphics[width=0.4\textwidth]
+{pictures/conservation/euler.eps}$ -->
+<IMG
+ WIDTH="164" HEIGHT="133" ALIGN="BOTTOM" BORDER="0"
+ SRC="img37.gif"
+ ALT="\includegraphics[width=0.4\textwidth]
+{pictures/conservation/euler.eps}">
+</I></I></DIV></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+<P>
+The examples in Figure <A HREF="node5.html#fig:conservation"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A> of computations with locally
+refined grids for these equations were done by R. Hartmann. The left and
+middle picture show solutions of the nonlinear Burgers equation with two
+merging shocks on a coarse grid and a refined one; bilinear discontinuous
+elements were used for these computations. On the right, the Euler equations
+for the shock tube problem were solved; shock, contact discontinuity and
+rarefaction wave can clearly be seen.
+
+<P>
+
+<H2><A NAME="SECTION00052000000000000000">
+Parameter estimation</A>
+</H2>
+
+<P>
+In many applications in engineering, one wants to determine the value of a
+parameter from measurements. One example would be the estimation of the
+elasticity parameters within a body from measurements of the displacement
+under a specified load. Another similar problem would be the estimation of the
+conductivity in a porous medium from measurements of the hydraulic
+head. A prototypic elliptic equation would be
+<BR>
+<IMG
+ WIDTH="130" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
+ SRC="img38.gif"
+ ALT="\begin{gather*}-\nabla\cdot (q \nabla u) = f
+\end{gather*}">
+<BR>
+with some boundary conditions. The coefficient <I>q</I>(<I>x</I>) is to be determined
+by minimizing the difference between the solution of this equation for a given
+coefficient, <I>u</I><SUB><I>q</I></SUB>(<I>x</I>), and a measurement <I>u</I><SUB><I>meas</I></SUB>, by variation of <I>q</I>.
+
+<P>
+Problems of this kind usually are ill-posed, i.e. they do not possess a
+continuous dependence of the optimal parameter <IMG
+ WIDTH="21" HEIGHT="34" ALIGN="MIDDLE" BORDER="0"
+ SRC="img39.gif"
+ ALT="$q^\ast$">
+from the measurement
+<I>u</I><SUB><I>meas</I></SUB>, which makes them rather difficult to solve. Furthermore, they are
+strongly nonlinear and usually require many solutions of the forward problem
+(i.e. the elliptic equation for a fixed coefficient) to determine the
+coefficient itself, which makes the efficient solution of the forward problem
+indispensable.
+
+<P>
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:parameter"> </A><A NAME="841"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>Estimated (left) and true coefficients (middle) in a
+ parameter estimation problem. The state variable approximating the
+ measurement is shown in the right column. Top: smooth true
+ coefficient, bottom: discontinuous true coefficient.</CAPTION>
+<TR><TD>
+<DIV ALIGN="CENTER">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_est.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="104" ALIGN="BOTTOM" BORDER="0"
+ SRC="img40.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_est.eps}">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_exact.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="105" ALIGN="BOTTOM" BORDER="0"
+ SRC="img41.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_exact.eps}">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_state.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="105" ALIGN="BOTTOM" BORDER="0"
+ SRC="img42.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/continuous_state.eps}">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_est.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="89" ALIGN="BOTTOM" BORDER="0"
+ SRC="img43.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_est.eps}">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_exact.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img44.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_exact.eps}">
+
+<!-- MATH: $\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_state.eps}$ -->
+<IMG
+ WIDTH="139" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img45.gif"
+ ALT="\includegraphics[width=0.34\textwidth]
+{pictures/parameter/discontinuous_state.eps}">
+</I></I></DIV></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+<P>
+In Figure <A HREF="node5.html#fig:parameter"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A> we show two examples of estimated parameters
+along with the exact values. In order to reduce the degree of ill-posedness
+and to reduce the number of unknowns, the discretization of the parameter <I>q</I>was performed on a coarser grid than the state variable <I>u</I>. In fact, the
+discretization was done on the same grid but we posed additional constraints
+such that each patch of four cells can be written as a shape function on the
+next coarser grid; these constraints can then be inserted into the system
+matrix just as was done for hanging nodes. The discretization of the parameter
+was done with discontinuous elements of one degree lower than the polynomial
+degree with which the state variable was discretized.
+
+<P>
+The top row of the picture shows the approximation of a continuous coefficient
+on a square domain; the state variable was discretized with bilinear elements,
+while the parameter was discretized with discontinuous constant elements. In
+the bottom row, a discontinuous coefficient was to be estimated on a circular
+domain of which one quarter is shown; state and parameter variables
+used bi-quadratic continuous elements and discontinuous bilinear elements,
+respectively. No adaptive grid refinement was performed for the second case.
+
+<P>
+
+<H2><A NAME="SECTION00053000000000000000">
+Wave equation</A>
+</H2>
+
+<P>
+The acoustic wave equation
+<BR>
+<IMG
+ WIDTH="173" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
+ SRC="img46.gif"
+ ALT="\begin{align*}\rho u_{t t} - \nabla\cdot (a\nabla u) = 0,
+\end{align*}">
+<BR>
+associated with suitable initial and boundary conditions occurs in a variety of
+places in physics, among which are water waves, acoustic sound waves in gaseous media,
+electro-magnetics and many other fields. Usually, <I>u</I> is the deviation from
+the state of rest and <IMG
+ WIDTH="14" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
+ SRC="img47.gif"
+ ALT="$\rho$">
+and <I>a</I> denote density and stiffness
+coefficient. The solutions of this equation often share the feature that they
+form waves traveling through the domain. Often the region where waves
+presently are is significantly smaller than the whole domain, so adaptivity
+should be able to reduce the number of cells needed for the solution of this
+equation by a noticeable amount, because coarse grids can be used wherever no
+waves are presently.
+
+<P>
+On the other hand, if we are not interested in the whole solution but only in
+parts of it (say that part traveling in one direction, or an integral over
+part of the domain at the end time), the domain of influence of the region
+where we evaluate itself also often is significantly smaller than the whole
+region, due to the finite speed with which waves spread. Here again a
+reasonable reduction of the required number of cells can be obtained.
+
+<P>
+Typical grids showing this are presented in the following. They were
+obtained using the program described in [<A
+ HREF="node6.html#Ban98">1</A>,<A
+ HREF="node6.html#BR99b">3</A>]. In Figure
+<A HREF="node5.html#fig:wave3d"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A>, a wave traveling outward from the lower left corner of the
+domain is shown. We used a simple error indicator to track the spreading of
+the wave to adjust the computational meshes accordingly; it can be seen that
+rather coarse cells were used where the solution is smooth.
+
+<P>
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:wave3d"> </A><A NAME="861"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>Automatically generated grids tracking an acoustic wave
+ traveling outwards in a three-dimensional domain.</CAPTION>
+<TR><TD>
+<DIV ALIGN="CENTER">
+
+<!-- MATH: $\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0000.eps}$ -->
+<IMG
+ WIDTH="123" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img48.gif"
+ ALT="\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0000.eps}">
+
+
+<!-- MATH: $\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0020.eps}$ -->
+<IMG
+ WIDTH="123" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img49.gif"
+ ALT="\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0020.eps}">
+
+
+<!-- MATH: $\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0040.eps}$ -->
+<IMG
+ WIDTH="123" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img50.gif"
+ ALT="\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0040.eps}">
+
+
+<!-- MATH: $\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0060.eps}$ -->
+<IMG
+ WIDTH="123" HEIGHT="93" ALIGN="BOTTOM" BORDER="0"
+ SRC="img51.gif"
+ ALT="\includegraphics[width=0.3\textwidth]
+{pictures/wave3d/grid.0060.eps}">
+</I></I></DIV></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+<P>
+
+<H2><A NAME="SECTION00054000000000000000">
+Boundary approximation</A>
+</H2>
+
+<P>
+In real-life applications such as air flow around a plane or
+scattering of waves by objects, the computational boundaries
+often are rather complex. In particular, a coarse grid that already
+mostly features the contours of the objects usually has many more
+cells than is acceptable for a coarse grid. One way to avoid this
+problem is to not approximate the boundary with the grid and pose
+the boundary values on the boundary of the grid, but to use a mesh
+that is not necessarily adapted to the physical boundaries and pose
+boundary values in the weak form of the equation. This allows, among
+other advantages, to use more regular meshes and a coarse grid with
+less cells, which enables us to use efficient multigrid algorithms.
+
+<P>
+Figure <A HREF="node5.html#fig:helmholtz"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
+ SRC="/data/allarch/usr/latex2html/icons.gif/cross_ref_motif.gif"></A> shows examples of solutions to Poisson's
+equation using Neumann boundary conditions on an embedded boundary
+curve. The interior of the circle is not part of the domain on which
+the problem is posed and the solution is set to zero there.
+
+<P>
+<BR>
+<DIV ALIGN="CENTER"><A NAME="fig:helmholtz"> </A><A NAME="870"> </A>
+<TABLE WIDTH="50%">
+<CAPTION><STRONG>Figure:</STRONG>
+<I>Approximation of a circular domain by inclusion of boundary
+ values into the weak formulation of the equation.</CAPTION>
+<TR><TD>
+<DIV ALIGN="CENTER">
+
+<!-- MATH: $\includegraphics[width=0.5\textwidth]{pictures/helmholtz/helmholtz.eps}$ -->
+<IMG
+ WIDTH="229" HEIGHT="155" ALIGN="BOTTOM" BORDER="0"
+ SRC="img52.gif"
+ ALT="\includegraphics[width=0.5\textwidth]{pictures/helmholtz/helmholtz.eps}">
+</I></I></DIV></TD></TR>
+</TABLE>
+</DIV>
+<BR>
+<P>
+
+<HR>
+<!--Navigation Panel-->
+<A NAME="tex2html98"
+ HREF="node6.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html96"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html90"
+ HREF="node4.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html99"
+ HREF="node6.html">Bibliography</A>
+<B> Up:</B> <A NAME="tex2html97"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html91"
+ HREF="node4.html">Iterative solvers</A>
+<!--End of Navigation Panel-->
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>Bibliography</TITLE>
+<META NAME="description" CONTENT="Bibliography">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="next" HREF="node7.html">
+<LINK REL="previous" HREF="node5.html">
+<LINK REL="up" HREF="main.html">
+<LINK REL="next" HREF="node7.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<A NAME="tex2html112"
+ HREF="node7.html">
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif.gif"></A>
+<A NAME="tex2html110"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html104"
+ HREF="node5.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Next:</B> <A NAME="tex2html113"
+ HREF="node7.html">About this document ...</A>
+<B> Up:</B> <A NAME="tex2html111"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html105"
+ HREF="node5.html">Example applications</A>
+<BR><BR>
+<!--End of Navigation Panel-->
+<H2><A NAME="SECTIONREF">Bibliography</A>
+</H2>
+<DL COMPACT><DD><P></P><DT><A NAME="Ban98"><STRONG>1</STRONG></A>
+<DD>
+W. Bangerth.
+<BR>Adaptive Finite-Elemente-Methoden zur Lösung der
+ Wellengleichung mit Anwendung in der Physik der Sonne.
+<BR>Diplomarbeit, Institut für Angewandte Mathematik, Universität
+ Heidelberg, 1998.
+
+<P></P><DT><A NAME="DEAL"><STRONG>2</STRONG></A>
+<DD>
+W. Bangerth and G. Kanschat.
+<BR><EM><TT>deal.II</TT> Homepage</EM>.
+<BR><TT>http://gaia.iwr.uni-heidelberg.de/~deal/</TT>.
+
+<P></P><DT><A NAME="BR99b"><STRONG>3</STRONG></A>
+<DD>
+W. Bangerth and R. Rannacher.
+<BR>Finite element approximation of the acoustic wave equation: Error
+ control and mesh adaptation.
+<BR><EM>East-West J. Num. Math.</EM>, (4), 1999.
+<BR>submitted.
+
+<P></P><DT><A NAME="Bec95"><STRONG>4</STRONG></A>
+<DD>
+R. Becker.
+<BR><EM>An Adaptive Finite Element Method for the Incompressible
+ Navier-Stokes Equations on Time-dependent Domains</EM>.
+<BR>Dissertation, Universität Heidelberg, 1995.
+
+<P></P><DT><A NAME="BR95"><STRONG>5</STRONG></A>
+<DD>
+R. Becker and R. Rannacher.
+<BR>Weighted a posteriori error control in FE methods.
+<BR>In <EM>ENUMATH 95</EM>, Paris, September 1995.
+<BR>in [<A
+ HREF="node6.html#enumath97">6</A>].
+
+<P></P><DT><A NAME="enumath97"><STRONG>6</STRONG></A>
+<DD>
+H. G. Bock, F. Brezzi, R. Glowinsky, G. Kanschat, Y. A. Kuznetsov,
+ J. Périaux, and R. Rannacher, editors.
+<BR><EM>ENUMATH 97, Proceedings of the 2nd Conference on Numerical
+ Mathematics and Advanced Applications</EM>, Singapore, 1998. World Scientific.
+
+<P></P><DT><A NAME="BF91"><STRONG>7</STRONG></A>
+<DD>
+F. Brezzi and M. Fortin.
+<BR><EM>Mixed and Hybrid Finite Element Methods</EM>.
+<BR>Springer, 1991.
+
+<P></P><DT><A NAME="CR73"><STRONG>8</STRONG></A>
+<DD>
+M. Crouzeix and P. Raviart.
+<BR>Conforming and nonconforming finite element methods for solving the
+ stationary stokes equations, part I.
+<BR><EM>RAIRO</EM>, R-3:33-76, 1973.
+
+<P></P><DT><A NAME="Kan96"><STRONG>9</STRONG></A>
+<DD>
+G. Kanschat.
+<BR><EM>Parallel and Adaptive Galerkin Methods for Radiative Transfer
+ Problems</EM>.
+<BR>Dissertation, Universität Heidelberg, 1996.
+
+<P></P><DT><A NAME="KS92"><STRONG>10</STRONG></A>
+<DD>
+G. Kanschat and F.-T. Suttmeier.
+<BR>Datenstrukturen für die Methode der finiten Elemente.
+<BR>unpublished, Bonn-Venusberg, 1992.
+
+<P></P><DT><A NAME="KS99c"><STRONG>11</STRONG></A>
+<DD>
+G. Kanschat and F.-T. Suttmeier.
+<BR>A posteriori error estimates for nonconforming finite element
+ schemes.
+<BR><EM>Calcolo</EM>, 36(3):129-141, 1999.
+<BR>to appear.
+
+<P></P><DT><A NAME="Koz94"><STRONG>12</STRONG></A>
+<DD>
+G. Kozlovsky.
+<BR>Solving partial differential equations using recursive grids.
+<BR><EM>Appl. Numer. Math.</EM>, 14:165-181, 1994.
+
+<P></P><DT><A NAME="RT92"><STRONG>13</STRONG></A>
+<DD>
+R. Rannacher and S. Turek.
+<BR>Simple nonconforming quadrilateral stokes element.
+<BR><EM>Num. Meth. PDE</EM>, 8(2):97-111, March 1992.
+
+<P></P><DT><A NAME="RT77"><STRONG>14</STRONG></A>
+<DD>
+P. Raviart and J.-M. Thomas.
+<BR>A mixed finite element method for second order elliptic problems.
+<BR>In I. Galligani and E. Magenes, editors, <EM>Mathematical Aspects of
+ the Finite Element Method</EM>, pages 292-315, New York, 1977. Springer.
+
+<P></P><DT><A NAME="RM80"><STRONG>15</STRONG></A>
+<DD>
+W. C. Rheinboldt and C. K. Mesztenyi.
+<BR>On a data structure for adaptive finite element mesh refinements.
+<BR><EM>ACM Trans. Math. Software</EM>, 6:166-187, 1980.
+
+<P></P><DT><A NAME="Sut96"><STRONG>16</STRONG></A>
+<DD>
+F.-T. Suttmeier.
+<BR><EM>Adaptive Finite Element Approximation of Problems in
+ Elasto-Plasticity Theory</EM>.
+<BR>Dissertation, Universität Heidelberg, 1996.
+</DL>
+
+<P>
+<BR><HR>
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
+* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
+* with significant contributions from:
+ Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
+<HTML>
+<HEAD>
+<TITLE>About this document ... </TITLE>
+<META NAME="description" CONTENT="About this document ... ">
+<META NAME="keywords" CONTENT="main">
+<META NAME="resource-type" CONTENT="document">
+<META NAME="distribution" CONTENT="global">
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+<LINK REL="STYLESHEET" HREF="screen.css" media="screen">
+<LINK REL="previous" HREF="node6.html">
+<LINK REL="up" HREF="main.html">
+</HEAD>
+<BODY >
+<!--Navigation Panel-->
+<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
+ SRC="/data/allarch/usr/latex2html/icons.gif/next_motif_gr.gif">
+<A NAME="tex2html118"
+ HREF="main.html">
+<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
+ SRC="/data/allarch/usr/latex2html/icons.gif/up_motif.gif"></A>
+<A NAME="tex2html114"
+ HREF="node6.html">
+<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
+ SRC="/data/allarch/usr/latex2html/icons.gif/previous_motif.gif"></A>
+<BR>
+<B> Up:</B> <A NAME="tex2html119"
+ HREF="main.html">No Title</A>
+<B> Previous:</B> <A NAME="tex2html115"
+ HREF="node6.html">Bibliography</A>
+<BR>
+<BR>
+<!--End of Navigation Panel-->
+
+<H1><A NAME="SECTION00070000000000000000">
+ About this document ... </A>
+</H1>
+ <P>
+This document was generated using the
+<A HREF="http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 98.1p1 release (March 2nd, 1998)
+<P>
+Copyright © 1993, 1994, 1995, 1996, 1997,
+<A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
+Computer Based Learning Unit, University of Leeds.
+<P>
+The command line arguments were: <BR>
+ <STRONG>latex2html</STRONG> <tt>-split 4 -antialias main.tex</tt>.
+<P>
+The translation was initiated by Wolfgang Bangerth on 1999-12-22
+<BR><HR>
+<ADDRESS>
+<I>Wolfgang Bangerth</I>
+<BR><I>1999-12-22</I>
+</ADDRESS>
+</BODY>
+</HTML>
--- /dev/null
+
+body { background-image: none;
+ background-color: white;
+ }
+
+frameset { background-color: white;
+ border-color: white;
+ border: 0;
+ frameborder: 0;
+ }
+
+td { vertical-align: top; }
+
+dt { font-weight: bold; }
+
+.figure { font-weight: bold;
+ font-size: larger;
+ }
+
+.pagetoc {}
+
+.chapter_title {}
+
+span.parhead { font-weight: bold;
+ }
+
+span.example { font-weight: bold;
+ font-style: italic;
+ }
+pre.example { padding-left: 2 em;
+ text-align: left;
+ text-indent: 0;
+ }
+
+table.navbar { }
+
+
+/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */
+.MATH { font-family: "Century Schoolbook", serif; }
+.MATH I { font-family: "Century Schoolbook", serif; font-weight: bold }
+.BOLDMATH { font-family: "Century Schoolbook", serif; font-weight: bold }
+
+/* implement both fixed-size and relative sizes */
+SMALL.XTINY { font-size : xx-small }
+SMALL.TINY { font-size : x-small }
+SMALL.SCRIPTSIZE { font-size : smaller }
+SMALL.FOOTNOTESIZE { font-size : small }
+SMALL.SMALL { }
+BIG.LARGE { }
+BIG.XLARGE { font-size : large }
+BIG.XXLARGE { font-size : x-large }
+BIG.HUGE { font-size : larger }
+BIG.XHUGE { font-size : xx-large }
+
+/* document-specific styles come next */
<li> <p> We have a few reports written on <acronym>deal.II</acronym>,
the following of which are online:
<ul>
+ <li> A <a href="reports/deal.II-paper/index.html" target="body">
+ paper describing the background, purpose and methods</a>
+ of <acronym>deal.II</acronym>, by Wolfgang Bangerth and
+ Guido Kanschat. This paper is also available as preprint
+ 99-43 from the
+ <a href="http://www.iwr.uni-heidelberg.de" target="_top">
+ IWR preprint server</a>.
<li> A brief report about the class involved in the
<a href="reports/class-hierarchies/index.html">iterators</a>
used to access cells in the triangulations and the data