]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Add the deal.II report to the online docs.
authorwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Wed, 22 Dec 1999 08:25:29 +0000 (08:25 +0000)
committerwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Wed, 22 Dec 1999 08:25:29 +0000 (08:25 +0000)
git-svn-id: https://svn.dealii.org/trunk@2106 0785d39b-7218-0410-832d-ea1e28bc413d

63 files changed:
deal.II/doc/reports/deal.II-paper/footnode.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img1.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img10.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img11.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img12.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img13.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img14.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img15.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img16.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img17.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img18.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img19.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img2.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img20.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img21.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img22.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img23.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img24.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img25.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img26.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img27.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img28.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img29.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img3.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img30.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img31.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img32.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img33.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img34.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img35.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img36.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img37.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img38.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img39.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img4.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img40.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img41.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img42.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img43.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img44.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img45.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img46.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img47.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img48.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img49.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img5.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img50.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img51.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img52.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img6.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img7.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img8.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/img9.gif [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/index.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node1.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node2.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node3.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node4.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node5.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node6.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/node7.html [new file with mode: 0644]
deal.II/doc/reports/deal.II-paper/screen.css [new file with mode: 0644]
deal.II/doc/toc.html

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

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.