</p>
<ul>
<li> <p>
- A <a href="reports/deal.II-paper/index.html" target="body">
+ A <a href="reports/deal-paper.pdf">
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">
+ <a href="http://www.iwr.uni-heidelberg.de/sfb/Preprints1999.html" target="_top">
IWR preprint server</a>.
</p>
+++ /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="index.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>
</HEAD>
<BODY >
<!--Navigation Panel-->
-<A NAME="tex2html9"
- HREF="node1.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="next_motif.gif"></A>
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif_gr.gif">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="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-->
+Please use new address <a href="../deal-paper.pdf">deal-paper.pdf</a>
-<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="index.html">
-<LINK REL="up" HREF="index.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="next_motif.gif"></A>
-<A NAME="tex2html42"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html36"
- HREF="index.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html45"
- HREF="node2.html">Grid handling</A>
-<B> Up:</B> <A NAME="tex2html43"
- HREF="index.html">No Title</A>
-<B> Previous:</B> <A NAME="tex2html37"
- HREF="index.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="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="next_motif.gif"></A>
-<A NAME="tex2html42"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html36"
- HREF="index.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html45"
- HREF="node2.html">Grid handling</A>
-<B> Up:</B> <A NAME="tex2html43"
- HREF="index.html">No Title</A>
-<B> Previous:</B> <A NAME="tex2html37"
- HREF="index.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="index.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="next_motif.gif"></A>
-<A NAME="tex2html58"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html52"
- HREF="node1.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="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="index.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="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.
- <p>
- (Note: in parts of the literature, the term "structure mesh" is used
- to indicate that the mesh is actually aligned along coordinate axes,
- is equispaced, and so on. Sometimes, this is referred to as
- ijk-meshes, because each grid point is identified with three
- indices, i, j, and k. Everything else would then be an unstructured
- grid. We use the weaker definition of "structured" as given above.)
-
-</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="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="next_motif.gif"></A>
-<A NAME="tex2html58"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html52"
- HREF="node1.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="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="index.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="index.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="next_motif.gif"></A>
-<A NAME="tex2html70"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html64"
- HREF="node2.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html73"
- HREF="node4.html">Iterative solvers</A>
-<B> Up:</B> <A NAME="tex2html71"
- HREF="index.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="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="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="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="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="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="next_motif.gif"></A>
-<A NAME="tex2html70"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html64"
- HREF="node2.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html73"
- HREF="node4.html">Iterative solvers</A>
-<B> Up:</B> <A NAME="tex2html71"
- HREF="index.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="index.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="next_motif.gif"></A>
-<A NAME="tex2html83"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html77"
- HREF="node3.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html86"
- HREF="node5.html">Example applications</A>
-<B> Up:</B> <A NAME="tex2html84"
- HREF="index.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="next_motif.gif"></A>
-<A NAME="tex2html83"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html77"
- HREF="node3.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html86"
- HREF="node5.html">Example applications</A>
-<B> Up:</B> <A NAME="tex2html84"
- HREF="index.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="index.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="next_motif.gif"></A>
-<A NAME="tex2html96"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html90"
- HREF="node4.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html99"
- HREF="node6.html">Bibliography</A>
-<B> Up:</B> <A NAME="tex2html97"
- HREF="index.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}">
-
-</td><td>
-<!-- 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}">
-
- </td><td>
-<!-- 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="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}">
- </td><td>
-<!-- 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}">
- </td><td>
-<!-- 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}">
-</td></tr><tr><td>
-<!-- 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}">
- </td><td>
-<!-- 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}">
- </td><td>
-<!-- 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="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="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}">
- </td><td>
-
-<!-- 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}">
-
- </td><td>
-<!-- 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}">
-
- </td><td>
-<!-- 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="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="next_motif.gif"></A>
-<A NAME="tex2html96"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html90"
- HREF="node4.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html99"
- HREF="node6.html">Bibliography</A>
-<B> Up:</B> <A NAME="tex2html97"
- HREF="index.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="index.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="next_motif.gif"></A>
-<A NAME="tex2html110"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html104"
- HREF="node5.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="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="index.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://www.dealii.org/</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="index.html">
-</HEAD>
-<BODY >
-<!--Navigation Panel-->
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="next_motif_gr.gif">
-<A NAME="tex2html118"
- HREF="index.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="up_motif.gif"></A>
-<A NAME="tex2html114"
- HREF="node6.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="previous_motif.gif"></A>
-<BR>
-<B> Up:</B> <A NAME="tex2html119"
- HREF="index.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 */
projects / dealii-svn.git / commitdiff
