]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Move reports over to the homepage
authormaier <maier@0785d39b-7218-0410-832d-ea1e28bc413d>
Mon, 11 Nov 2013 15:51:49 +0000 (15:51 +0000)
committermaier <maier@0785d39b-7218-0410-832d-ea1e28bc413d>
Mon, 11 Nov 2013 15:51:49 +0000 (15:51 +0000)
git-svn-id: https://svn.dealii.org/trunk@31626 0785d39b-7218-0410-832d-ea1e28bc413d

77 files changed:
deal.II/doc/reports/assemble/assemble.pdf [deleted file]
deal.II/doc/reports/assemble/assemble.tex [deleted file]
deal.II/doc/reports/class-hierarchies/1d-dof.eps [deleted file]
deal.II/doc/reports/class-hierarchies/1d-dof.fig [deleted file]
deal.II/doc/reports/class-hierarchies/1d-dof.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/1d-tria.eps [deleted file]
deal.II/doc/reports/class-hierarchies/1d-tria.fig [deleted file]
deal.II/doc/reports/class-hierarchies/1d-tria.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/2d-dof.eps [deleted file]
deal.II/doc/reports/class-hierarchies/2d-dof.fig [deleted file]
deal.II/doc/reports/class-hierarchies/2d-dof.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/2d-tria.eps [deleted file]
deal.II/doc/reports/class-hierarchies/2d-tria.fig [deleted file]
deal.II/doc/reports/class-hierarchies/2d-tria.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/3d-dof.eps [deleted file]
deal.II/doc/reports/class-hierarchies/3d-dof.fig [deleted file]
deal.II/doc/reports/class-hierarchies/3d-dof.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/3d-tria.eps [deleted file]
deal.II/doc/reports/class-hierarchies/3d-tria.fig [deleted file]
deal.II/doc/reports/class-hierarchies/3d-tria.jpg [deleted file]
deal.II/doc/reports/class-hierarchies/index.html [deleted file]
deal.II/doc/reports/codimension-one/desimone-heltai-manigrasso.pdf [deleted file]
deal.II/doc/reports/index.html
deal.II/doc/reports/mapping_q/img1.gif [deleted file]
deal.II/doc/reports/mapping_q/img10.gif [deleted file]
deal.II/doc/reports/mapping_q/img11.gif [deleted file]
deal.II/doc/reports/mapping_q/img12.gif [deleted file]
deal.II/doc/reports/mapping_q/img13.gif [deleted file]
deal.II/doc/reports/mapping_q/img14.gif [deleted file]
deal.II/doc/reports/mapping_q/img15.gif [deleted file]
deal.II/doc/reports/mapping_q/img16.gif [deleted file]
deal.II/doc/reports/mapping_q/img17.gif [deleted file]
deal.II/doc/reports/mapping_q/img18.gif [deleted file]
deal.II/doc/reports/mapping_q/img19.gif [deleted file]
deal.II/doc/reports/mapping_q/img2.gif [deleted file]
deal.II/doc/reports/mapping_q/img20.gif [deleted file]
deal.II/doc/reports/mapping_q/img21.gif [deleted file]
deal.II/doc/reports/mapping_q/img22.gif [deleted file]
deal.II/doc/reports/mapping_q/img23.gif [deleted file]
deal.II/doc/reports/mapping_q/img24.gif [deleted file]
deal.II/doc/reports/mapping_q/img25.gif [deleted file]
deal.II/doc/reports/mapping_q/img26.gif [deleted file]
deal.II/doc/reports/mapping_q/img27.gif [deleted file]
deal.II/doc/reports/mapping_q/img28.gif [deleted file]
deal.II/doc/reports/mapping_q/img29.gif [deleted file]
deal.II/doc/reports/mapping_q/img3.gif [deleted file]
deal.II/doc/reports/mapping_q/img30.gif [deleted file]
deal.II/doc/reports/mapping_q/img31.gif [deleted file]
deal.II/doc/reports/mapping_q/img32.gif [deleted file]
deal.II/doc/reports/mapping_q/img33.gif [deleted file]
deal.II/doc/reports/mapping_q/img34.gif [deleted file]
deal.II/doc/reports/mapping_q/img35.gif [deleted file]
deal.II/doc/reports/mapping_q/img36.gif [deleted file]
deal.II/doc/reports/mapping_q/img37.gif [deleted file]
deal.II/doc/reports/mapping_q/img38.gif [deleted file]
deal.II/doc/reports/mapping_q/img39.gif [deleted file]
deal.II/doc/reports/mapping_q/img4.gif [deleted file]
deal.II/doc/reports/mapping_q/img40.gif [deleted file]
deal.II/doc/reports/mapping_q/img41.gif [deleted file]
deal.II/doc/reports/mapping_q/img42.gif [deleted file]
deal.II/doc/reports/mapping_q/img43.gif [deleted file]
deal.II/doc/reports/mapping_q/img44.gif [deleted file]
deal.II/doc/reports/mapping_q/img45.gif [deleted file]
deal.II/doc/reports/mapping_q/img46.gif [deleted file]
deal.II/doc/reports/mapping_q/img47.gif [deleted file]
deal.II/doc/reports/mapping_q/img48.gif [deleted file]
deal.II/doc/reports/mapping_q/img49.gif [deleted file]
deal.II/doc/reports/mapping_q/img5.gif [deleted file]
deal.II/doc/reports/mapping_q/img50.gif [deleted file]
deal.II/doc/reports/mapping_q/img51.gif [deleted file]
deal.II/doc/reports/mapping_q/img6.gif [deleted file]
deal.II/doc/reports/mapping_q/img7.gif [deleted file]
deal.II/doc/reports/mapping_q/img8.gif [deleted file]
deal.II/doc/reports/mapping_q/img9.gif [deleted file]
deal.II/doc/reports/mapping_q/index.html [deleted file]
deal.II/doc/reports/nedelec/nedelec.pdf [deleted file]
deal.II/doc/reports/new-threads/index.html [deleted file]

diff --git a/deal.II/doc/reports/assemble/assemble.pdf b/deal.II/doc/reports/assemble/assemble.pdf
deleted file mode 100644 (file)
index 073d8af..0000000
Binary files a/deal.II/doc/reports/assemble/assemble.pdf and /dev/null differ
diff --git a/deal.II/doc/reports/assemble/assemble.tex b/deal.II/doc/reports/assemble/assemble.tex
deleted file mode 100644 (file)
index 6e0e966..0000000
+++ /dev/null
@@ -1,948 +0,0 @@
-\documentclass{article}
-\usepackage{times}
-\usepackage{amsmath}
-\usepackage{amsfonts}
-\usepackage{a4}
-\newcommand{\leftpartial}{\overleftarrow \partial}
-\newcommand{\rightpartial}{\overrightarrow \partial}
-\renewcommand{\div}{\nabla\cdot}
-\renewcommand{\vec}[1]{{\mathbf #1}}
-\begin{document}
-
-
-\begin{center}
-  \begin{huge}
-    Assembling matrices in \texttt{deal.II}
-  \end{huge}
-
-  \vspace*{0.5cm}
-
-  \begin{large}
-    Wolfgang Bangerth\\
-    ETH Z\"urich, Switzerland\\[12pt]
-    May 2002
-  \end{large}
-\end{center}
-
-
-\section{Introduction}
-
-Assembling the system matrix for finite element discretizations is standard,
-at least as far as scalar problems are concerned. However, things become a
-little more complicated in implementations once problems are vector-valued,
-and in particular if finite elements are used in which different components of
-vector-valued shape functions are coupled, such as for example for
-divergence-free elements. 
-
-It is this case that we are interested in in this report, and we will discuss
-the implementational details user programs must follow if they want to use
-such elements with \texttt{deal.II}. In order to explain the problem in a
-simple way, we start by reviewing the algorithms that are used, first for the
-scalar case, then for the case of ``simple'' vector-valued finite elements,
-and finally for the most general case.  However, we do not intend to give an
-introduction into the derivation of finite element methods, or of posing a
-partial differential equation in weak form.
-
-The interface for vector-valued finite element shape functions with more than
-one non-zero component that is described in this report is presently being
-implemented, and will be merged with the library after version 3.4 is
-released. Thus, it will be part of version 3.5 or 4.0 of the library,
-depending on which version number we will assign to the successor of 3.4. By
-then, the library will also contain an implementation of Nedelec elements, for
-which these techniques are necessary. The interface for primitive
-vector-valued shape functions, for which only one vector component is
-non-zero, has been part of the library since its publication with version 3.0.
-
-
-
-
-\section{Linear systems for finite element methods}
-
-We start by briefly introducing the way finite element matrices are assembled
-``on paper''. As usual in finite elements, we take the weak form of the partial
-differential equation. In the most general case, it reads: \textit{find $u\in
-  V$ such that}
-\begin{gather*}
-  a(u, v) = (f,v)_\Omega \qquad \forall v\in V,
-\end{gather*}
-where $a(\cdot,\cdot)$ is the bilinear form associated with the partial
-differential equations, and $V$ is the space of test functions. For
-simplicity, we have here assumed that the problem is linear and that then
-$a(\cdot,\cdot)$ is a bilinear form; if the problem is nonlinear, it is
-usually solved using a sequence of linear problems, so this is no restriction.
-
-In finite elements, we define an approximation of the solution $u$ by choosing
-a finite dimensional subspace $V_h$ spanned by the basis functions
-$\{\varphi_i\}$, and searching $u_h\in V_h$ by testing the weak form by the
-test functions from $V_h$. The problem then reads: \textit{find $u_h\in V_h$
-such that}
-\begin{gather*}
-  a(u_h, v_h) = (f,v_h)_\Omega \qquad \forall v_h\in V_h.
-\end{gather*}
-
-Now, $\{\varphi_i\}$ is a basis of $V_h$. We denote the dimension of $V_h$ by
-$N$, and will henceforth let all sums be over the range $0\ldots N-1$, to keep
-with the standard notation of the C/C++ programming languages. With this, we
-can expand the solution $u_h=\sum_{j=0}^{N-1} U_j \varphi_j$, and by
-bilinearity of the form $a(\cdot,\cdot)$, the problem above is equivalent to
-\begin{gather}
-  \label{eq:lin-1}
-  \sum_{j=0}^{N-1} U_j a(\varphi_j,\varphi_i) = (f, \varphi_i)
-  \qquad
-  \forall i=0\ldots N-1.
-\end{gather}
-Denoting
-\begin{gather*}
-  A_{ij} = a(\varphi_j,\varphi_i),
-  \qquad
-  \qquad
-  F_j = (f, \varphi_j),
-\end{gather*}
-the equations determining the expansion coefficients $U_i$ are therefore:
-\begin{gather}
-  \label{eq:lin-2}
-  A U = F.
-\end{gather}
-
-Note that we have taken a reverted order of indices in the definition of $A$,
-since we want the linear system \eqref{eq:lin-2} with the solution to the
-right of the matrix, to keep with standard notation, instead of to the left as
-in \eqref{eq:lin-1}. For symmetric problems, there is no difference, but for
-non-symmetric ones this is a common source for problems and a rather common
-trap. 
-
-For partial differential equations, the bilinear form used in \eqref{eq:lin-1}
-involves an integral over the domain $\Omega$ on which the problem is
-posed. For example, for the Laplace equation we have
-\begin{gather*}
-  A_{ij}
-  =
-  a(\varphi_j, \varphi_i)
-  =
-  (\nabla \varphi_j, \nabla \varphi_i)_\Omega
-  =
-  \int_\Omega \nabla \varphi_j \cdot \nabla \varphi_i \; dx.
-\end{gather*}
-For practical purposes, we split this equation into integrals over the
-individual cells $K$ of the triangulation $\mathbb T$ we use for the
-discretization. In \texttt{deal.II}, these cells are always lines,
-quadrilaterals, or hexahedra. With this, we have that
-\begin{gather*}
-  A = \sum_{K \in {\mathbb T}} A^K,
-  \qquad\qquad
-  A^K_{ij} = a_K(\varphi_j, \varphi_i) 
-  \qquad
-  0\le i,j\le N-1,
-\end{gather*}
-where the bilinear form $a_K(\cdot,\cdot)$ only involves an integral over the
-cell $K$. The important point is that we do so since for the localized basis
-functions used in finite elements, $A^K$ is a matrix with almost only zeros.
-The only elements which are not zero are those corresponding to indices $i,j$
-indicating those shape functions that have support also on the element $K$.
-For example, in 2d and using the usual bilinear shape functions for a scalar
-problem, only the four shape functions associated with the vertices of the
-cell $K$ are nonzero on $K$, and thus only the entries in $A^K$ are nonzero
-where the four rows corresponding to these indices and the respective four
-columns intersect.
-
-In general, assume that there are $N_K$ shape functions with support on cell
-$K$, and let the set of their indices be denoted by $I_K$. Then we can define
-a matrix $\hat A^K$ of (small dimension) $N_K\times N_K$ holding these nonzero
-entries, and we can obtain back the original contribution $A_K$ to $A$ by the
-transformation
-\begin{gather*}
-  A^K_{ij} = 
-  \left\{
-    \begin{array}{ll}
-      0 & \text{if $i\not\in I_K$ or $j\not\in I_K$,} \\
-      \hat A^K_{local(i),local(j)} & \text{otherwise},
-    \end{array}
-  \right.
-  \qquad 0\le i,j\le N-1.
-\end{gather*}
-Here, $local(i)$ gives the number of the global degree of freedom $i$ on the
-cell $K$, i.e. the position of $i$ in the index set $I_K$. One could call
-$\hat A^K$ the \texttt{reduced} form of $A^K$, since the many zero rows and
-column have been stripped.
-
-In general, when assembling the global matrix, the reverse way is used: when
-adding up $A^K$ to $A$, we do so only with $\hat A^K$ by
-\begin{gather*}
-  A_{global(i),global(j)} 
-  +\!\!=
-  \hat A^K_{ij}
-  \qquad
-  \qquad
-  0\le i,j\le N_K-1.
-\end{gather*}
-Thus, indices only run over the (small) range $0\ldots N_K-1$ instead of
-$0\ldots N-1$. Here, $global(i)$ denotes the global number of the degree of
-freedom with number $i$ on this cell $K$, i.e. $global(i)=I_K[i]$, where the
-bracket operator returns the $i$th element of the set $I_K$.
-
-The main part of assembling finite element matrices is therefore to assemble
-the local matrix $\hat A^K$. Before we go on with discussing how this is done
-in \texttt{deal.II}, we would like to comment on the evaluation of the
-integrals involved. Since the integrals are usually too complex to be
-evaluated exactly (they may depend on coefficients appearing in the equation,
-or the solution of previous steps in nonlinear or time-dependent problems),
-they are approximated by quadrature. Assume we have a quadrature formula with
-$N_q$ points $x_q$ defined on cell in real space (as opposed to the unit cell)
-and weights $w_q$. Then, for example for the Laplace equation, we approximate
-\begin{gather}
-  \hat A^K_{ij}
-  \equiv
-  \int_K \nabla\varphi_i \cdot \nabla \varphi_j \; dx
-  \approx
-  \sum_{q=0}^{N_q-1} 
-  \nabla\varphi_i(x_q) \cdot \nabla \varphi_j(x_q)
-  \ w_q |\text{det} \ J(\hat x_q)|.
-\end{gather}
-For other problems, the integrand is different, but the principle remains the
-same. $\text{det}\ J(\hat x_q)$ denotes the determinant of the Jacobian of the
-transformation between the unit cell on which the quadrature weights are
-defined, and the real cell, and $\hat x_q$ is the point on the unit cell
-corresponding to the quadrature point $x_q$ in real space.
-
-Since all matrices and right hand side vectors only require knowledge of the
-values and gradients of shape functions at quadrature points, this is all that
-\texttt{deal.II} usually provides. One can see this as a kind of \textit{view}
-on a finite element, as it only provides a certain perspective on the actual
-definition of a shape function. Nevertheless, this is entirely sufficient for
-all purposes of programming finite element programs. 
-
-In \texttt{deal.II} the \texttt{FEValues} class does this: you give it a
-finite element definition, a quadrature formula object, and an object defining
-the transformation between unit and real cell, and it provides you with the
-values, gradient, and second derivatives of shape functions at the quadrature
-points. It also gives access to the determinant of the Jacobian, although only
-multiplied with $w_q$ as these two are always used in conjunction. It also
-provides you with many other fields, such as normal vectors to the outer
-boundary. In practice you do not need them all computed on each cell; thus,
-you have to specify explicitly in which data you are interested when
-constructing \texttt{FEValues} objects.
-
-In the following, we provide a list of connections between the symbols introduced
-above, and the respective functions and variable names used in typical
-\texttt{deal.II} programs. With this, we will subsequently show the basic
-structure of an assembly routine. If you have already taken a look at the
-example programs provided with \texttt{deal.II}, you will recognize all these
-names. If you haven't, this would be a good time to look at the first
-three of them.
-
-
-\begin{center}
-  \begin{tabular}{|ll|}
-    \hline
-    $A$ & \texttt{system\_matrix} \\
-    $\hat A^K$ & \texttt{cell\_matrix} \\
-    $K$ & \texttt{cell} \\
-    $N$ & \texttt{dof\_handler.n\_dofs()} \\
-    $N_K$ & \texttt{fe.dofs\_per\_cell} \\
-    $I_K$ & \texttt{local\_dof\_indices} \\
-    $N_q$ & \texttt{quadrature\_formula.n\_quadrature\_points} \\
-    $\varphi_i(x_q)$ & \texttt{fe\_values.shape\_value(i,q)} \\
-    $\nabla\varphi_i(x_q)$ & \texttt{fe\_values.shape\_grad(i,q)} \\
-    $x_q$ & \texttt{fe\_values.quadrature\_point(q)} \\
-    $|\text{det} J(\hat x_q)| w_q$ & \texttt{fe\_values.JxW(q)} \\
-    \hline
-  \end{tabular}  
-\end{center}
-
-With this vocabulary, the typical matrix assembly loop in \texttt{deal.II} has
-the following form: first declare a quadrature object and use it for the
-initialization of a \texttt{FEValues} object as discussed above:
-\begin{verbatim}
-  QGauss2<2>  quadrature_formula;
-  FEValues<2> fe_values (fe, quadrature_formula, 
-                         UpdateFlags(update_values    |
-                                     update_gradients |
-                                     update_JxW_values));
-\end{verbatim}
-In practice, you may want to use a different set of fields to be updated on
-each cell. For example if you do not need the values of shape functions on a
-cell, you may omit \texttt{update\_values} from the list. Also note that by
-default a bi- or tri-linear (depending on space dimension) mapping between
-unit and real cell is used. Other mappings are possible, for example quadratic
-ones, or a mapping that makes use of the fact that in many cases cells are
-actually rectangular, rather than arbitrary quadrilaterals; in order to use
-them, another constructor of the \texttt{FEValues} class can be used, which
-takes a mapping object as first argument, before the other arguments listed
-above.
-
-Next we define abbreviations for the values of $N_K$ and $N_q$:
-\begin{verbatim}
-  const unsigned int 
-      dofs_per_cell = fe.dofs_per_cell,
-      n_q_points    = quadrature_formula.n_quadrature_points;
-\end{verbatim}
-Then have an object to store the matrix $\hat A^K$, which is of size
-$N_K\times N_K$:
-\begin{verbatim}
-  FullMatrix<double>   cell_matrix (dofs_per_cell, dofs_per_cell);
-\end{verbatim}
-And an object representing the set of global indices of degrees of freedom,
-previously denoted by $I_K$, that have support on the present cell, i.e. those
-degrees of freedom local to the present cell:
-\begin{verbatim}
-  std::vector<unsigned int> local_dof_indices (dofs_per_cell);
-\end{verbatim}
-The next step is then to loop over all cells:
-\begin{verbatim}
-  typename DoFHandler<dim>::active_cell_iterator
-       cell = dof_handler.begin_active(),
-       endc = dof_handler.end();
-  for (; cell!=endc; ++cell)
-    {
-\end{verbatim}
-On each cell, first tell the \texttt{FEValues} object to compute the values of
-the various fields for this particular cell, and do not forget to reset the
-local matrix $\hat A^K$ to zero before adding it up:
-\begin{verbatim}
-      fe_values.reinit (cell);
-      cell_matrix.clear ();
-\end{verbatim}
-Now comes the main part, assembling the local matrix $\hat A^K$. It consists
-of a loop over all indices $0\le i,j \le N_K$ and all quadrature points $0\le
-q\le N_q$, and summing up the contributions. As this is what we will discuss
-in detail later on, we only denote it here by an ellipse:
-\begin{verbatim}
-      for (unsigned int i=0; i<dofs_per_cell; ++i)
-        for (unsigned int j=0; j<dofs_per_cell; ++j)
-          for (unsigned int q=0; q<n_q_points; ++q)
-            cell_matrix(i,j) += ...;
-
-\end{verbatim}
-After we have $\hat A^K$, we still have to sum it into the global matrix
-$A$. This is done by first getting the set $I_K$ of the global indices of the
-shape functions that were active on this cell, and then distributing $\hat
-A^K$: 
-\begin{verbatim}
-      cell->get_dof_indices (local_dof_indices);
-
-      for (unsigned int i=0; i<dofs_per_cell; ++i)
-        for (unsigned int j=0; j<dofs_per_cell; ++j)
-          system_matrix.add (local_dof_indices[i],
-                             local_dof_indices[j],
-                             cell_matrix(i,j));
-    };
-\end{verbatim}
-When this is done, we go on to the next cell.
-
-Within this framework, the only open point is assembling $\hat A^K$ on one
-quadrature point. This will be subject of the rest of this report.
-
-
-\section{Assembling scalar problems}
-
-For scalar problems, assembling $\hat A^K$ is relatively simple. With the
-terms introduced above, and for the Laplace equation, this looks as follows:
-\begin{verbatim}
-  local_matrix(i,j) += (fe_values.shape_grad(i,q_point) *
-                        fe_values.shape_grad(j,q_point) *
-                        fe_values.JxW (q_point));
-\end{verbatim}
-This term is placed in the innermost loop, i.e. is performed for all indices
-$i,j$, and all quadrature points \texttt{q\_point}.
-
-For nonsymmetric problems, the order of terms has to be considered, as
-mentioned above. For example, for the advection equation
-\begin{gather*}
-  \beta \cdot \nabla u = f,
-\end{gather*}
-with which the bilinear form
-\begin{gather*}
-  a(u,v) = (\beta \cdot \nabla u, v)_\Omega
-\end{gather*}
-is associated, the local matrix is assembled as
-\begin{verbatim}
-  local_matrix(i,j) += (fe_values.shape_values(i,q_point) *
-                        ( beta * fe_values.shape_grad(j,q_point) ) *
-                        fe_values.JxW (q_point));
-\end{verbatim}
-Here, \texttt{beta} is an object of type \texttt{Tensor<1,dim>}, which
-represents a tensor of rank 1 in \texttt{dim} space dimensions.
-
-Assembling matrices for scalar problems is also shown from a practical
-perspective in many of the example programs of \texttt{deal.II}, where it is
-also demonstrated how to do this for the right hand side vectors. Thus, scalar
-problems are not too interesting, and we now turn to vector-valued problems.
-
-
-
-\section{Vector-valued problems}
-
-Since we need some problems at which we will explain assembling the matrix for
-the vector-valued case, we now briefly introduce two simple equations. The
-first are the Lam\'e equations of elasticity, which are taken for the symmetric
-case, then we briefly introduce the Stokes equations as a nonsymmetric problem.
-
-\subsection{The elastic equations}
-\label{sec:elastic}
-
-As first example for the methods we are going to discuss for vector-valued
-problems, we consider the elastic Lam\'e equations for isotropic materials,
-which read in strong form:
-$$
-   -
-   \nabla (\lambda+\mu) (\div \vec u)
-   -
-   (\nabla \cdot \mu \nabla) \vec u
-   =
-   \vec f.
-$$
-These equations describe the three-dimensional deformation $\vec u$ of an
-elastic body under a body force $\vec f$. The respective bilinear form
-associated with this operator is then
-$$
-  a(\vec u, \vec v) =
-  \left(
-    (\lambda+\mu) \div \vec u, \div \vec v
-  \right)_\Omega
-  +
-  \sum_k
-  \left(
-    \mu \nabla u_k, \nabla v_k
-  \right)_\Omega,
-$$
-or as a sum over components:
-$$
-  a(\vec u, \vec v) =
-  \sum_{k,l}
-  \left(
-    (\lambda+\mu) \partial_l u_l, \partial_k v_k
-  \right)_\Omega
-  +
-  \sum_{k,l}
-  \left(
-    \mu \partial_l u_k, \partial_l v_k
-  \right)_\Omega.
-$$
-
-When assembling matrices, it is advantageous to write the weak form
-(i.e. after integration by parts) as a kind of operator. This is since matrix
-elements after discretization are defined as
-\begin{gather*}
-  A_{ij} = a(\varphi_j,\varphi_i)_\Omega,
-\end{gather*}
-where $\varphi_i,\varphi_j$ are two vector-valued trial functions, and it
-would be nice if we could write the bilinear form $a(\cdot,\cdot)$ as a kind
-of scalar product $(\varphi_i, Q \varphi_j)$, where $Q$ is a differential
-operator. This is trivial if we take $Q$ as the operator of the strong form,
-$Q=-\nabla (\lambda+\mu) \div - (\nabla \cdot \mu \nabla)$, but we wanted to
-do this for the weak form. For this, we introduce some notation that is used
-in quantum field theory: for differential operators, we indicate by an arrow
-placed atop of it whether it shall act on the object to the left or to the
-right of it. Thus, 
-$\varphi \overleftarrow\nabla \cdot \overrightarrow\nabla \psi
-=(\nabla\varphi)\cdot(\nabla\psi)$. With this, a simple computation shows 
-that 
-\begin{multline*}
-  a(\vec u,\vec v)
-  =
-  (\lambda+\mu)
-  \left(
-    \begin{pmatrix}
-      u_1 \\ u_2
-    \end{pmatrix}
-    \mid
-    \begin{pmatrix}
-      \leftpartial_1 \rightpartial_1 &
-      \leftpartial_1 \rightpartial_2 \\
-      \leftpartial_2 \rightpartial_1 &
-      \leftpartial_2 \rightpartial_2
-    \end{pmatrix}
-    \mid
-    \begin{pmatrix}
-      v_1 \\ v_2
-    \end{pmatrix}
-  \right)_\Omega
-  \\
-  +
-  \mu
-  \left(
-    \begin{pmatrix}
-      u_1 \\ u_2
-    \end{pmatrix}
-    \mid
-    \left(
-      \leftpartial_1 \rightpartial_1 + 
-      \leftpartial_2 \rightpartial_2
-    \right)
-    \begin{pmatrix}
-      1 & 0 \\
-      0 & 1
-    \end{pmatrix}
-    \mid
-    \begin{pmatrix}
-      v_1 \\ v_2
-    \end{pmatrix}
-  \right)_\Omega.
-\end{multline*}
-The sought operator $Q$ is then
-\begin{gather*}
-  Q
-  =
-  (\lambda+\mu)
-  \begin{pmatrix}
-    \leftpartial_1 \rightpartial_1 &
-    \leftpartial_1 \rightpartial_2 \\
-    \leftpartial_2 \rightpartial_1 &
-    \leftpartial_2 \rightpartial_2
-  \end{pmatrix}
-  +
-  \mu
-  \begin{pmatrix}
-    \leftpartial_1 \rightpartial_1 + 
-    \leftpartial_2 \rightpartial_2 & 0 \\
-    0 & \leftpartial_1 \rightpartial_1 + 
-    \leftpartial_2 \rightpartial_2
-  \end{pmatrix},
-\end{gather*}
-and $a(\vec u,\vec v)=(\vec u | Q | \vec v)$. We demonstrate the fact that $Q$
-acts to both sides by placing it in the middle of the scalar product, just as
-in the bra-ket notation of quantum physics. 
-
-The advantages of this formulation will become clear when discussing
-assembling matrices below. For now, we remark that the symmetry of the weak
-form is equally apparent from the form of $Q$ as well as from the initial
-definition of $a(\cdot,\cdot)$.
-
-
-
-\subsection{The Stokes equations}
-\label{sec:stokes}
-
-For a nonsymmetric problem, we take the Stokes equations: 
-\begin{align*}
-  -\Delta \vec u + \nabla p &= 0,
-  \\
-  \text{div } \vec u &= 0.
-\end{align*}
-We denote by $\vec w=\{\vec u,p\}$ the entire solution vector. In the weak
-form, the above equations read
-\begin{gather*}
-  a(\vec u,p; \vec v, q)
-  =
-  \nu(\nabla \vec u_1, \nabla \vec v_1)
-  +\nu(\nabla \vec u_2, \nabla \vec v_2)
-  - (p, \nabla\cdot \vec v)
-  + (\nabla\cdot\vec u, q).
-\end{gather*}
-Since we integrated the gradient term in the first equation by parts, but not
-the divergence term in the second equation, the problem is now
-nonsymmetric. If we would have liked, we could have made the problem symmetric
-again by multiplying the entire second equation by $-1$, but we don't want to
-do that for now for illustrational purposes.
-
-Again, we introduce the operator $Q$ for this problem, which after some
-computations turns out to be
-\begin{gather*}
-  Q
-  =
-  \begin{pmatrix}
-    \nu(\leftpartial_1 \rightpartial_1 +
-    \leftpartial_2 \rightpartial_2)     & 0 & -\leftpartial_1 \\
-    0 & \nu(\leftpartial_1 \rightpartial_1 +
-        \leftpartial_2 \rightpartial_2) & -\leftpartial_2 \\
-    \rightpartial_1 & \rightpartial_2 & 0
-  \end{pmatrix}.
-\end{gather*}
-Again, it is clear from this form that we could have made the operator
-symmetric by multiplying the last row by $-1$. Note when checking the symmetry
-of $Q$ that taking the transpose of such an operator means reverting the
-directions of the arrows over the operators, and exchanging their order.
-For example, using the first term, these two steps are 
-$\leftpartial_1 \rightpartial_1 \rightarrow \rightpartial_1 \leftpartial_1
-\rightarrow \leftpartial_1 \rightpartial_1$.
-
-
-\section{Assembling vector-valued problems: The simple case}
-
-The simple case in assembling vector-valued problems is when the (also
-vector-valued) shape functions are chosen such that only one component in the
-vector is nonzero. This is usually the case, if we choose the shape functions
-to be the outer product of scalar shape functions, such as independent
-bilinear ansatz spaces for each component of a finite element space.
-
-In this case, each shape function $\Phi_i$ has the representation
-\begin{gather*}
-  \Phi_i(\vec x) = 
-  \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,
-\end{gather*}
-where $\Phi_i$ is the vector-valued shape function, and $\varphi_i$ its
-only non-zero component. Let us denote by $c(i)$ the index of this non-zero
-component, then $\Phi_i$ can also be written as 
-\begin{gather*}
-  \left(\Phi_i(\vec x)\right)_l
-  =
-  \varphi_i(\vec x) \delta_{c(i),l},
-\end{gather*}
-with the Kronecker delta function $\delta_{jk}$.
-
-With this simple form, the cell matrix on cell $K$ has a simple form:
-\begin{gather*}
-  A^K_{ij}
-  =
-  a_K(\Phi_i,\Phi_j)
-  =
-  \left(\Phi_i \mid Q \mid \Phi_j \right)_K
-  =
-  \left(\varphi_i \mid Q_{c(i),c(j)} \mid \varphi_j \right)_K.
-\end{gather*}
-Thus, in assembling the local cell matrices, we only have to determine the
-single components in which the two shape functions are non-zero, and 
-pick one element from the matrix $Q$ to assemble each entry of the cell
-matrix with the help of the values of the functions $\varphi_i$ at the
-quadrature points. Here, it comes handy that we have written the operator as a
-matrix operator $Q$, since this makes it very clear how shape functions $i$
-and $j$ couple: if $Q_{c(i),c(j)}$ is zero, then they do not couple at all for
-this operator. Otherwise, it is easily visible which derivative acts on which
-shape function for this combination of shape functions.
-
-In \texttt{deal.II}, these two actions mentioned above (getting the non-zero
-component of a shape function, and the value of this component at a given
-quadrature point) are done as follows:
-\begin{itemize}
-\item \textit{Determining the non-zero component:} Given the shape function
-  with number $i$ (i.e. its index local to the degrees of freedom on the
-  present cell), its only non-zero component is obtained by the function call 
-\begin{verbatim}
-  const unsigned int nonzero_component_i
-     = fe.system_to_component_index(i).first;
-\end{verbatim}
-  The \texttt{FiniteElement::system\_to\_component\_index} returns a pair of
-  numbers for each index $0\le i < N_K$, the first of which denotes the only
-  non-zero component of the shape function $i$. Since for the case described
-  in this section, the individual components of the vector-valued finite
-  element are independent, we consider each component as a set of scalar shape
-  functions; the second number of the pair returned by the function then
-  denotes the index of the shape function $\varphi_i$ within the shape
-  functions corresponding to this component.
-  
-  If, for example, our finite element in use is a $Q^2/Q^2/Q^1$ combination
-  (for example for 2d flow computations: bi-quadratic ansatz functions for the
-  velocities, bi-linear for the pressure), then we have a total of 22 shape
-  functions (9+9+4). For each $0\le i < 22$, the first part of the pair
-  returned by the function described above, $c(i)$, may then either be 0, 1,
-  or 2, denoting the three possible components of the finite element. If
-  $c(i)$ is either 0 or 1, then the component to which the shape function $i$
-  belongs is a bi-quadratic one, and the second index is between $0$ and $8$
-  (inclusive) as the $Q^2$ element has 9 shape functions. If $c(i)==2$, then
-  the second part is between 0 and 3 (inclusive).
-
-\item \textit{Getting the value of $\varphi_i(\vec x_q)$:} Since only one
-  component of $\Phi_i$ is non-zero, we can use the same function as before,
-  i.e. \texttt{FEValues::shape\_value(i,q)}, which in the scalar case returned
-  the value of shape function $i$ at quadrature point $q$. Likewise, the 
-  \texttt{FEValues::shape\_grad(i,q)} function returns the gradient of this
-  particular component.
-
-  In other words, whether the finite element is scalar or not, the two
-  indicated functions return value and gradient of the only non-zero component
-  of a shape function. If the finite element is scalar, then it is of course
-  clear which component this is (since there $c(i)==0$ for all valid indices
-  $i$), in the vector-valued case, it is component $c(i)$.
-\end{itemize}
-
-
-\subsection{The elastic equations}
-\label{sec:elastic-simple}
-
-With this, and the definition of the ``bi-directional'' operator $Q$ in
-Section~\ref{sec:elastic}, the local matrix assembly function for the elastic
-equations would then read as follows:
-\begin{verbatim}
-  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
-    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
-      for (unsigned int q=0; q<n_q_points; ++q) 
-        {
-          const unsigned int
-            comp_i = fe.system_to_component_index(i).first,
-            comp_j = fe.system_to_component_index(j).first;
-
-                           // first assemble part with lambda+mu
-          cell_matrix(i,j) += ((lambda+mu)                       *
-                               fe_values.shape_grad(i,q)[comp_i] * 
-                               fe_values.shape_grad(j,q)[comp_j] *
-                               fe_values.JxW(q)); 
-
-                           // then part with mu only
-          if (comp_i == comp_j)
-            cell_matrix(i,j) += (mu                           *
-                                 (fe_values.shape_grad(i,q) * 
-                                  fe_values.shape_grad(j,q)  )*
-                                 fe_values.JxW(q)); 
-        };
-\end{verbatim}
-Note that this code works in any space dimension, not only for
-\texttt{dim==2}. Optimization of this is possible by hoisting the computation
-of \texttt{comp\_i} and \texttt{comp\_j}, denoting $c(i)$ and $c(j)$,
-respectively, out of the inner loops. Also, if the coefficients are
-non-constant, they need to be computed at each quadrature point; this may be
-done using this fragment in the innermost loop:
-\begin{verbatim}
-  const double
-    lambda_value = lambda.value(fe_values.quadrature_point(q)),
-    mu_value     = mu.value(fe_values.quadrature_point(q));
-\end{verbatim}
-assuming that \texttt{lambda,mu} are variables of classes describing space
-dependent functions, and which are derived
-from the \texttt{Function<dim>} class.
-
-
-\subsection{The Stokes equations}
-\label{sec:stokes-simple}
-
-For the Stokes equation, things are slightly more complicated since the three
-components denote different quantities, and the operator $Q$ does not have
-such a simple form, but the case is still simple enough. We present its
-generalization to an arbitrary number of space dimensions, i.e. assume that
-there are \texttt{dim} velocity variables and one scalar pressure:
-\begin{verbatim}
-  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
-    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
-      for (unsigned int q=0; q<n_q_points; ++q) 
-        {
-          const unsigned int
-            comp_i = fe.system_to_component_index(i).first,
-            comp_j = fe.system_to_component_index(j).first;
-
-                           // velocity-velocity coupling?
-          if ((comp_i<dim) && (comp_j<dim))
-            if (comp_i == comp_j)
-              cell_matrix(i,j) += (nu *
-                                   (fe_values.shape_grad(i,q) * 
-                                    fe_values.shape_grad(j,q)  ) *
-                                   fe_values.JxW(q)); 
-
-                           // velocity-pressure coupling
-          if ((comp_i<dim) && (comp_j==dim))
-            cell_matrix(i,j) += (-fe_values.shape_grad(i,q)[comp_i] * 
-                                  fe_values.shape_value(j,q)        *
-                                 fe_values.JxW(q)); 
-
-                           // pressure-velocity coupling
-          if ((comp_i==dim) && (comp_j<dim))
-            cell_matrix(i,j) += (fe_values.shape_value(i,q) * 
-                                 fe_values.shape_grad(j,q)[comp_j] *
-                                 fe_values.JxW(q)); 
-        };
-\end{verbatim}
-Again, optimization is possible by observing that only one of the outer
-\texttt{if}s in the body can be true, for example using \texttt{else} clauses,
-or \texttt{break} statements.
-
-
-\section{Assembling vector-valued problems: The complicated case}
-
-The more complicated case is when more than one component of a vector-valued
-shape function is non-zero, i.e. the representation
-\begin{gather*}
-  \Phi_i(\vec x) = 
-  \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,
-\end{gather*}
-does not hold any more. The usual case where this happens is when shape
-functions have to satisfy certain constraints, such as that they should have
-zero divergence or curl, or when the normal fluxes at some points, e.g. the
-face centers, are the degrees of freedom: 
-$\vec n\cdot \Phi_i(x_a) = \delta_{ia}$. In this case, the individual
-components of a shape function are no more independent, and thus cannot be
-chosen such that only one component is non-zero.
-
-What happens in this case? First, the function
-\texttt{FiniteElement::system\_\-to\_\-component\_\-index} does not make much sense
-any more, since a shape function $\Phi_i$ cannot be associated with only one
-vector component any more. Calling this function for basis functions $\Phi_i$
-that are not restricted to only one non-zero component will thus yield an
-exception being thrown.
-
-Second, the functions \texttt{FEValues::shape\_value} and
-\texttt{FEValues::shape\_grad} returning the values and gradients of the only
-non-zero component of a shape function at a quadrature point cannot work any
-more, since there are now more than only one non-zero components for some or
-all values of $i$. For those shape function for which this holds, you will
-again get an exception upon calling these functions.
-
-
-\subsubsection*{Getting information about shape functions}
-
-So how do you find out whether calling these functions is ok or not? In other
-words, how do you know whether shape function $\Phi_i$ has only one non-zero
-component, or more? For this, there are two functions:
-\texttt{FiniteElement::is\_primitive(i)} returns as a \texttt{bool} whether
-the shape function has only one non-zero component. For example, for a
-$Q^2/Q^2/Q^1$ element, this would be \texttt{true} for all 22 shape functions.
-For a finite element for which every shape function is non-zero in more than
-one component, it would be \texttt{false} for all indices $i$. It might also
-be \texttt{true} for only some shape functions, for example if the velocity
-components of the Stokes discretization are done using some more complicated
-element, but the pressure component with a $Q^1$, then it would be
-\texttt{true} for the pressure shape functions, but \texttt{false} otherwise.
-
-Second, the \texttt{FiniteElement::n\_nonzero\_components(i)} function returns
-in how many components the $i$th shape function is non-zero. Again, for the
-$Q^2/Q^2/Q^1$ combination, this would yield the value 1 for all allowed
-indices $i$. For coupled elements, it would be greater than 1.
-
-Third, you may sometimes want to know in which components a certain shape
-function is non-zero. For this, the
-\texttt{FiniteElement::get\_nonzero\_components(i)} function is the right thing: it
-returns a reference to a vector of boolean values, one for each component of
-the vector-valued finite element, and the values indicate whether the shape
-function is non-zero for each of them.
-
-Note that if you have the result of
-\texttt{FiniteElement::get\_\-nonzero\_\-components(i)}, then the result of
-\texttt{FiniteElement::n\_nonzero\_components(i)} is simply the number of
-\texttt{true} values in the array returned by the first function. In the same
-way,
-\texttt{FiniteElement::\-is\_primitive(i)} is simply whether
-\texttt{FiniteElement::\-n\_nonzero\_\-components(i)} returned a value other than
-1. The functions are thus redundant in some way, but useful nevertheless. Of
-course, the values of the  \texttt{FiniteElement::\-is\_primitive(i)}
-and  \texttt{FiniteElement::n\_nonzero\_components(i)} functions are not
-recomputed every time based on the result of some other function, but are
-cached once at the time of construction of a finite element object.
-
-
-\subsubsection*{Evaluating shape functions}
-
-Now, we have seen which functions cannot be called for non-primitive shape
-functions, and also how to find out about shape functions and whether they are
-primitive and the like. Yet, we don't have replacements for the functions that
-cannot be called, so here they are: instead of \texttt{FEValues::shape\_value}
-and \texttt{FEValues::shape\_grad}, call
-\texttt{FEValues::shape\_value\_component} and
-\texttt{FEValues::shape\_grad\_component}. These functions take as arguments
-first the number of the shape function, and second the number of the
-quadrature point (these are also the arguments of the original functions), but
-now as additional third argument the vector component.
-
-Of course, these functions can be called on primitive shape functions as
-well. In that case, the following holds:
-\begin{itemize}
-\item The value of \texttt{FEValues::shape\_value\_component(i,q,c)} is equal
-  to \texttt{FEValues::\-shape\_value(i,q)} if and only if the component
-  \texttt{c} is equal to \texttt{fe.system\_to\_\-component\_\-index(i).first},
-  i.e. if \texttt{c} is the only non-zero component of the shape function
-  \texttt{i}.
-\item For all other components \texttt{c}, the returned value of
-  \texttt{FEValues::shape\_\-value\_\-component(i,q,c)} is zero.
-\end{itemize}
-The same of course also holds for
-\texttt{FEValues::shape\_grad\_component(i,q,c)} and
-\texttt{FEValues::shape\_2nd\_derivative\_component(i,q,c)}.
-
-
-\subsection{The elastic equations}
-
-With the above, we can now assemble the matrix for the elastic equation in
-mostly the same way as before. The difference is that for each shape function,
-we have to loop over all components. The code then looks like this (compare
-this with the one in Section~\ref{sec:elastic-simple}):
-\begin{verbatim}
-  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
-   for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
-    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
-     for (unsigned int comp_j=0; comp_j<fe.n_components(); ++comp_j)
-      for (unsigned int q=0; q<n_q_points; ++q) 
-        {
-                       // first assemble part with lambda+mu
-          cell_matrix(i,j)
-             += ((lambda+mu)                       *
-                 fe_values.shape_grad_component(i,q,comp_i)[comp_i] * 
-                 fe_values.shape_grad_component(j,q,comp_j)[comp_j] *
-                 fe_values.JxW(q)); 
-
-                       // then part with mu only
-          if (comp_i == comp_j)
-            cell_matrix(i,j)
-              += (mu                           *
-                  (fe_values.shape_grad_component(i,q,comp_i) * 
-                   fe_values.shape_grad_component(j,q,comp_j)  )*
-                   fe_values.JxW(q)); 
-        };
-\end{verbatim}
-If you dislike this particular order of the loops, you can reorder them as you
-like, as they are independent.
-
-The code as shown above can be optimized. For example, instead of
-unconditionally performing the loop over all components of shape functions $i$
-of $j$, we might first ask whether these shape functions are primitive, using
-\texttt{fe.is\_primitive(i)}, and use the loop only if the result is false;
-if, on the other hand, the result is true, we only need to set
-\texttt{comp\_i} to the fixed value
-\texttt{fe.system\_to\_component\_index(i).first}, and likewise for shape
-function $j$.
-
-Another possibility for optimization would be to ask whether a certain
-component over which we loop is actually non-zero, or if the shape function is
-a non-primitive one but happens to be zero in the present component
-nevertheless. For this, we could replace the loop over \texttt{comp\_i} by
-this:
-\begin{verbatim}
-    for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
-      if (fe.get_nonzero_components(i)[comp_i] == true)
-\end{verbatim}
-If the if-clause does not succeed then this component of the shape function is
-definitely zero, and there will not be a contribution to the matrix anyway, so
-we can also skip the computations.
-
-
-\subsection{The Stokes equations}
-
-Likewise, this is now the code for the Stokes equations:
-\begin{verbatim}
-  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
-   for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
-    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
-     for (unsigned int comp_j=0; comp_j<fe.n_components(); ++comp_j)
-      for (unsigned int q=0; q<n_q_points; ++q) 
-        {
-                       // velocity-velocity coupling?
-          if ((comp_i<dim) && (comp_j<dim))
-            if (comp_i == comp_j)
-              cell_matrix(i,j)
-                  += (nu *
-                      (fe_values.shape_grad_component(i,q,comp_i) * 
-                       fe_values.shape_grad_component(j,q,comp_j)  ) *
-                      fe_values.JxW(q)); 
-
-                       // velocity-pressure coupling
-          if ((comp_i<dim) && (comp_j==dim))
-            cell_matrix(i,j)
-                += (-fe_values.shape_grad_component(i,q,comp_i)[comp_i] * 
-                    fe_values.shape_value_component(j,q,comp_j)        *
-                    fe_values.JxW(q)); 
-
-                       // pressure-velocity coupling
-          if ((comp_i==dim) && (comp_j<dim))
-            cell_matrix(i,j)
-                += (fe_values.shape_value_component(i,q,comp_i) * 
-                    fe_values.shape_grad_component(j,q,comp_j)[comp_j] *
-                    fe_values.JxW(q)); 
-        };
-\end{verbatim}
-Again, the same optimizations as above are possible. Here, they even seem
-worthwhile, since it is often the case that the velocity variables are
-discretized using a non-primitive finite element, while the pressure uses a
-primitive element. In that case, some shape functions are primitive (namely
-those discretizing the pressure), and of the non-primitive shape functions
-(those for the velocity variables) some vector components (the pressure
-components) are always zero. Thus, both optimizations described above would be
-useful. We leave the implementation of this to the reader.
-
-
-\section{Conclusions}
-
-We have shown how finite element matrices are assembled using the
-functionality of the \texttt{deal.II} library. For the scalar case, and, in
-the vector-valued case, if the
-finite element shape functions are such that only one vector component of each
-shape function is non-zero, assembling is relatively simple. In the other
-case, when there are shape functions with more than one non-zero component,
-some more care is necessary, but assembling is still straightforward and
-follows the same pattern as before.
-
-\end{document}
diff --git a/deal.II/doc/reports/class-hierarchies/1d-dof.eps b/deal.II/doc/reports/class-hierarchies/1d-dof.eps
deleted file mode 100644 (file)
index f97f3b5..0000000
+++ /dev/null
@@ -1,183 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 1d-dof.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 16:17:22 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 514 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--8.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 9692 -1000 l 9692 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-7.500 slw
-n 3705 1500 m 3600 1500 3600 1770 105 arcto 4 {pop} repeat
-  3600 1875 5895 1875 105 arcto 4 {pop} repeat
-  6000 1875 6000 1605 105 arcto 4 {pop} repeat
-  6000 1500 3705 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 4800 1875 m 2400 2700 l gs col0 s gr 
-% Polyline
-n 2400 3075 m 2400 3900 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 255 1500 m 150 1500 150 1770 105 arcto 4 {pop} repeat
-  150 1875 2145 1875 105 arcto 4 {pop} repeat
-  2250 1875 2250 1605 105 arcto 4 {pop} repeat
-  2250 1500 255 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 1200 1875 m 2400 2700 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 1155 3900 m 1050 3900 1050 4170 105 arcto 4 {pop} repeat
-  1050 4275 3645 4275 105 arcto 4 {pop} repeat
-  3750 4275 3750 4005 105 arcto 4 {pop} repeat
-  3750 3900 1155 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 955 2700 m 850 2700 850 2970 105 arcto 4 {pop} repeat
-  850 3075 3845 3075 105 arcto 4 {pop} repeat
-  3950 3075 3950 2805 105 arcto 4 {pop} repeat
-  3950 2700 955 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 1-dimensional Case, Part 2) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-4800 1800 m
-gs 1 -1 sc (DoFAccessor<1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-1200 1800 m
-gs 1 -1 sc (CellAccessor<1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-2400 3000 m
-gs 1 -1 sc (DoFObjectAccessor<1,1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-2400 4200 m
-gs 1 -1 sc (DoFCellAccessor<1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/1d-dof.fig b/deal.II/doc/reports/class-hierarchies/1d-dof.fig
deleted file mode 100644 (file)
index 6d1e056..0000000
+++ /dev/null
@@ -1,28 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6000 1875 6000 1500 3600 1500 3600 1875 6000 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 2400 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        2400 3075 2400 3900
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        2250 1875 2250 1500 150 1500 150 1875 2250 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        1200 1875 2400 2700
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3750 4275 3750 3900 1050 3900 1050 4275 3750 4275
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3950 3075 850 3075 850 2700 3950 2700 3950 3075
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 1-dimensional Case, Part 2\001
-4 1 0 0 0 0 20 0.0000 4 195 1995 4800 1800 DoFAccessor<1>\001
-4 1 0 0 0 0 20 0.0000 4 195 1950 1200 1800 CellAccessor<1>\001
-4 1 0 0 0 0 20 0.0000 4 255 2940 2400 3000 DoFObjectAccessor<1,1>\001
-4 1 0 0 0 0 20 0.0000 4 195 2460 2400 4200 DoFCellAccessor<1>\001
diff --git a/deal.II/doc/reports/class-hierarchies/1d-dof.jpg b/deal.II/doc/reports/class-hierarchies/1d-dof.jpg
deleted file mode 100644 (file)
index d443b95..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/1d-dof.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/1d-tria.eps b/deal.II/doc/reports/class-hierarchies/1d-tria.eps
deleted file mode 100644 (file)
index 5670f0c..0000000
+++ /dev/null
@@ -1,170 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 1d-tria.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 15:49:56 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 513 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--9.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 9692 -1000 l 9692 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-7.500 slw
-n 3705 1500 m 3600 1500 3600 1770 105 arcto 4 {pop} repeat
-  3600 1875 5895 1875 105 arcto 4 {pop} repeat
-  6000 1875 6000 1605 105 arcto 4 {pop} repeat
-  6000 1500 3705 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 4800 1875 m 1800 2700 l gs col0 s gr 
-% Polyline
-n 1800 3075 m 1800 3900 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 280 2700 m 175 2700 175 2970 105 arcto 4 {pop} repeat
-  175 3075 3345 3075 105 arcto 4 {pop} repeat
-  3450 3075 3450 2805 105 arcto 4 {pop} repeat
-  3450 2700 280 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 755 3900 m 650 3900 650 4170 105 arcto 4 {pop} repeat
-  650 4275 2845 4275 105 arcto 4 {pop} repeat
-  2950 4275 2950 4005 105 arcto 4 {pop} repeat
-  2950 3900 755 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-4800 1800 m
-gs 1 -1 sc (TriaAccessor<1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 1-dimensional Case, Part 1) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-1800 3000 m
-gs 1 -1 sc (TriaObjectAccessor<1,1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-1800 4200 m
-gs 1 -1 sc (CellAccessor<1>) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/1d-tria.fig b/deal.II/doc/reports/class-hierarchies/1d-tria.fig
deleted file mode 100644 (file)
index 3f46e3c..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6000 1875 6000 1500 3600 1500 3600 1875 6000 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 1800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        1800 3075 1800 3900
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3450 3075 175 3075 175 2700 3450 2700 3450 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        2950 4275 650 4275 650 3900 2950 3900 2950 4275
-4 1 0 0 0 0 20 0.0000 4 195 1980 4800 1800 TriaAccessor<1>\001
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 1-dimensional Case, Part 1\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 1800 3000 TriaObjectAccessor<1,1>\001
-4 1 0 0 0 0 20 0.0000 4 195 1950 1800 4200 CellAccessor<1>\001
diff --git a/deal.II/doc/reports/class-hierarchies/1d-tria.jpg b/deal.II/doc/reports/class-hierarchies/1d-tria.jpg
deleted file mode 100644 (file)
index c074ca3..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/1d-tria.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/2d-dof.eps b/deal.II/doc/reports/class-hierarchies/2d-dof.eps
deleted file mode 100644 (file)
index 6d185a7..0000000
+++ /dev/null
@@ -1,203 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 2d-dof.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 16:24:04 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 560 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--8.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 10462 -1000 l 10462 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-15.000 slw
-n 6825 3075 m 6825 3900 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 5380 2700 m 5275 2700 5275 2970 105 arcto 4 {pop} repeat
-  5275 3075 8270 3075 105 arcto 4 {pop} repeat
-  8375 3075 8375 2805 105 arcto 4 {pop} repeat
-  8375 2700 5380 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 5580 3900 m 5475 3900 5475 4170 105 arcto 4 {pop} repeat
-  5475 4275 8070 4275 105 arcto 4 {pop} repeat
-  8175 4275 8175 4005 105 arcto 4 {pop} repeat
-  8175 3900 5580 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-6825 3000 m
-gs 1 -1 sc (DoFObjectAccessor<2,2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-6825 4200 m
-gs 1 -1 sc (DoFCellAccessor<2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 1480 2700 m 1375 2700 1375 2970 105 arcto 4 {pop} repeat
-  1375 3075 4370 3075 105 arcto 4 {pop} repeat
-  4475 3075 4475 2805 105 arcto 4 {pop} repeat
-  4475 2700 1480 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-2925 3000 m
-gs 1 -1 sc (DoFObjectAccessor<1,2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 3705 1500 m 3600 1500 3600 1770 105 arcto 4 {pop} repeat
-  3600 1875 5895 1875 105 arcto 4 {pop} repeat
-  6000 1875 6000 1605 105 arcto 4 {pop} repeat
-  6000 1500 3705 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 7455 1500 m 7350 1500 7350 1770 105 arcto 4 {pop} repeat
-  7350 1875 9345 1875 105 arcto 4 {pop} repeat
-  9450 1875 9450 1605 105 arcto 4 {pop} repeat
-  9450 1500 7455 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 255 1500 m 150 1500 150 1770 105 arcto 4 {pop} repeat
-  150 1875 3045 1875 105 arcto 4 {pop} repeat
-  3150 1875 3150 1605 105 arcto 4 {pop} repeat
-  3150 1500 255 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 4800 1875 m 2800 2700 l gs col0 s gr 
-% Polyline
-n 1200 1875 m 2800 2700 l gs col0 s gr 
-% Polyline
-n 4800 1875 m 6800 2700 l gs col0 s gr 
-% Polyline
-n 8400 1875 m 6800 2700 l gs col0 s gr 
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 2-dimensional Case, Part 2) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-4800 1800 m
-gs 1 -1 sc (DoFAccessor<2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-8400 1800 m
-gs 1 -1 sc (CellAccessor<2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-1650 1800 m
-gs 1 -1 sc (TriaObjectAccessor<1,2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/2d-dof.fig b/deal.II/doc/reports/class-hierarchies/2d-dof.fig
deleted file mode 100644 (file)
index ba45b2c..0000000
+++ /dev/null
@@ -1,42 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-6 5250 2700 8400 4275
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        6825 3075 6825 3900
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        8375 3075 5275 3075 5275 2700 8375 2700 8375 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        8175 4275 8175 3900 5475 3900 5475 4275 8175 4275
-4 1 0 0 0 0 20 0.0000 4 255 2940 6825 3000 DoFObjectAccessor<2,2>\001
-4 1 0 0 0 0 20 0.0000 4 195 2460 6825 4200 DoFCellAccessor<2>\001
--6
-6 1350 2700 4500 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        4475 3075 1375 3075 1375 2700 4475 2700 4475 3075
-4 1 0 0 0 0 20 0.0000 4 255 2940 2925 3000 DoFObjectAccessor<1,2>\001
--6
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6000 1875 6000 1500 3600 1500 3600 1875 6000 1875
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9450 1875 9450 1500 7350 1500 7350 1875 9450 1875
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3150 1875 150 1875 150 1500 3150 1500 3150 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 2800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        1200 1875 2800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 6800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        8400 1875 6800 2700
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 2-dimensional Case, Part 2\001
-4 1 0 0 0 0 20 0.0000 4 195 1995 4800 1800 DoFAccessor<2>\001
-4 1 0 0 0 0 20 0.0000 4 195 1950 8400 1800 CellAccessor<2>\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 1650 1800 TriaObjectAccessor<1,2>\001
diff --git a/deal.II/doc/reports/class-hierarchies/2d-dof.jpg b/deal.II/doc/reports/class-hierarchies/2d-dof.jpg
deleted file mode 100644 (file)
index caf1cc2..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/2d-dof.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/2d-tria.eps b/deal.II/doc/reports/class-hierarchies/2d-tria.eps
deleted file mode 100644 (file)
index ec95b92..0000000
+++ /dev/null
@@ -1,181 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 2d-tria.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 15:59:56 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 552 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--15.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 10437 -1000 l 10437 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-7.500 slw
-n 3705 1500 m 3600 1500 3600 1770 105 arcto 4 {pop} repeat
-  3600 1875 5895 1875 105 arcto 4 {pop} repeat
-  6000 1875 6000 1605 105 arcto 4 {pop} repeat
-  6000 1500 3705 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 4800 1875 m 1800 2700 l gs col0 s gr 
-% Polyline
-n 4800 1875 m 7800 2700 l gs col0 s gr 
-% Polyline
-n 7800 3075 m 7800 3900 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 6855 3900 m 6750 3900 6750 4170 105 arcto 4 {pop} repeat
-  6750 4275 8745 4275 105 arcto 4 {pop} repeat
-  8850 4275 8850 4005 105 arcto 4 {pop} repeat
-  8850 3900 6855 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 380 2700 m 275 2700 275 2970 105 arcto 4 {pop} repeat
-  275 3075 3245 3075 105 arcto 4 {pop} repeat
-  3350 3075 3350 2805 105 arcto 4 {pop} repeat
-  3350 2700 380 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 6330 2700 m 6225 2700 6225 2970 105 arcto 4 {pop} repeat
-  6225 3075 9320 3075 105 arcto 4 {pop} repeat
-  9425 3075 9425 2805 105 arcto 4 {pop} repeat
-  9425 2700 6330 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-4800 1800 m
-gs 1 -1 sc (TriaAccessor<2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 2-dimensional Case, Part 1) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-1800 3000 m
-gs 1 -1 sc (TriaObjectAccessor<1,2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-7800 3000 m
-gs 1 -1 sc (TriaObjectAccessor<2,2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-7800 4200 m
-gs 1 -1 sc (CellAccessor<2>) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/2d-tria.fig b/deal.II/doc/reports/class-hierarchies/2d-tria.fig
deleted file mode 100644 (file)
index b5276f0..0000000
+++ /dev/null
@@ -1,28 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6000 1875 6000 1500 3600 1500 3600 1875 6000 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 1800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        4800 1875 7800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        7800 3075 7800 3900
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        8850 4275 8850 3900 6750 3900 6750 4275 8850 4275
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3350 3075 275 3075 275 2700 3350 2700 3350 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9425 3075 6225 3075 6225 2700 9425 2700 9425 3075
-4 1 0 0 0 0 20 0.0000 4 195 1980 4800 1800 TriaAccessor<2>\001
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 2-dimensional Case, Part 1\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 1800 3000 TriaObjectAccessor<1,2>\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 7800 3000 TriaObjectAccessor<2,2>\001
-4 1 0 0 0 0 20 0.0000 4 195 1950 7800 4200 CellAccessor<2>\001
diff --git a/deal.II/doc/reports/class-hierarchies/2d-tria.jpg b/deal.II/doc/reports/class-hierarchies/2d-tria.jpg
deleted file mode 100644 (file)
index 93a7c4d..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/2d-tria.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/3d-dof.eps b/deal.II/doc/reports/class-hierarchies/3d-dof.eps
deleted file mode 100644 (file)
index 7dffc7b..0000000
+++ /dev/null
@@ -1,219 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 3d-dof.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 16:33:48 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 592 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--12.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 11062 -1000 l 11062 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-15.000 slw
-n 1500 1125 m 1875 2700 l 6525 1875 l gs col0 s gr 
-% Polyline
-n 3375 1575 m 5250 2700 l 6525 1875 l gs col0 s gr 
-% Polyline
-n 6525 1875 m 8400 2700 l 8925 1350 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 5430 1500 m 5325 1500 5325 1770 105 arcto 4 {pop} repeat
-  5325 1875 7620 1875 105 arcto 4 {pop} repeat
-  7725 1875 7725 1605 105 arcto 4 {pop} repeat
-  7725 1500 5430 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-6525 1800 m
-gs 1 -1 sc (DoFAccessor<3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 330 750 m 225 750 225 1020 105 arcto 4 {pop} repeat
-  225 1125 3120 1125 105 arcto 4 {pop} repeat
-  3225 1125 3225 855 105 arcto 4 {pop} repeat
-  3225 750 330 750 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-1725 1050 m
-gs 1 -1 sc (TriaObjectAccessor<1,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 2130 1200 m 2025 1200 2025 1470 105 arcto 4 {pop} repeat
-  2025 1575 4920 1575 105 arcto 4 {pop} repeat
-  5025 1575 5025 1305 105 arcto 4 {pop} repeat
-  5025 1200 2130 1200 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-3525 1500 m
-gs 1 -1 sc (TriaObjectAccessor<1,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 8055 975 m 7950 975 7950 1245 105 arcto 4 {pop} repeat
-  7950 1350 9945 1350 105 arcto 4 {pop} repeat
-  10050 1350 10050 1080 105 arcto 4 {pop} repeat
-  10050 975 8055 975 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-9000 1275 m
-gs 1 -1 sc (CellAccessor<3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-% Polyline
-n 3805 2700 m 3700 2700 3700 2970 105 arcto 4 {pop} repeat
-  3700 3075 6695 3075 105 arcto 4 {pop} repeat
-  6800 3075 6800 2805 105 arcto 4 {pop} repeat
-  6800 2700 3805 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 580 2700 m 475 2700 475 2970 105 arcto 4 {pop} repeat
-  475 3075 3470 3075 105 arcto 4 {pop} repeat
-  3575 3075 3575 2805 105 arcto 4 {pop} repeat
-  3575 2700 580 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 6980 2700 m 6875 2700 6875 2970 105 arcto 4 {pop} repeat
-  6875 3075 9870 3075 105 arcto 4 {pop} repeat
-  9975 3075 9975 2805 105 arcto 4 {pop} repeat
-  9975 2700 6980 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 7155 3900 m 7050 3900 7050 4170 105 arcto 4 {pop} repeat
-  7050 4275 9645 4275 105 arcto 4 {pop} repeat
-  9750 4275 9750 4005 105 arcto 4 {pop} repeat
-  9750 3900 7155 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 8400 3075 m 8400 3900 l gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-2025 3000 m
-gs 1 -1 sc (DoFObjectAccessor<1,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-5250 3000 m
-gs 1 -1 sc (DoFObjectAccessor<2,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-8400 3000 m
-gs 1 -1 sc (DoFObjectAccessor<3,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-8400 4200 m
-gs 1 -1 sc (DoFCellAccessor<3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 3-dimensional Case, Part 2) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/3d-dof.fig b/deal.II/doc/reports/class-hierarchies/3d-dof.fig
deleted file mode 100644 (file)
index fc810f6..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-6 5325 1500 7725 1875
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        7725 1875 7725 1500 5325 1500 5325 1875 7725 1875
-4 1 0 0 0 0 20 0.0000 4 195 1995 6525 1800 DoFAccessor<3>\001
--6
-6 225 750 3225 1125
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3225 1125 225 1125 225 750 3225 750 3225 1125
-4 1 0 0 0 0 20 0.0000 4 255 2925 1725 1050 TriaObjectAccessor<1,3>\001
--6
-6 2025 1200 5025 1575
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        5025 1575 2025 1575 2025 1200 5025 1200 5025 1575
-4 1 0 0 0 0 20 0.0000 4 255 2925 3525 1500 TriaObjectAccessor<1,3>\001
--6
-6 7950 975 10050 1350
-6 7950 975 10050 1350
-6 7950 975 10050 1350
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        10050 1350 10050 975 7950 975 7950 1350 10050 1350
--6
--6
-4 1 0 0 0 0 20 0.0000 4 195 1950 9000 1275 CellAccessor<3>\001
--6
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6800 3075 3700 3075 3700 2700 6800 2700 6800 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3575 3075 475 3075 475 2700 3575 2700 3575 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9975 3075 6875 3075 6875 2700 9975 2700 9975 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9750 4275 9750 3900 7050 3900 7050 4275 9750 4275
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        8400 3075 8400 3900
-2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 3
-        1500 1125 1875 2700 6525 1875
-2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 3
-        3375 1575 5250 2700 6525 1875
-2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 3
-        6525 1875 8400 2700 8925 1350
-4 1 0 0 0 0 20 0.0000 4 255 2940 2025 3000 DoFObjectAccessor<1,3>\001
-4 1 0 0 0 0 20 0.0000 4 255 2940 5250 3000 DoFObjectAccessor<2,3>\001
-4 1 0 0 0 0 20 0.0000 4 255 2940 8400 3000 DoFObjectAccessor<3,3>\001
-4 1 0 0 0 0 20 0.0000 4 195 2460 8400 4200 DoFCellAccessor<3>\001
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 3-dimensional Case, Part 2\001
diff --git a/deal.II/doc/reports/class-hierarchies/3d-dof.jpg b/deal.II/doc/reports/class-hierarchies/3d-dof.jpg
deleted file mode 100644 (file)
index b69962d..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/3d-dof.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/3d-tria.eps b/deal.II/doc/reports/class-hierarchies/3d-tria.eps
deleted file mode 100644 (file)
index 75ea137..0000000
+++ /dev/null
@@ -1,193 +0,0 @@
-%!PS-Adobe-2.0 EPSF-2.0
-%%Title: 3d-tria.eps
-%%Creator: fig2dev Version 3.2 Patchlevel 1
-%%CreationDate: Sun Dec 19 16:06:42 1999
-%%For: wolf@adaptive (Wolfgang Bangerth)
-%%Orientation: Portrait
-%%BoundingBox: 0 0 576 239
-%%Pages: 0
-%%BeginSetup
-%%EndSetup
-%%Magnification: 1.0000
-%%EndComments
-/$F2psDict 200 dict def
-$F2psDict begin
-$F2psDict /mtrx matrix put
-/col-1 {0 setgray} bind def
-/col0 {0.000 0.000 0.000 srgb} bind def
-/col1 {0.000 0.000 1.000 srgb} bind def
-/col2 {0.000 1.000 0.000 srgb} bind def
-/col3 {0.000 1.000 1.000 srgb} bind def
-/col4 {1.000 0.000 0.000 srgb} bind def
-/col5 {1.000 0.000 1.000 srgb} bind def
-/col6 {1.000 1.000 0.000 srgb} bind def
-/col7 {1.000 1.000 1.000 srgb} bind def
-/col8 {0.000 0.000 0.560 srgb} bind def
-/col9 {0.000 0.000 0.690 srgb} bind def
-/col10 {0.000 0.000 0.820 srgb} bind def
-/col11 {0.530 0.810 1.000 srgb} bind def
-/col12 {0.000 0.560 0.000 srgb} bind def
-/col13 {0.000 0.690 0.000 srgb} bind def
-/col14 {0.000 0.820 0.000 srgb} bind def
-/col15 {0.000 0.560 0.560 srgb} bind def
-/col16 {0.000 0.690 0.690 srgb} bind def
-/col17 {0.000 0.820 0.820 srgb} bind def
-/col18 {0.560 0.000 0.000 srgb} bind def
-/col19 {0.690 0.000 0.000 srgb} bind def
-/col20 {0.820 0.000 0.000 srgb} bind def
-/col21 {0.560 0.000 0.560 srgb} bind def
-/col22 {0.690 0.000 0.690 srgb} bind def
-/col23 {0.820 0.000 0.820 srgb} bind def
-/col24 {0.500 0.190 0.000 srgb} bind def
-/col25 {0.630 0.250 0.000 srgb} bind def
-/col26 {0.750 0.380 0.000 srgb} bind def
-/col27 {1.000 0.500 0.500 srgb} bind def
-/col28 {1.000 0.630 0.630 srgb} bind def
-/col29 {1.000 0.750 0.750 srgb} bind def
-/col30 {1.000 0.880 0.880 srgb} bind def
-/col31 {1.000 0.840 0.000 srgb} bind def
-
-end
-save
--15.0 258.0 translate
-1 -1 scale
-
-/cp {closepath} bind def
-/ef {eofill} bind def
-/gr {grestore} bind def
-/gs {gsave} bind def
-/sa {save} bind def
-/rs {restore} bind def
-/l {lineto} bind def
-/m {moveto} bind def
-/rm {rmoveto} bind def
-/n {newpath} bind def
-/s {stroke} bind def
-/sh {show} bind def
-/slc {setlinecap} bind def
-/slj {setlinejoin} bind def
-/slw {setlinewidth} bind def
-/srgb {setrgbcolor} bind def
-/rot {rotate} bind def
-/sc {scale} bind def
-/sd {setdash} bind def
-/ff {findfont} bind def
-/sf {setfont} bind def
-/scf {scalefont} bind def
-/sw {stringwidth} bind def
-/tr {translate} bind def
-/tnt {dup dup currentrgbcolor
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add
-  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
-  bind def
-/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
-  4 -2 roll mul srgb} bind def
-/reencdict 12 dict def /ReEncode { reencdict begin
-/newcodesandnames exch def /newfontname exch def /basefontname exch def
-/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
-basefontdict { exch dup /FID ne { dup /Encoding eq
-{ exch dup length array copy newfont 3 1 roll put }
-{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
-newfont /FontName newfontname put newcodesandnames aload pop
-128 1 255 { newfont /Encoding get exch /.notdef put } for
-newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
-newfontname newfont definefont pop end } def
-/isovec [
-8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
-8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
-8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
-8#220 /dotlessi 8#230 /oe 8#231 /OE
-8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
-8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
-8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
-8#255 /endash 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
-8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
-8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
-8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
-8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
-8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
-8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
-8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
-8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
-8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
-8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
-8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
-8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
-8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
-8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
-8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
-8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
-8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
-8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
-/Times-Roman /Times-Roman-iso isovec ReEncode
-/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
-/$F2psEnd {$F2psEnteredState restore end} def
-%%EndProlog
-
-$F2psBegin
-10 setmiterlimit
-n -1000 5287 m -1000 -1000 l 10837 -1000 l 10837 5287 l cp clip
- 0.06000 0.06000 sc
-% Polyline
-15.000 slw
-n 5100 1875 m 5100 2700 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 380 2700 m 275 2700 275 2970 105 arcto 4 {pop} repeat
-  275 3075 3245 3075 105 arcto 4 {pop} repeat
-  3350 3075 3350 2805 105 arcto 4 {pop} repeat
-  3350 2700 380 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 3480 2700 m 3375 2700 3375 2970 105 arcto 4 {pop} repeat
-  3375 3075 6470 3075 105 arcto 4 {pop} repeat
-  6575 3075 6575 2805 105 arcto 4 {pop} repeat
-  6575 2700 3480 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 6730 2700 m 6625 2700 6625 2970 105 arcto 4 {pop} repeat
-  6625 3075 9720 3075 105 arcto 4 {pop} repeat
-  9825 3075 9825 2805 105 arcto 4 {pop} repeat
-  9825 2700 6730 2700 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-n 4005 1500 m 3900 1500 3900 1770 105 arcto 4 {pop} repeat
-  3900 1875 6195 1875 105 arcto 4 {pop} repeat
-  6300 1875 6300 1605 105 arcto 4 {pop} repeat
-  6300 1500 4005 1500 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-% Polyline
-15.000 slw
-n 5100 1875 m 1800 2700 l gs col0 s gr 
-% Polyline
-n 5100 1875 m 8200 2700 l gs col0 s gr 
-% Polyline
-n 8250 3075 m 8250 3900 l gs col0 s gr 
-% Polyline
-7.500 slw
-n 7305 3900 m 7200 3900 7200 4170 105 arcto 4 {pop} repeat
-  7200 4275 9195 4275 105 arcto 4 {pop} repeat
-  9300 4275 9300 4005 105 arcto 4 {pop} repeat
-  9300 3900 7305 3900 105 arcto 4 {pop} repeat
- cp gs col0 s gr 
-/Times-Roman-iso ff 300.00 scf sf
-1800 3000 m
-gs 1 -1 sc (TriaObjectAccessor<1,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-8250 3000 m
-gs 1 -1 sc (TriaObjectAccessor<3,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-5100 1800 m
-gs 1 -1 sc (TriaAccessor<3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-8250 4200 m
-gs 1 -1 sc (CellAccessor<3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 300.00 scf sf
-5025 3000 m
-gs 1 -1 sc (TriaObjectAccessor<2,3>) dup sw pop 2 div neg 0 rm  col0 sh gr
-/Times-Roman-iso ff 375.00 scf sf
-4800 600 m
-gs 1 -1 sc (Class Hierarchy for the 3-dimensional Case, Part 1) dup sw pop 2 div neg 0 rm  col0 sh gr
-$F2psEnd
-rs
diff --git a/deal.II/doc/reports/class-hierarchies/3d-tria.fig b/deal.II/doc/reports/class-hierarchies/3d-tria.fig
deleted file mode 100644 (file)
index 784a1a4..0000000
+++ /dev/null
@@ -1,33 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
-0
-1200 2
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        3350 3075 275 3075 275 2700 3350 2700 3350 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6575 3075 3375 3075 3375 2700 6575 2700 6575 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9825 3075 6625 3075 6625 2700 9825 2700 9825 3075
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        6300 1875 6300 1500 3900 1500 3900 1875 6300 1875
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        5100 1875 1800 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        5100 1875 8200 2700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2
-        8250 3075 8250 3900
-2 4 0 1 0 7 0 0 -1 0.000 0 0 7 0 0 5
-        9300 4275 9300 3900 7200 3900 7200 4275 9300 4275
-2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2
-        5100 1875 5100 2700
-4 1 0 0 0 0 20 0.0000 4 255 2925 1800 3000 TriaObjectAccessor<1,3>\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 8250 3000 TriaObjectAccessor<3,3>\001
-4 1 0 0 0 0 20 0.0000 4 195 1980 5100 1800 TriaAccessor<3>\001
-4 1 0 0 0 0 20 0.0000 4 195 1950 8250 4200 CellAccessor<3>\001
-4 1 0 0 0 0 20 0.0000 4 255 2925 5025 3000 TriaObjectAccessor<2,3>\001
-4 1 0 0 0 0 25 0.0000 4 345 7590 4800 600 Class Hierarchy for the 3-dimensional Case, Part 1\001
diff --git a/deal.II/doc/reports/class-hierarchies/3d-tria.jpg b/deal.II/doc/reports/class-hierarchies/3d-tria.jpg
deleted file mode 100644 (file)
index 6aa0d0b..0000000
Binary files a/deal.II/doc/reports/class-hierarchies/3d-tria.jpg and /dev/null differ
diff --git a/deal.II/doc/reports/class-hierarchies/index.html b/deal.II/doc/reports/class-hierarchies/index.html
deleted file mode 100644 (file)
index f2c3ac5..0000000
+++ /dev/null
@@ -1,996 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Homepage</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II"></head>
-
-   </head>
-<BODY LINK="#0000ff" VLINK="#800080">
-
-<H1 ALIGN="CENTER">
-Description of the C++ class hierarchy for the
-accessor classes
-</H1>
-
-
-<p ALIGN="CENTER">
-  <strong> Wolfgang Bangerth, 1998, 1999, 2000</strong>
-</p>
-
-
-<p>
-The class hierarchy of the accessor classes used to retrieve and store
-data in the triangulation and degree of freedom handler objects is one
-of  the more complicated parts of  the library. It  makes heavy use of
-class templates with  integers  as template parameters  as  well as of
-explicit specialization  of classes and  member functions.  Therefore,
-it is not so  easy to  see the  connections and  inheritance relations
-within this part of the class tree; this  document tries to shed a bit
-of light onto this.
-</p>
-
-<p>
-Furthermore, it lists the member functions that can be queried to
-obtain information from an iterator.
-</p>
-
-
-<strong>Table of contents</strong>
-<ul>
-  <li> <a href="#intro" target="body">What iterators and accessors
-       are</a> 
-  <li> <a href="#tria-accessors" target="body">The triangulation
-       accessor hierarchy</a> 
-  <li> <a href="#tria-typedefs" target="body">Typedefs of the
-       Triangulation class to iterators and accessors</a>
-  <li> <a href="#tria-functions" target="body">Functions offered by
-       triangulation accessors</a> 
-  <li> <a href="#dof-accessors" target="body">The degree of freedom
-       accessor hierarchy</a> 
-  <li> <a href="#dof-typedefs" target="body">Typedefs of the
-       DoFHandler class to iterators and accessors</a>
-  <li> <a href="#dof-functions" target="body">Functions offered by
-       degree of freedom accessors</a> 
-</ul>
-
-
-<a name="intro"></a>
-<H3>
-What iterators and accessors are
-</H3>
-
-<p>
-When  using  adative finite elements,   the data structures  often are
-extremely complex, requiring   multiply indirected access  and complex
-relationships between  the different places  where data is stored. The
-traditional way  to  handle this is  to  put  all  data which  belongs
-together somehow into  a structure or  object; however, sometimes this
-can  not  be done  efficiently,    leading  to either higher    memory
-consumption (when you have to store many small data pieces and because
-you have to store a lot of pointers to other objects) or higher coding
-requirements (when you want to follow all those pointers to the object
-you desire).
-</p>
-
-<p>
-Therefore, we took  over a concept  which was already  used in the C++
-standard template library, namely iterators and accessors. An accessor
-is an object that looks like if it  had all the information stored but
-really only delegates the access to the right  places; in fact, within
-this library, accessor store almost  no information but know where  to
-get   everything   from the complex  and   nested  data structures the
-triangulation object offers. They have a simple interface which allows
-to     extract any desired   information   from  the triangulation and
-therefore makes access  much easier and safer in  three ways: first it
-performs range and parameter checking  when in debugging mode; second,
-it encapsulates the access to the real data  from the user, hiding the
-true data structures and thus allowing  them without changing the user
-programs as well as those parts of the  library which only act through
-accessors; and third by reducing the coding  errors because of reduced
-complexity, since the chains of indirect access are replaces by simple
-commands.
-</p>
-
-<p>
-Iterators are a  related concept: while  accessors act as if they were
-structures with data contained in them, iterators act  as if they were
-pointers pointing to   accessors. You can  dereference  them using the
--&gt; and * operators  as with any  other pointer, but they have  more
-functionality. Essentially, they  have overloaded ++ and -- operators,
-which  allow the next  or previous object  pointed to to be just about
-anywhere  in memory. A good introductory  example are the iterators of
-the STL  <CODE>list&lt;T&gt;</CODE> class, which  act on a linked list
-as if it  were a contiguous  array. The  iterators in  this library go
-even a step further: they do not point to different objects but rather
-tell  the   associated  accessor   object which   data   to  look   at
-next.
-</p>
-
-<p>
-Additionally, there  are different  versions  of the   iterators which
-behave  differently   when  being  incremented or   decremented: while
-<I>raw</I> iterators let the  associated accessor point  to any of the
-objects it   is  made for,  <I>normal</I>  iterators   always point to
-objects which are in use.  Usually, you will not want  to see cells or
-lines which are there but are unused by the triangulation (these cells
-are  somewhat like  holes in  the   arrays of the triangulation;  such
-things happen  when unrefining a cell,  the freed memory  is then kept
-for a while  because of better efficiency), so  you will  almost never
-want to use raw iterators;  they are mostly there  for internal use in
-the    library. Normal iterators are   almost  like raw iterators, but
-whenever you call the ++  or -- operator,  the  look at what they  are
-pointing at  and skip all unused  elements by increasing or decreasing
-the pointer as often as necessary to reach the next used object.
-</p>
-
-<p>
-Finally,    there are <I>active</I>  iterators,    which are the  most
-important ones. They  are  like normal   iterators but  only point  to
-active cells or lines.  By active we  mean that they have no children;
-in  the context in which this  library is used,  this is equivalent to
-the  fact   that   we  do  computations   on these   cells,   lines or
-whatever. Active iterators  are normal iterators  which  skip over all
-non-active cells, lines, etc when being incremented or decremented.
-</p>
-
-
-
-<a name="tria-accessors"></a>
-<H3>
-The triangulation accessor hierarchy
-</H3>
-
-<p>
-The triangulation accessors are used to retrieve and store data in the
-triangulation.  There  exist accessors  for  lines  in one and  higher
-dimensions, accessors for  quads in two  and higher dimensions, and so
-on. The general naming scheme is as follows:
-<ul>
-<li> <code>TriaAccessor&lt;dim&gt;</code> is a general base class
-     which is of not much interest.
-<li> <code>TriaObjectAccessor&lt;objectdim,spacedim&gt;</code> denotes
-     an accessor for an object with dimension
-     <code>objectdim</code> in a <code>spacedim</code> dimensional
-     space. It is derived from <code>TriaAccessor&lt;spacedim&gt;</code>.
-<li> <code>CellAccessor&lt;dim&gt;</code> presents the special
-     properties that a cell has. It is therefore derived from
-     <code>TriaObjectAccessor&lt;spacedimdim,spacedim&gt;</code>.
-</ul>
-</p>
-
-<p>
-Their inheritance trees in the different space dimensions therefore
-look like this:
-</p>
-
-<hr>
-
-<CENTER>
-<IMG SRC="1d-tria.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-<hr>
-
-<CENTER>
-<IMG SRC="2d-tria.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-<hr>
-
-<CENTER>
-<IMG SRC="3d-tria.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-<hr>
-
-<p>
-Some of the data is only  useful if an object is  a cell. For example,
-neighborship is only accessible for cells,  while faces (e.g. lines in
-2D) can't access their neighbors (neither the  adjacent cells, nor the
-other   faces it touches).    Therefore, the CellAccessor classes  are
-derived from whatever  object a cell  is in the respective  dimension,
-i.e. from lines  in 1D, from quads  in 2D,  and  so on. 
-</p>
-
-
-
-<a name="tria-typedefs"></a>
-<H4>
-Typedefs of the Triangulation class to iterators and accessors
-</H4>
-
-<p>
-The <CODE>Triangulation<1></CODE> class declares the following data
-types which involve accessors:
-<PRE>
-    typedef TriaRawIterator   <1,CellAccessor<1> >    raw_line_iterator;
-    typedef TriaIterator      <1,CellAccessor<1> >        line_iterator;
-    typedef TriaActiveIterator<1,CellAccessor<1> > active_line_iterator;
-
-    typedef    raw_line_iterator    raw_cell_iterator;
-    typedef        line_iterator        cell_iterator;
-    typedef active_line_iterator active_cell_iterator; 
-</PRE>
-Since lines are cells in one space dimension, all line iterators are
-cell iterators as well.
-</p>
-
-<p>
-In two space dimensions, the following types are declared by the
-<CODE>Triangulation<2></CODE> class:
-<PRE>
-    typedef TriaRawIterator   <2,TriaObjectAccessor<1, 2> >    raw_line_iterator;
-    typedef TriaIterator      <2,TriaObjectAccessor<1, 2> >        line_iterator;
-    typedef TriaActiveIterator<2,TriaObjectAccessor<1, 2> > active_line_iterator;
-    
-    typedef TriaRawIterator   <2,CellAccessor<2> >    raw_quad_iterator;
-    typedef TriaIterator      <2,CellAccessor<2> >        quad_iterator;
-    typedef TriaActiveIterator<2,CellAccessor<2> > active_quad_iterator;
-
-    typedef    raw_quad_iterator    raw_cell_iterator;
-    typedef        quad_iterator        cell_iterator;
-    typedef active_quad_iterator active_cell_iterator;
-
-    typedef    raw_line_iterator    raw_face_iterator;
-    typedef        line_iterator        face_iterator;
-    typedef active_line_iterator active_face_iterator;    
-</PRE>
-Since in this space dimension, quads are cells and lines are the faces
-of  cells, the  appropriate face  and  cell iterators  are declared in
-terms of the underlying accessor types.
-</p>
-
-
-<p>
-In three space dimensions, the following types are declared by the
-<CODE>Triangulation<3></CODE> class:
-<PRE>
-    typedef TriaRawIterator   <3,TriaObjectAccessor<1, 3> >    raw_line_iterator;
-    typedef TriaIterator      <3,TriaObjectAccessor<1, 3> >        line_iterator;
-    typedef TriaActiveIterator<3,TriaObjectAccessor<1, 3> > active_line_iterator;
-    
-    typedef TriaRawIterator   <3,TriaObjectAccessor<2, 3> >    raw_quad_iterator;
-    typedef TriaIterator      <3,TriaObjectAccessor<2, 3> >        quad_iterator;
-    typedef TriaActiveIterator<3,TriaObjectAccessor<2, 3> > active_quad_iterator;
-
-    typedef TriaRawIterator   <3,CellAccessor<3> >    raw_hex_iterator;
-    typedef TriaIterator      <3,CellAccessor<3> >        hex_iterator;
-    typedef TriaActiveIterator<3,CellAccessor<3> > active_hex_iterator;
-
-    typedef    raw_hex_iterator    raw_cell_iterator;
-    typedef        hex_iterator        cell_iterator;
-    typedef active_hex_iterator active_cell_iterator;
-
-    typedef    raw_quad_iterator    raw_face_iterator;
-    typedef        quad_iterator        face_iterator;
-    typedef active_quad_iterator active_face_iterator;    
-</PRE>
-Since in this space dimension, hexes are cells and quads are the faces
-of  cells, the  appropriate face  and  cell iterators  are declared in
-terms of the underlying accessor types.
-</p>
-
-
-
-<a name="tria-functions"></a>
-<h4>Functions offered by triangulation accessors</h4>
-
-<p>
-We briefly state a short list of the functions offered by the
-triangulation accessors. For a more complete discussion of these
-functions, please refer to the online 
-<a href="../../documentation.html" target="body">API
-documentation of the `grid' classes</a>. These functions can be
-accessed by <code>iterator->function()</code> if <code>iterator</code>
-is a cell-, face-, hex-, quad-, or line-iterator. Some functions are
-not available for all iterator types, which is noted for the
-individual entries.
-</p>
-
-<dl>
-  <dt><em>
-  level ()
-  </em></dt>
-
-  <dd>
-  Return the hierarchical refinement level on 
-  which this object lives.
-  </dd>
-
-
-  <dt><em>
-  index ()
-  </em></dt>
-
-  <dd>
-  Return the index within the hierarchical refinement level on 
-  which this object lives.
-  </dd>
-
-
-  <dt><em>
-  get_triangulation ()
-  </em></dt>
-
-  <dd>
-  Return a reference to the triangulation to which this object belongs.
-  </dd>
-
-
-  <dt><em>
-  vertex_index (vertex_number)
-  </em></dt>
-
-  <dd>
-  Return the global index of one of the vertices of this object.
-  </dd>
-
-
-  <dt><em>
-  vertex (vertex_number)
-  </em></dt>
-
-  <dd>
-  Return the position of the respective vertex in space.
-  </dd>
-
-
-  <dt><em>
-  used ()
-  </em></dt>
-
-  <dd>
-  Return whether the object is used. The return value is
-  <code>true</code> for all iterators that are either normal iterators
-  or active iterators, only raw iterators can return
-  <code>false</code>. Since raw iterators are only used in the
-  interiors of the library, you will not usually need this function.
-  </dd>
-
-
-  <dt><em>
-  set_used () / clear_used ()
-  </em></dt>
-
-  <dd>
-  Set or clear the flag that describes whether the object is used by
-  the triangulation. Only for internal use.
-  </dd>
-
-
-  <dt><em>
-  user_flag_set ()
-  </em></dt>
-
-  <dd>
-  Return whether the user flag is set.
-  </dd>
-
-
-  <dt><em>
-  set_user_flag () / clear_user_flag ()
-  </em></dt>
-
-  <dd>
-  Set or clear the flag that might be used by a user to indicate that
-  something should happen with this object.
-  </dd>
-
-
-  <dt><em>
-  recursively_set_user_flag () / recursively_clear_user_flag ()
-  </em></dt>
-
-  <dd>
-  Set or clear the user flag for this cell and all its descendants.
-  </dd>
-
-
-  <dt><em>
-  user_pointer ()
-  </em></dt>
-
-  <dd>
-  Query the pointer belonging to this object which may be used by
-  the user to store additional information with this object.
-  </dd>
-
-
-  <dt><em>
-  set_user_pointer () / clear_user_pointer ()
-  </em></dt>
-
-  <dd>
-  Set or clear a pointer belonging to this object which may be used by
-  the user to store additional information with this object.
-  </dd>
-
-
-  <dt><em>
-  child (child_number)
-  </em></dt>
-
-  <dd>
-  Return an iterator to one of the children of this object.
-  </dd>
-
-
-  <dt><em>
-  child_index (child_number)
-  </em></dt>
-
-  <dd>
-  Return the index of the child within the next finer level of the
-  triangulation. 
-  </dd>
-
-
-  <dt><em>
-  set_children (index), clear_children ()
-  </em></dt>
-
-  <dd>
-  Only for internal use.
-  </dd>
-
-
-  <dt><em>
-  has_children ()
-  </em></dt>
-
-  <dd>
-  Return whether an object has children, i.e. whether it is further
-  refined. If it has children, then it is not active.
-  </dd>
-
-
-  <dt><em>
-  max_refinement_depth ()
-  </em></dt>
-
-  <dd>
-  Return how often this cell or one of its children is refined.
-  </dd>
-
-
-  <dt><em>
-  boundary_indicator
-  </em></dt>
-
-  <dd>
-  Return the number of the boundary at which this object lies, if the
-  object has a dimension less than the space dimension.
-  </dd>
-
-
-  <dt><em>
-  set_boundary_indicator (boundary_id)
-  </em></dt>
-
-  <dd>
-  Set the number of the boundary to which this object belongs.
-  </dd>
-
-
-  <dt><em>
-  at_boundary ()
-  </em></dt>
-
-  <dd>
-  Return whether this object is at the boundary (if the dimension of
-  the object is less than the space dimension), or one of its faces is
-  at the boundary for cells.
-  </dd>
-
-
-  <dt><em>
-  has_boundary_lines ()
-  </em></dt>
-
-  <dd>
-  Return whether one of the lines bounding this cell is at the
-  boundary. For 1d and 2d this is equivalent to <em>at_boundary</em>,
-  in 3d, there are cases where bounding lines of a hex are at the
-  boundary, while the faces are in the interior. (Only for cell
-  iterators.)
-  </dd>
-
-
-  <dt><em>
-  diameter ()
-  </em></dt>
-
-  <dd>
-  Return the diameter of the object.
-  </dd>
-
-
-  <dt><em>
-  center ()
-  </em></dt>
-
-  <dd>
-  Return the coordinates of the center of the object.
-  </dd>
-
-
-  <dt><em>
-  barycenter ()
-  </em></dt>
-
-  <dd>
-  Return the coordinates of the barycenter of the object.
-  </dd>
-
-
-  <dt><em>
-  measure ()
-  </em></dt>
-
-  <dd>
-  Return the length, area, or volume of an object, depending on the
-  dimension of the object.
-  </dd>
-
-
-  <dt><em>
-  point_inside (point)
-  </em></dt>
-
-  <dd>
-  Return whether the given point is inside this cell, or rather the
-  (bi-, tri-)linearly mapped image of the unit cell with the vertices
-  of this cell. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  number_of_children ()
-  </em></dt>
-
-  <dd>
-  Accumulated number of children and their children.
-  </dd>
-
-
-  <dt><em>
-  line (line_number)
-  </em></dt>
-
-  <dd>
-  Return an iterator to one of the bounding lines of this object. (Only
-  for iterators to quadrilaterals and hexahedra.)
-  </dd>
-
-
-  <dt><em>
-  line_index (line_number)
-  </em></dt>
-
-  <dd>
-  Return the index of one of the bounding lines of this object. The
-  level index is the same as that of the present object. (Only
-  for iterators to quadrilaterals and hexahedra.)
-  </dd>
-
-
-  <dt><em>
-  quad (quad_number)
-  </em></dt>
-
-  <dd>
-  Return an iterator to one of the bounding quadrilaterals of this
-  object. (Only for iterators to hexahedra.)
-  </dd>
-
-
-  <dt><em>
-  line_index (line_number)
-  </em></dt>
-
-  <dd>
-  Return the index of one of the bounding quadrilaterals of this
-  object. The level index is the same as that of the present
-  object. (Only for iterators to hexahedra.)
-  </dd>
-
-
-  <dt><em>
-  neighbor (neighbor_number)
-  </em></dt>
-
-  <dd>
-  Return iterator to one of the neighbors. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  neighbor_index (neighbor_number) / neighbor_level (neighbor_number)
-  </em></dt>
-
-  <dd>
-  Return number and level of one of the neighbors. (Only for cell
-  iterators.)
-  </dd>
-
-
-  <dt><em>
-  set_neighbor ()
-  </em></dt>
-
-  <dd>
-  Set a neighbor. Only for internal use. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  neighbor_of_neighbor (neighbor_number)
-  </em></dt>
-
-  <dd>
-  Return the how-manyth neighbor the present cell is of the neighbor
-  specified by the argument. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  at_boundary (face_number)
-  </em></dt>
-
-  <dd>
-  Return whether this cell's given face is at the boundary. (Only for
-  cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  refine_flag_set ()
-  </em></dt>
-
-  <dd>
-  Return whether the refinement flag is set or not for the present
-  cell. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  set_refine_flag () / clear_refine_flag ()
-  </em></dt>
-
-  <dd>
-  Set/clear the flag indicating refinement. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  coarsen_flag_set ()
-  </em></dt>
-
-  <dd>
-  Query whether the flag indicating coarsening is set for this
-  object. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  set_coarsen_flag () / claer_coarsen_flag ()
-  </em></dt>
-
-  <dd>
-  Set/clear the flag indicating coarsening. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  face (face_number)
-  </em></dt>
-
-  <dd>
-  Return an iterator to one of the faces of this cell, if dimension is
-  greater than one. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  material_id ()
-  </em></dt>
-
-  <dd>
-  Return the material number of this cell. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  set_material_id (id)
-  </em></dt>
-
-  <dd>
-  Set the material number of this cell. (Only for cell iterators.)
-  </dd>
-
-
-  <dt><em>
-  active ()
-  </em></dt>
-
-  <dd>
-  Return whether this cell is active, i.e. has no children. (Only for
-  cell iterators.)
-  </dd>
-</dl>
-
-
-
-<a name="dof-accessors"></a>
-<H3>
-The degree of freedom accessor hierarchy
-</H3>
-
-<p>
-The DoFAccessor classes    provide access to  the   degree  of freedom
-information associated  with  cells,   lines, etc.   The   inheritance
-relationship is much the    same  as for the   triangulation  accessor
-classes, as can  be seen from the  following  pictures.
-
-<hr>
-
-<CENTER>
-<IMG SRC="1d-dof.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-
-<hr>
-
-<CENTER>
-<IMG SRC="2d-dof.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-
-<hr>
-
-<CENTER>
-<IMG SRC="3d-dof.jpg" ALIGN="CENTER" WIDTH="80%"> 
-</CENTER>
-<p>
-
-<hr>
-
-<p>
-The main difference to the triangulation accessor hierarchy is that we
-want the DoF accessors to provide the information about the degrees of
-freedom, but for convenience also that of the triangulation. This way,
-we can get all the information from one object rather than needing two
-which  work in  parallel, and  the  class hierarchy  shown above  does
-exactly this.
-</p>
-
-<p>
-For the named reason, it is necessary to derive the
-<code>DoFObjectAccessor&lt;1,dim&gt;</code> from the
-<code>TriaObjectAccessor&lt;1,dim&gt;</code> class of the
-triangulation accessor hierarchy, as well as the
-<code>DoFObjectAccessor&lt;2,dim&gt;</code> from the
-<code>TriaObjectAccessor&lt;2,dim&gt;</code>. However, we would also
-like to include the functionality added by the CellAccessor class;
-this is done through some template magic: when in one space dimension,
-the <code>DoFObjectAccessor&lt;1,1&gt;</code> is derived from
-CellAccessor&lt;1&gt;, while when in higher dimensions, it is derived
-from <code>DoFObjectAccessor&lt;1,dim&gt;</code>; the same applies for
-the <code>DoFObjectAccessor&lt;2,dim&gt;</code> class.  Note that this
-way, CellAccessor is always a base class to DoFCellAccessor and the
-inheritance lattice is dimension dependant; the exact way of achieving
-this is complicated but not of interest here.
-</p>
-
-
-<a name="dof-typedefs"></a>
-<H4>
-Typedefs of the DoFHandler class to iterators and accessors
-</H4>
-
-<p>
-The typedefs done by the DoFHandler class are much alike those done by
-the Triangulation class. They could be summarized as follows:
-</p>
-
-<p>
-For one space dimension:
-<PRE>
-    typedef TriaRawIterator   <1,DoFCellAccessor<1> >    raw_line_iterator;
-    typedef TriaIterator      <1,DoFCellAccessor<1> >        line_iterator;
-    typedef TriaActiveIterator<1,DoFCellAccessor<1> > active_line_iterator;
-
-    typedef    raw_line_iterator    raw_cell_iterator;
-    typedef        line_iterator        cell_iterator;
-    typedef active_line_iterator active_cell_iterator; 
-</PRE>
-Since lines are cells in one space dimension, all line iterators are
-cell iterators as well.
-</p>
-
-<p>
-For two space dimensions:
-<PRE>
-    typedef TriaRawIterator   <2,DoFObjectAccessor<1, 2> >    raw_line_iterator;
-    typedef TriaIterator      <2,DoFObjectAccessor<1, 2> >        line_iterator;
-    typedef TriaActiveIterator<2,DoFObjectAccessor<1, 2> > active_line_iterator;
-    
-    typedef TriaRawIterator   <2,DoFCellAccessor<2> >    raw_quad_iterator;
-    typedef TriaIterator      <2,DoFCellAccessor<2> >        quad_iterator;
-    typedef TriaActiveIterator<2,DoFCellAccessor<2> > active_quad_iterator;
-
-    typedef    raw_quad_iterator    raw_cell_iterator;
-    typedef        quad_iterator        cell_iterator;
-    typedef active_quad_iterator active_cell_iterator;
-
-    typedef    raw_line_iterator    raw_face_iterator;
-    typedef        line_iterator        face_iterator;
-    typedef active_line_iterator active_face_iterator;    
-</PRE>
-</p>
-
-<p>
-For three space dimensions:
-<PRE>
-    typedef TriaRawIterator   <3,DoFObjectAccessor<1, 3> >    raw_line_iterator;
-    typedef TriaIterator      <3,DoFObjectAccessor<1, 3> >        line_iterator;
-    typedef TriaActiveIterator<3,DoFObjectAccessor<1, 3> > active_line_iterator;
-
-    typedef TriaRawIterator   <3,DoFObjectAccessor<2, 3> >    raw_quad_iterator;
-    typedef TriaIterator      <3,DoFObjectAccessor<2, 3> >        quad_iterator;
-    typedef TriaActiveIterator<3,DoFObjectAccessor<2, 3> > active_quad_iterator;
-
-    typedef TriaRawIterator   <3,DoFCellAccessor<3> >         raw_hex_iterator;
-    typedef TriaIterator      <3,DoFCellAccessor<3> >             hex_iterator;
-    typedef TriaActiveIterator<3,DoFCellAccessor<3> >      active_hex_iterator;
-
-    typedef    raw_hex_iterator    raw_cell_iterator;
-    typedef        hex_iterator        cell_iterator;
-    typedef active_hex_iterator active_cell_iterator;
-
-    typedef    raw_quad_iterator    raw_face_iterator;
-    typedef        quad_iterator        face_iterator;
-    typedef active_quad_iterator active_face_iterator;    
-</PRE>
-</p>
-
-
-
-<a name="dof-functions"></a>
-<h4>Functions offered by degree of freedom accessors</h4>
-
-<p>
-Since degree of freedom accessors are derived from triangulation
-accessors, they inherit the functionality of these accessors, but add
-some of their own. We only list the additional functionality
-below. For a full reference, including data types of parameters and
-return values, please refer to the general
-<a href="../../documentation.html" target="body">API
-documentation of the `DoF' classes</a>.
-</p>
-
-
-<dl>
-  <dt><em>
-  dof_index (dof_number)
-  </em></dt>
-
-  <dd>
-  Return the global index of one of the DoFs on this object.
-  </dd>
-
-
-  <dt><em>
-  set_dof_index (dof_number, index)
-  </em></dt>
-
-  <dd>
-  Set the index of a DoF. Only for internal use.
-  </dd>
-
-
-  <dt><em>
-  vertex_dof_index (vertex_number, dof_number)
-  </em></dt>
-
-  <dd>
-  Return the index of one of the DoFs on one of the vertices of this
-  object.
-  </dd>
-
-
-  <dt><em>
-  set_vertex_dof_index (...)
-  </em></dt>
-
-  <dd>
-  Set the vertex DoF index. Only for internal use.
-  </dd>
-
-
-  <dt><em>
-  get_dof_indices (vector_of_indices)
-  </em></dt>
-
-  <dd>
-  Return a vector of the indices of the DoFs on this object.
-  </dd>
-
-
-  <dt><em>
-  get_dof_values (global_values, local_values)
-  </em></dt>
-
-  <dd>
-  Extract and return the values of the DoFs on this object from a data
-  vector defined on all DoFs.
-  </dd>
-
-
-  <dt><em>
-  set_dof_values (local_values, global_values)
-  </em></dt>
-
-  <dd>
-  Reverse operation: take values of DoFs on this object, and set them
-  into a global data vector.
-  </dd>
-
-
-  <dt><em>
-  distribute_local_to_global (local_source, global_destination)  
-  </em></dt>
-
-  <dd>
-  Add the elements of local_source, defining values of the degrees of
-  freedom on this object, to the elements of the global data
-  vector. The two parameters may be either vectors or matrices.
-  </dd>
-
-
-  <dt><em>
-  get_interpolated_dof_values (global_values, local_interpolation)
-  </em></dt>
-
-  <dd>
-  Interpolate the global field to this cell. If this cell is active,
-  then this is the restriction of the global field to this cell,
-  but when this cell is not active then it is the interpolation of the
-  restriction of the field to the child cells and the interpolation to
-  the present one. (For cell iterators only.)
-  </dd>
-
-
-  <dt><em>
-  set_dof_values_by_interpolation (local_values, global_interpolation)
-  </em></dt>
-  
-  <dd>
-  Inverse operation: interpolate the local values to the children (if
-  this cell is not active) and set the respective values in the global
-  vector. (For cell iterators only.)
-  </dd>
-</dl>
-
-
-<HR>
-
-<div ALIGN="RIGHT">
-Wolfgang Bangerth, 1998, 1999, 2000
-</div>
-<p>&nbsp;</P></BODY>
-</HTML>
-
-
-
-</BODY>
-</HTML>
-
diff --git a/deal.II/doc/reports/codimension-one/desimone-heltai-manigrasso.pdf b/deal.II/doc/reports/codimension-one/desimone-heltai-manigrasso.pdf
deleted file mode 100644 (file)
index d64a5e5..0000000
Binary files a/deal.II/doc/reports/codimension-one/desimone-heltai-manigrasso.pdf and /dev/null differ
index 025527d4c7f542134f2f5cf95acc982065f10678..9a2246b474d9f56230d5b0be99ff400e3619cab6 100644 (file)
@@ -24,7 +24,7 @@
   <ul>
     <li>
       A brief report about the classes involved in the
-      <a href="class-hierarchies/index.html"
+      <a href="http://www.dealii.org/reports/class-hierarchies/index.html"
          target="body">iterators and accessors</a>
       used to access cells in the triangulations and the data
       thereon, such as their geometry, the number of the
@@ -35,7 +35,7 @@
     </li>
 
     <li>
-      A brief report on <a href="mapping_q/index.html"
+      A brief report on <a href="http://www.dealii.org/reports/mapping_q/index.html"
                           target="body">mapping</a> functions of higher polynomial
       degrees (by Ralf Hartmann). These allow the realisation
       of higher order boundary approximations. This report
@@ -45,7 +45,7 @@
 
     <li>
       A report on
-      <a href="assemble/assemble.pdf"
+      <a href="http://www.dealii.org/reports/assemble/assemble.pdf"
          target="body">assembling matrices</a> (by Wolfgang
       Bangerth). This report looks in particular at how
       matrices are assembled for vector-valued problems, and
@@ -57,7 +57,7 @@
 
     <li>
       A very detailed report on
-      <a href="nedelec/nedelec.pdf"
+      <a href="http://www.dealii.org/reports/nedelec/nedelec.pdf"
          target="body">Nedelec elements</a> (by Anna
       Schneebeli, University of Basel, Switzerland). It
       explains the construction and application of Nedelec
@@ -68,7 +68,7 @@
 
     <li>
       A report on the
-      <a href="codimension-one/desimone-heltai-manigrasso.pdf"
+      <a href="http://www.dealii.org/reports/codimension-one/desimone-heltai-manigrasso.pdf"
          target="body">codimension one</a> capabilities of the library
          (by Antonio DeSimone, Luca Heltai and Cataldo Manigrasso,
          SISSA, Trieste, Italy). It explains in detail how to use the
diff --git a/deal.II/doc/reports/mapping_q/img1.gif b/deal.II/doc/reports/mapping_q/img1.gif
deleted file mode 100644 (file)
index 3afa2db..0000000
Binary files a/deal.II/doc/reports/mapping_q/img1.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img10.gif b/deal.II/doc/reports/mapping_q/img10.gif
deleted file mode 100644 (file)
index f1b1253..0000000
Binary files a/deal.II/doc/reports/mapping_q/img10.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img11.gif b/deal.II/doc/reports/mapping_q/img11.gif
deleted file mode 100644 (file)
index f3a7034..0000000
Binary files a/deal.II/doc/reports/mapping_q/img11.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img12.gif b/deal.II/doc/reports/mapping_q/img12.gif
deleted file mode 100644 (file)
index 7e40605..0000000
Binary files a/deal.II/doc/reports/mapping_q/img12.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img13.gif b/deal.II/doc/reports/mapping_q/img13.gif
deleted file mode 100644 (file)
index c7a3aea..0000000
Binary files a/deal.II/doc/reports/mapping_q/img13.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img14.gif b/deal.II/doc/reports/mapping_q/img14.gif
deleted file mode 100644 (file)
index e9c184c..0000000
Binary files a/deal.II/doc/reports/mapping_q/img14.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img15.gif b/deal.II/doc/reports/mapping_q/img15.gif
deleted file mode 100644 (file)
index 0bab0d5..0000000
Binary files a/deal.II/doc/reports/mapping_q/img15.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img16.gif b/deal.II/doc/reports/mapping_q/img16.gif
deleted file mode 100644 (file)
index 655453f..0000000
Binary files a/deal.II/doc/reports/mapping_q/img16.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img17.gif b/deal.II/doc/reports/mapping_q/img17.gif
deleted file mode 100644 (file)
index d16cfa2..0000000
Binary files a/deal.II/doc/reports/mapping_q/img17.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img18.gif b/deal.II/doc/reports/mapping_q/img18.gif
deleted file mode 100644 (file)
index 273a7d4..0000000
Binary files a/deal.II/doc/reports/mapping_q/img18.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img19.gif b/deal.II/doc/reports/mapping_q/img19.gif
deleted file mode 100644 (file)
index 7254199..0000000
Binary files a/deal.II/doc/reports/mapping_q/img19.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img2.gif b/deal.II/doc/reports/mapping_q/img2.gif
deleted file mode 100644 (file)
index 91c5ff7..0000000
Binary files a/deal.II/doc/reports/mapping_q/img2.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img20.gif b/deal.II/doc/reports/mapping_q/img20.gif
deleted file mode 100644 (file)
index 5535696..0000000
Binary files a/deal.II/doc/reports/mapping_q/img20.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img21.gif b/deal.II/doc/reports/mapping_q/img21.gif
deleted file mode 100644 (file)
index 0398f35..0000000
Binary files a/deal.II/doc/reports/mapping_q/img21.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img22.gif b/deal.II/doc/reports/mapping_q/img22.gif
deleted file mode 100644 (file)
index de29603..0000000
Binary files a/deal.II/doc/reports/mapping_q/img22.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img23.gif b/deal.II/doc/reports/mapping_q/img23.gif
deleted file mode 100644 (file)
index af5f661..0000000
Binary files a/deal.II/doc/reports/mapping_q/img23.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img24.gif b/deal.II/doc/reports/mapping_q/img24.gif
deleted file mode 100644 (file)
index 8725fa8..0000000
Binary files a/deal.II/doc/reports/mapping_q/img24.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img25.gif b/deal.II/doc/reports/mapping_q/img25.gif
deleted file mode 100644 (file)
index 4a18c7e..0000000
Binary files a/deal.II/doc/reports/mapping_q/img25.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img26.gif b/deal.II/doc/reports/mapping_q/img26.gif
deleted file mode 100644 (file)
index 3a9ba08..0000000
Binary files a/deal.II/doc/reports/mapping_q/img26.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img27.gif b/deal.II/doc/reports/mapping_q/img27.gif
deleted file mode 100644 (file)
index 99087f0..0000000
Binary files a/deal.II/doc/reports/mapping_q/img27.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img28.gif b/deal.II/doc/reports/mapping_q/img28.gif
deleted file mode 100644 (file)
index 707c7df..0000000
Binary files a/deal.II/doc/reports/mapping_q/img28.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img29.gif b/deal.II/doc/reports/mapping_q/img29.gif
deleted file mode 100644 (file)
index edd5bfb..0000000
Binary files a/deal.II/doc/reports/mapping_q/img29.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img3.gif b/deal.II/doc/reports/mapping_q/img3.gif
deleted file mode 100644 (file)
index 5535696..0000000
Binary files a/deal.II/doc/reports/mapping_q/img3.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img30.gif b/deal.II/doc/reports/mapping_q/img30.gif
deleted file mode 100644 (file)
index cd04d32..0000000
Binary files a/deal.II/doc/reports/mapping_q/img30.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img31.gif b/deal.II/doc/reports/mapping_q/img31.gif
deleted file mode 100644 (file)
index e9a9003..0000000
Binary files a/deal.II/doc/reports/mapping_q/img31.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img32.gif b/deal.II/doc/reports/mapping_q/img32.gif
deleted file mode 100644 (file)
index 38306f0..0000000
Binary files a/deal.II/doc/reports/mapping_q/img32.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img33.gif b/deal.II/doc/reports/mapping_q/img33.gif
deleted file mode 100644 (file)
index b8d2b50..0000000
Binary files a/deal.II/doc/reports/mapping_q/img33.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img34.gif b/deal.II/doc/reports/mapping_q/img34.gif
deleted file mode 100644 (file)
index aea6c3e..0000000
Binary files a/deal.II/doc/reports/mapping_q/img34.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img35.gif b/deal.II/doc/reports/mapping_q/img35.gif
deleted file mode 100644 (file)
index 2dbcd81..0000000
Binary files a/deal.II/doc/reports/mapping_q/img35.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img36.gif b/deal.II/doc/reports/mapping_q/img36.gif
deleted file mode 100644 (file)
index f8bfdf0..0000000
Binary files a/deal.II/doc/reports/mapping_q/img36.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img37.gif b/deal.II/doc/reports/mapping_q/img37.gif
deleted file mode 100644 (file)
index 65d5c07..0000000
Binary files a/deal.II/doc/reports/mapping_q/img37.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img38.gif b/deal.II/doc/reports/mapping_q/img38.gif
deleted file mode 100644 (file)
index 231b0e8..0000000
Binary files a/deal.II/doc/reports/mapping_q/img38.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img39.gif b/deal.II/doc/reports/mapping_q/img39.gif
deleted file mode 100644 (file)
index ff944c6..0000000
Binary files a/deal.II/doc/reports/mapping_q/img39.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img4.gif b/deal.II/doc/reports/mapping_q/img4.gif
deleted file mode 100644 (file)
index 3ebda31..0000000
Binary files a/deal.II/doc/reports/mapping_q/img4.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img40.gif b/deal.II/doc/reports/mapping_q/img40.gif
deleted file mode 100644 (file)
index b4a8f2a..0000000
Binary files a/deal.II/doc/reports/mapping_q/img40.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img41.gif b/deal.II/doc/reports/mapping_q/img41.gif
deleted file mode 100644 (file)
index d95a0f0..0000000
Binary files a/deal.II/doc/reports/mapping_q/img41.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img42.gif b/deal.II/doc/reports/mapping_q/img42.gif
deleted file mode 100644 (file)
index d28a084..0000000
Binary files a/deal.II/doc/reports/mapping_q/img42.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img43.gif b/deal.II/doc/reports/mapping_q/img43.gif
deleted file mode 100644 (file)
index b3d5a1a..0000000
Binary files a/deal.II/doc/reports/mapping_q/img43.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img44.gif b/deal.II/doc/reports/mapping_q/img44.gif
deleted file mode 100644 (file)
index 86cc117..0000000
Binary files a/deal.II/doc/reports/mapping_q/img44.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img45.gif b/deal.II/doc/reports/mapping_q/img45.gif
deleted file mode 100644 (file)
index 09dcfea..0000000
Binary files a/deal.II/doc/reports/mapping_q/img45.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img46.gif b/deal.II/doc/reports/mapping_q/img46.gif
deleted file mode 100644 (file)
index 1e1590e..0000000
Binary files a/deal.II/doc/reports/mapping_q/img46.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img47.gif b/deal.II/doc/reports/mapping_q/img47.gif
deleted file mode 100644 (file)
index 0239071..0000000
Binary files a/deal.II/doc/reports/mapping_q/img47.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img48.gif b/deal.II/doc/reports/mapping_q/img48.gif
deleted file mode 100644 (file)
index 15674c4..0000000
Binary files a/deal.II/doc/reports/mapping_q/img48.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img49.gif b/deal.II/doc/reports/mapping_q/img49.gif
deleted file mode 100644 (file)
index ad5cc2d..0000000
Binary files a/deal.II/doc/reports/mapping_q/img49.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img5.gif b/deal.II/doc/reports/mapping_q/img5.gif
deleted file mode 100644 (file)
index 95d2ce6..0000000
Binary files a/deal.II/doc/reports/mapping_q/img5.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img50.gif b/deal.II/doc/reports/mapping_q/img50.gif
deleted file mode 100644 (file)
index 6f0caf5..0000000
Binary files a/deal.II/doc/reports/mapping_q/img50.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img51.gif b/deal.II/doc/reports/mapping_q/img51.gif
deleted file mode 100644 (file)
index fd296a6..0000000
Binary files a/deal.II/doc/reports/mapping_q/img51.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img6.gif b/deal.II/doc/reports/mapping_q/img6.gif
deleted file mode 100644 (file)
index 2d477da..0000000
Binary files a/deal.II/doc/reports/mapping_q/img6.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img7.gif b/deal.II/doc/reports/mapping_q/img7.gif
deleted file mode 100644 (file)
index 18070cf..0000000
Binary files a/deal.II/doc/reports/mapping_q/img7.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img8.gif b/deal.II/doc/reports/mapping_q/img8.gif
deleted file mode 100644 (file)
index 91c5ff7..0000000
Binary files a/deal.II/doc/reports/mapping_q/img8.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/img9.gif b/deal.II/doc/reports/mapping_q/img9.gif
deleted file mode 100644 (file)
index 5e6633a..0000000
Binary files a/deal.II/doc/reports/mapping_q/img9.gif and /dev/null differ
diff --git a/deal.II/doc/reports/mapping_q/index.html b/deal.II/doc/reports/mapping_q/index.html
deleted file mode 100644 (file)
index 487a4d7..0000000
+++ /dev/null
@@ -1,867 +0,0 @@
-<!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="mapping">
-<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">
-<LINK REL="next" HREF="node1.html">
-</HEAD>
-<BODY >
-<p>
-In modified form taken from
-<br>
-<br>
-<a href="http://ganymed.iwr.uni-heidelberg.de/~hartmann/" target="_top">Ralf Hartmann</a>
-<br>
-Adaptive Finite Element Methods for the Compressible Euler Equations
-<br>
-PhD thesis, University of Heidelberg, 2002.
-</p>
-
-
-<P>
-<DIV ALIGN="CENTER">
-<FONT SIZE="+4"><B>Higher order Boundary approximation</B></FONT>
-
-</DIV>
-<P>
-<B>Introduction:</B> In many numerical applications the domain
-
-<!-- MATH: $\Omega\subset\mathbb R^d$ -->
-<IMG
- WIDTH="61" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img6.gif"
- ALT="$\Omega\subset\mathbb R^d$">,
-<IMG
- WIDTH="46" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img7.gif"
- ALT="$d\geq 2$">
-is not a polygonal domain but includes
-curved boundaries. For these cases the boundary cannot be represented
-exactly by the discretised boundary. Approximating the boundary by a
-piecewise linear boundary interpolation, i.e. by a polygonal boundary,
-may in some applications not be sufficient. In these cases a higher
-order boundary approximation, for example by piecewise quadratic or
-cubic boundary interpolation, must be employed.  In the finite element
-framework this higher order boundary approximation is realized by
-mapping the reference element <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-to the element
-
-<!-- MATH: $K=\sigma_K(\hat K)$ -->
-<IMG
- WIDTH="96" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
- SRC="img9.gif"
- ALT="$K=\sigma_K(\hat K)$">
-in real space, whereas on cells <I>K</I> at the
-boundary, i.e.
-<!-- MATH: $\partial K\cap\Gamma=\emptyset$ -->
-<IMG
- WIDTH="93" HEIGHT="34" ALIGN="MIDDLE" BORDER="0"
- SRC="img10.gif"
- ALT="$\partial K\cap\Gamma=\emptyset$">,
-the mappings
-<IMG
- WIDTH="28" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$\sigma_K$">
-are given by polynomial functions of higher degree.
-
-<P>
-<B>Elements with general mapping functions <IMG
- WIDTH="28" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$\sigma_K$">.</B>  We begin
-by first introducing some notation. Let <IMG
- WIDTH="61" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img12.gif"
- ALT="$K\in T_h$">
-be a cell of the
-triangulation <I>T</I><SUB><I>h</I></SUB> with
-<!-- MATH: $K=\sigma_K(\hat K)$ -->
-<IMG
- WIDTH="96" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
- SRC="img9.gif"
- ALT="$K=\sigma_K(\hat K)$">,
-where <IMG
- WIDTH="28" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$\sigma_K$">is a smooth bijective mapping of the reference element (unit square)
-<IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-to the element <I>K</I> in real space, see Figure
-<A HREF="index.html#fig:mapping">1</A>.
-<BR>
-<DIV ALIGN="CENTER"><A NAME="fig:mapping">&#160;</A><A NAME="183">&#160;</A>
-<TABLE WIDTH="50%">
-<CAPTION><STRONG>Figure:</STRONG>
-Mapping <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">
-of reference element <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-to the element <I>K</I> in real space.</CAPTION>
-<TR><TD>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: $\includegraphics[scale=0.3]{figures/m1.ps}$ -->
-<IMG
- WIDTH="660" ALIGN="BOTTOM" BORDER="0"
- SRC="img13.gif"
- ALT="\includegraphics[scale=0.3]{figures/m1.ps}"></DIV></TD></TR>
-</TABLE>
-</DIV>
-<BR>
-<P>
-In the following and for the sake of simplicity we suppress the letter
-<I>K</I> in the subscript and write <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">
-instead of <IMG
- WIDTH="28" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$\sigma_K$">.
-
-<P>
-<B>Mapping functions of higher polynomial degree.</B>  A mapping
-function <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">,
-that maps the reference element <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-to an
-arbitrary quadrilateral cell <I>K</I> with straight boundaries, can in
-general be represented by a bilinear function, i.e.  by a
-<I>Q</I><SUB>1</SUB>-mapping. For the case that the cell <I>K</I> includes curved
-boundaries it might be necessary to employ polynomial mapping
-functions of higher degree.
-
-<P>
-Given a degree <I>p</I>&gt;0, a cell <IMG
- WIDTH="61" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img12.gif"
- ALT="$K\in T_h$">,
-and (<I>p</I>+1)<SUP><I>d</I></SUP> mapping
-support points <IMG
- WIDTH="56" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img14.gif"
- ALT="$p_i\in K$">,
-
-<!-- MATH: $i=0,\ldots,(p+1)^d-1$ -->
-<IMG
- WIDTH="174" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img15.gif"
- ALT="$i=0,\ldots,(p+1)^d-1$">,
-we define a
-<I>Q</I><SUB><I>p</I></SUB>-mapping
-<!-- MATH: $\sigma\in [Q_p]^d$ -->
-<IMG
- WIDTH="75" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img16.gif"
- ALT="$\sigma\in [Q_p]^d$">
-as follows
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\sigma(\hat x)=\sum_{i=0}^{(p+1)^d-1}p_i\phi_i(\hat x).
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:def-mapping-q">&#160;</A><IMG
- WIDTH="176" HEIGHT="66"
- SRC="img17.gif"
- ALT="\begin{displaymath}
-\sigma(\hat x)=\sum_{i=0}^{(p+1)^d-1}p_i\phi_i(\hat x).
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(1)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-Here, <IMG
- WIDTH="20" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img18.gif"
- ALT="$\phi_i$">,
-
-<!-- MATH: $i=0,\ldots,(p+1)^d-1$ -->
-<IMG
- WIDTH="174" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img15.gif"
- ALT="$i=0,\ldots,(p+1)^d-1$">
-denote the Lagrange interpolation
-basis functions, that satisfy
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-\phi_i(\hat p_j)=\delta_{ij}, \quad i,j=0,\ldots,(p+1)^d-1,
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="302" HEIGHT="32"
- SRC="img19.gif"
- ALT="\begin{displaymath}\phi_i(\hat p_j)=\delta_{ij}, \quad i,j=0,\ldots,(p+1)^d-1,
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-where <IMG
- WIDTH="19" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img20.gif"
- ALT="$\hat p_i$">,
-
-<!-- MATH: $i=0,\ldots,(p+1)^d-1$ -->
-<IMG
- WIDTH="174" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img15.gif"
- ALT="$i=0,\ldots,(p+1)^d-1$">
-denote the Lagrange support
-points on the unit cell <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">.
-The definition of <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">(<A HREF="index.html#eq:def-mapping-q">1</A>) ensures that each of the unit support points
-<IMG
- WIDTH="19" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img20.gif"
- ALT="$\hat p_i$">
-is mapped onto the corresponding mapping support points
-<I>p</I><SUB><I>i</I></SUB>, i.e.
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\sigma(\hat p_i)=p_i, \quad i=0,\ldots,(p+1)^d-1
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:point-mappings">&#160;</A><IMG
- WIDTH="270" HEIGHT="31"
- SRC="img21.gif"
- ALT="\begin{displaymath}
-\sigma(\hat p_i)=p_i, \quad i=0,\ldots,(p+1)^d-1
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(2)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-Analogous to Lagrange finite elements the unit Lagrange support points
-<IMG
- WIDTH="19" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img20.gif"
- ALT="$\hat p_i$">
-are equidistantly distributed on <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-based on a tensor
-product mesh. In the following we only consider the two-dimensional
-case, <I>d</I>=2.  For that case, Figure <A HREF="index.html#fig:unit-mapping-points">2</A>
-shows the distributions of the unit support points <IMG
- WIDTH="19" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img20.gif"
- ALT="$\hat p_i$">,
-
-<!-- MATH: $i=0,\ldots,(p+1)^2-1$ -->
-<IMG
- WIDTH="174" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
- SRC="img22.gif"
- ALT="$i=0,\ldots,(p+1)^2-1$">
-for degrees
-<!-- MATH: $p=1,\ldots,4$ -->
-<IMG
- WIDTH="96" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img5.gif"
- ALT="$p=1,\ldots ,4$">.
-<BR>
-<DIV ALIGN="CENTER"><A NAME="fig:unit-mapping-points">&#160;</A><A NAME="184">&#160;</A>
-<TABLE WIDTH="50%">
-<CAPTION><STRONG>Figure:</STRONG>
-Unit support points <IMG
- WIDTH="19" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img20.gif"
- ALT="$\hat p_i$">,
-
-<!-- MATH: $0\leq i<(p+1)^2$ -->
-<IMG
- WIDTH="126" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
- SRC="img4.gif"
- ALT="$0\leq i<(p+1)^2$">,
-for degrees
-<!-- MATH: $p=1,\ldots,4$ -->
-<IMG
- WIDTH="96" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img5.gif"
- ALT="$p=1,\ldots ,4$">.</CAPTION>
-<TR><TD>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: $\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q1_n.eps}$ -->
-<IMG
- WIDTH="180" ALIGN="BOTTOM" BORDER="0"
- SRC="img23.gif"
- ALT="\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q1_n.eps}">
-
-<!-- MATH: $\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q2_n.eps}$ -->
-<IMG
- WIDTH="180" ALIGN="BOTTOM" BORDER="0"
- SRC="img24.gif"
- ALT="\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q2_n.eps}">
-
-<!-- MATH: $\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q3_n.eps}$ -->
-<IMG
- WIDTH="180" ALIGN="BOTTOM" BORDER="0"
- SRC="img25.gif"
- ALT="\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q3_n.eps}">
-
-<!-- MATH: $\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q4_n.eps}$ -->
-<IMG
- WIDTH="180" ALIGN="BOTTOM" BORDER="0"
- SRC="img26.gif"
- ALT="\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q4_n.eps}"></DIV></TD></TR>
-</TABLE>
-</DIV>
-<BR>
-Let the ordering and numbering of the unit support points be as
-follows: first the corners, then the points on the edges and finally
-the inner support points, see also Figure
-<A HREF="index.html#fig:unit-mapping-points">2</A>.  Thus the first 4<I>p</I> points are placed
-on the boundary
-<!-- MATH: $\partial\hat K$ -->
-<IMG
- WIDTH="31" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img27.gif"
- ALT="$\partial\hat K$">
-of the reference cell, i.e.
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-\hat p_k\in\partial\hat K, \quad k=0,\ldots,4p-1.
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="225" HEIGHT="30"
- SRC="img28.gif"
- ALT="\begin{displaymath}\hat p_k\in\partial\hat K, \quad k=0,\ldots,4p-1.
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-According to (<A HREF="index.html#eq:point-mappings">2</A>) these points are mapped to the
-mapping support points <I>p</I><SUB><I>k</I></SUB>,
-<!-- MATH: $k=0,\ldots,4p-1$ -->
-<IMG
- WIDTH="135" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$k=0,\ldots,4p-1$">
-that are chosen to be
-placed on the boundary of the real cell in approximatively equal
-distances, i.e.
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-p_k\in\partial K, \quad k=0,\ldots,4p-1.
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="224" HEIGHT="30"
- SRC="img30.gif"
- ALT="\begin{displaymath}p_k\in\partial K, \quad k=0,\ldots,4p-1.
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-While the support points <I>p</I><SUB><I>k</I></SUB>,
-<!-- MATH: $k=0,\ldots,4p-1$ -->
-<IMG
- WIDTH="135" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$k=0,\ldots,4p-1$">
-on the boundary are
-given by the boundary description of the real cell <I>K</I>, the <EM>inner
-  mapping support points</EM>
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-p_i\in K\setminus\partial K, \quad i=4p,\ldots,(p+1)^2-1
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="297" HEIGHT="31"
- SRC="img31.gif"
- ALT="\begin{displaymath}p_i\in K\setminus\partial K, \quad i=4p,\ldots,(p+1)^2-1
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-are not uniquely determined. Numerical tests show that it is not a
-trivial task to define the positions of the inner mapping support
-points appropriately. If they are not chosen appropriately the
-resulting mapping <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">
-for a cell <I>K</I> may degenerate, i.e. the
-mapping <IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">
-for some cell <I>K</I> may not be bijective.
-
-<P>
-<B>Computation of inner support points by smooth transformation.</B>
-In the following we will define the positions of the inner mapping
-support points so that the mapping does - in all practical cases - <I>not</I>
-degenerate. To this end, we employ an approach for the mapping of the
-support points, that is in the style of the smooth transformations
-that is used to transform structured triangulations to match complex
-boundary discriptions. In the following, again for notational
-convenience, we consider only the two-dimensional case.
-
-<P>
-The smooth transformation mentioned above is based on solutions to the
-Laplace equation that is solved on the reference cell <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">.
-Discrete boundary conditions are imposed that are given by the
-coordinates of the mapping support points <I>p</I><SUB><I>k</I></SUB>,
-<!-- MATH: $k=0,\ldots,4p-1$ -->
-<IMG
- WIDTH="135" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$k=0,\ldots,4p-1$">,
-on
-the boundary of the cell <I>K</I> in real space.
-
-<P>
-To be more explicite we define a Laplace problem on the unit
-cell <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\begin{array}{rcll}
--\hat\Delta \sigma_l(\hat x)&=&0, \quad &\hat x\in \hat K,\\
-  \sigma_l(\hat x)&=&{g_l}|_{\partial \hat K}(\hat x), \quad &\hat x\in \partial\hat K,
-\end{array}
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:local-laplace-problem">&#160;</A><IMG
- WIDTH="273" HEIGHT="53"
- SRC="img32.gif"
- ALT="\begin{displaymath}
-\begin{array}{rcll}
--\hat\Delta \sigma_l(\hat x)&=&0, \quad...
-...l \hat K}(\hat x), \quad &\hat x\in \partial\hat K,
-\end{array}\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(3)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-for each component <IMG
- WIDTH="20" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
- SRC="img33.gif"
- ALT="$\sigma_l$">,
-<I>l</I>=1,2, of the <I>Q</I><SUB><I>p</I></SUB> mapping
-<IMG
- WIDTH="15" HEIGHT="16" ALIGN="BOTTOM" BORDER="0"
- SRC="img1.gif"
- ALT="$\sigma $">.
-Here, the discrete boundary function
-<!-- MATH: $g\in [Q_p]^2$ -->
-<IMG
- WIDTH="73" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
- SRC="img34.gif"
- ALT="$g\in [Q_p]^2$">
-is
-given by
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-g_l(\hat x)=\sum_{i=0}^{4p-1}(p_i)_l\phi_i(\hat x), \quad l=1,\ldots,d
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:discrete-boundary-function">&#160;</A><IMG
- WIDTH="277" HEIGHT="62"
- SRC="img35.gif"
- ALT="\begin{displaymath}
-g_l(\hat x)=\sum_{i=0}^{4p-1}(p_i)_l\phi_i(\hat x), \quad l=1,\ldots,d
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(4)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-where (<I>p</I><SUB><I>i</I></SUB>)<SUB><I>l</I></SUB> denotes the <I>l</I>th component of the support point <I>p</I><SUB><I>i</I></SUB>,
-and <IMG
- WIDTH="20" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img18.gif"
- ALT="$\phi_i$">
-the corresponding Lagrangian interpolation basis
-function.  We recall that the numbering of the mapping support points
-involves
-<!-- MATH: $p_k\in\partial K$ -->
-<IMG
- WIDTH="69" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img36.gif"
- ALT="$p_k\in\partial K$">
-for
-<!-- MATH: $k=0,\ldots, 4p-1$ -->
-<IMG
- WIDTH="135" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$k=0,\ldots,4p-1$">.
-Substituting
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\tilde \sigma_l:=\sigma_l-g_l, \quad l=1,2,
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:def-tilde-sigma">&#160;</A><IMG
- WIDTH="176" HEIGHT="30"
- SRC="img37.gif"
- ALT="\begin{displaymath}
-\tilde \sigma_l:=\sigma_l-g_l, \quad l=1,2,
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(5)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-into the Laplace problem (<A HREF="index.html#eq:local-laplace-problem">3</A>) yields the
-zero boundary value problem,
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\begin{array}{rcll}
--\hat\Delta \tilde\sigma_l(\hat x)&=&\hat\Delta g_l(\hat x), \quad &\hat x\in \hat K,\\
-  \tilde\sigma_l(\hat x)&=&0, \quad &\hat x\in \partial\hat K,
-\end{array}
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:transformed-local-laplace-problem">&#160;</A><IMG
- WIDTH="262" HEIGHT="53"
- SRC="img38.gif"
- ALT="\begin{displaymath}
-\begin{array}{rcll}
--\hat\Delta \tilde\sigma_l(\hat x)&=&\h...
-...gma_l(\hat x)&=&0, \quad &\hat x\in \partial\hat K,
-\end{array}\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(6)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-that is equivalent to the following variational formulation
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-\tilde\sigma_l\in H^1_0(\hat K):\qquad
-(\hat\nabla \tilde\sigma_l, \hat\nabla \phi)_{\hat K}
-    = -(\hat\nabla g_l, \hat\nabla \phi)_{\hat K} \quad \forall \phi\in  H^1_0(\hat K).
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="467" HEIGHT="33"
- SRC="img39.gif"
- ALT="\begin{displaymath}\tilde\sigma_l\in H^1_0(\hat K):\qquad
-(\hat\nabla \tilde\si...
-...\hat\nabla \phi)_{\hat K} \quad \forall \phi\in H^1_0(\hat K). \end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-Discretisation of this problem
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-\tilde\sigma_l\in Q_p(\hat K):\qquad
-(\hat\nabla \tilde\sigma_l, \hat\nabla \phi_{4p+i})_{\hat K}
-    = -(\hat\nabla g_l, \hat\nabla \phi_{4p+i})_{\hat K} \quad \forall i=0,\ldots, (p-1)^2-1,
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="609" HEIGHT="33"
- SRC="img40.gif"
- ALT="\begin{displaymath}\tilde\sigma_l\in Q_p(\hat K):\qquad
-(\hat\nabla \tilde\sigm...
-...bla \phi_{4p+i})_{\hat K} \quad \forall i=0,\ldots, (p-1)^2-1, \end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-and recalling definitions (<A HREF="index.html#eq:def-mapping-q">1</A>), (<A HREF="index.html#eq:def-tilde-sigma">5</A>) and (<A HREF="index.html#eq:discrete-boundary-function">4</A>) gives
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-\sum_{j=1}^{(p-1)^2}S_{ij}(p_{4p+j})_l=-\sum_{k=0}^{4p-1}T_{ik}(p_k)_l, \quad i=0, \ldots, (p-1)^2-1,
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:discrete-local-laplace">&#160;</A><IMG
- WIDTH="455" HEIGHT="68"
- SRC="img41.gif"
- ALT="\begin{displaymath}
-\sum_{j=1}^{(p-1)^2}S_{ij}(p_{4p+j})_l=-\sum_{k=0}^{4p-1}T_{ik}(p_k)_l, \quad i=0, \ldots, (p-1)^2-1,
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(7)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-with the matrices
-<!-- MATH: $S_{ij}\in\mathbb R^{(p-1)^2\times(p-1)^2}$ -->
-<IMG
- WIDTH="155" HEIGHT="42" ALIGN="MIDDLE" BORDER="0"
- SRC="img42.gif"
- ALT="$S_{ij}\in\mathbb R^{(p-1)^2\times(p-1)^2}$">
-and
-<!-- MATH: $T_{ik}\in\mathbb R^{(p-1)^2\times 4p}$ -->
-<IMG
- WIDTH="128" HEIGHT="42" ALIGN="MIDDLE" BORDER="0"
- SRC="img43.gif"
- ALT="$T_{ik}\in\mathbb R^{(p-1)^2\times 4p}$">
-given by
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-S_{ij}=(\hat\nabla \phi_{4p+i}, \hat\nabla \phi_{4p+j})_{\hat K}, \quad i,j=0,\ldots,(p-1)^2-1,
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="404" HEIGHT="33"
- SRC="img44.gif"
- ALT="\begin{displaymath}S_{ij}=(\hat\nabla \phi_{4p+i}, \hat\nabla \phi_{4p+j})_{\hat K}, \quad i,j=0,\ldots,(p-1)^2-1,
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-and
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-T_{ik}=(\hat\nabla \phi_{4p+i}, \hat\nabla \phi_k)_{\hat K}, \quad i=0,\ldots,(p-1)^2-1,\quad k=0,\ldots,4p-1.
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="522" HEIGHT="33"
- SRC="img45.gif"
- ALT="\begin{displaymath}T_{ik}=(\hat\nabla \phi_{4p+i}, \hat\nabla \phi_k)_{\hat K}, \quad i=0,\ldots,(p-1)^2-1,\quad k=0,\ldots,4p-1.
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-The solutions to problem (<A HREF="index.html#eq:discrete-local-laplace">7</A>) for <I>l</I>=1,2 are
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-(p_{4p+j})_l=-\sum_{i=0}^{(p-1)^2-1}\sum_{k=0}^{4p-1}S^{-1}_{ji}T_{ik}(p_k)_l, \quad j=0,\ldots,(p-1)^2-1,
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="481" HEIGHT="66"
- SRC="img46.gif"
- ALT="\begin{displaymath}(p_{4p+j})_l=-\sum_{i=0}^{(p-1)^2-1}\sum_{k=0}^{4p-1}S^{-1}_{ji}T_{ik}(p_k)_l, \quad j=0,\ldots,(p-1)^2-1,
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-that may be written in compact form:
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-p_{4p+j}=\sum_{k=0}^{4p-1}c_{jk}p_k, \quad j=0,\ldots,(p-1)^2-1,
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:linear-combination-laplace">&#160;</A><IMG
- WIDTH="337" HEIGHT="62"
- SRC="img47.gif"
- ALT="\begin{displaymath}
-p_{4p+j}=\sum_{k=0}^{4p-1}c_{jk}p_k, \quad j=0,\ldots,(p-1)^2-1,
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(8)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-where <I>c</I><SUB><I>jk</I></SUB> represents the coefficient
-<BR><P></P>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: \begin{equation}
-c_{jk}=-\sum_{i=0}^{(p-1)^2-1}S^{-1}_{ji}T_{ik}.
-\end{equation} -->
-
-<TABLE WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE"><TD ALIGN="CENTER" NOWRAP><A NAME="eq:coefficients">&#160;</A><IMG
- WIDTH="180" HEIGHT="65"
- SRC="img48.gif"
- ALT="\begin{displaymath}
-c_{jk}=-\sum_{i=0}^{(p-1)^2-1}S^{-1}_{ji}T_{ik}.
-\end{displaymath}"></TD>
-<TD WIDTH=10 ALIGN="RIGHT">
-(9)</TD></TR>
-</TABLE>
-</DIV>
-<BR CLEAR="ALL"><P></P>
-of the linear combination (<A HREF="index.html#eq:linear-combination-laplace">8</A>), that
-represents the dependency of the <I>j</I>th inner mapping support point
-<I>p</I><SUB>4<I>p</I>+<I>j</I></SUB> on the support points <I>p</I><SUB><I>k</I></SUB>,
-<!-- MATH: $k=0,\ldots,4p-1$ -->
-<IMG
- WIDTH="135" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$k=0,\ldots,4p-1$">,
-that are
-placed on the boundary of the cell <I>K</I>. For a fixed degree <I>p</I>, these
-coefficients <I>c</I><SUB><I>jk</I></SUB> are the same for the mapping of <EM>all</EM> cells
-<I>K</I> in real space because the <I>c</I><SUB><I>jk</I></SUB> depend only on the reference
-element <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">.
-Therefore the coefficients <I>c</I><SUB><I>jk</I></SUB> can be
-precomputed and result in following linear combinations:
-
-<P>
-For <I>p</I>=2 the linear combination turns out to be
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-p_8=\tfrac{1}{16}\sum_{k=0}^3p_k+\tfrac{3}{16}\sum_{k=4}^7p_k,
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="196" HEIGHT="61"
- SRC="img49.gif"
- ALT="\begin{displaymath}p_8=\tfrac{1}{16}\sum_{k=0}^3p_k+\tfrac{3}{16}\sum_{k=4}^7p_k,
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-see also Figure <A HREF="index.html#fig:coefficients-q2-q3">3</A>, left.
-<BR>
-<DIV ALIGN="CENTER"><A NAME="fig:coefficients-q2-q3">&#160;</A><A NAME="185">&#160;</A>
-<TABLE WIDTH="50%">
-<CAPTION><STRONG>Figure 3:</STRONG>
-Left: Coefficients <I>c</I><SUB>8,<I>k</I></SUB> for <I>Q</I><SUB>2</SUB> mapping. Right: Coefficients <I>c</I><SUB>12,<I>k</I></SUB> for <I>Q</I><SUB>3</SUB> mapping.</CAPTION>
-<TR><TD>
-<DIV ALIGN="CENTER">
-
-<!-- MATH: $\includegraphics*[scale=0.4]{figures/m2.ps}$ -->
-<IMG
- WIDTH="700" ALIGN="BOTTOM" BORDER="0"
- SRC="img50.gif"
- ALT="\includegraphics*[scale=0.4]{figures/m2.ps}"></DIV></TD></TR>
-</TABLE>
-</DIV>
-<BR>
-For the case that <I>p</I>=3, Figure <A HREF="index.html#fig:coefficients-q2-q3">3</A>, right, shows the coefficients <I>c</I><SUB>12,<I>k</I></SUB> of the linear combination for the inner mapping support point <I>p</I><SUB>12</SUB>. The coefficents for the points <I>p</I><SUB>13</SUB>, <I>p</I><SUB>14</SUB> and <I>p</I><SUB>15</SUB> can be obtain by rotation of the coefficients.
-
-<P>
-<B>Implementation in deal.II.</B>  The coefficients <I>c</I><SUB><I>jk</I></SUB>, see
-(<A HREF="index.html#eq:coefficients">9</A>), are represented in the <I>MappingQ</I>
-class by the <I>laplace_on_quad_vector</I> as follows
-<BR><P></P>
-<DIV ALIGN="CENTER">
-<!-- MATH: \begin{displaymath}
-\mbox{\textit{laplace\_on\_quad\_vector}[j][k]}=c_{jk}
-\end{displaymath} -->
-
-
-<IMG
- WIDTH="247" HEIGHT="32"
- SRC="img51.gif"
- ALT="\begin{displaymath}\mbox{\textit{laplace\_on\_quad\_vector}[j][k]}=c_{jk}
-\end{displaymath}">
-</DIV>
-<BR CLEAR="ALL">
-<P></P>
-These coefficients are the same for the mapping of <EM>all</EM> cells
-<I>K</I> in real space because the <I>c</I><SUB><I>jk</I></SUB> depend only on the reference
-element <IMG
- WIDTH="21" HEIGHT="21" ALIGN="BOTTOM" BORDER="0"
- SRC="img8.gif"
- ALT="$\hat K$">.
-Hence for a given degree <I>p</I> the
-<I>laplace_on_quad_vector</I> can be filled by the constructor of
-the <I>MappingQ</I> class. This is done by calling the
-<I>MappingQ::set_laplace_on_quad_vector</I> function that
-includes the coefficients hardcoded for <I>p</I>=2 and <I>p</I>=3 in <I>d</I>=2 dimensions, and a routine for computing the coefficients according to
-(<A HREF="index.html#eq:coefficients">9</A>) for all other cases.  The mapping support
-points <IMG
- WIDTH="56" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img14.gif"
- ALT="$p_i\in K$">,
-
-<!-- MATH: $i=0,\ldots,(p+1)^d-1$ -->
-<IMG
- WIDTH="174" HEIGHT="38" ALIGN="MIDDLE" BORDER="0"
- SRC="img15.gif"
- ALT="$i=0,\ldots,(p+1)^d-1$">
-are computed once for each
-MappingQ object by the
-<I>MappingQ::compute_support_points_laplace</I> that is invoked
-by the virtual <I>compute_mapping_support_points</I> function of
-the base <I>Mapping</I> class. In
-<I>MappingQ::compute_support_points_laplace</I>, first the 4<I>p</I> points on the boundary of the cell are computed (by calling
-<I>MappingQ::add_line_support_points</I>), then by calling
-<I>MappingQ::apply_laplace_vector</I> the remaining (<I>p</I>-1)<SUP>2</SUP> inner mapping supports points are computed, where
-<I>MappingQ::apply_laplace_vector</I> just performs the linear
-combination given in (<A HREF="index.html#eq:linear-combination-laplace">8</A>).
-<BR><HR>
-</FONT>
-<ADDRESS>
-<I>Ralf Hartmann</I>
-<BR><I>2001-09-03</I>
-</ADDRESS>
-</BODY>
-</HTML>
diff --git a/deal.II/doc/reports/nedelec/nedelec.pdf b/deal.II/doc/reports/nedelec/nedelec.pdf
deleted file mode 100644 (file)
index 1ed9f2e..0000000
Binary files a/deal.II/doc/reports/nedelec/nedelec.pdf and /dev/null differ
diff --git a/deal.II/doc/reports/new-threads/index.html b/deal.II/doc/reports/new-threads/index.html
deleted file mode 100644 (file)
index b146117..0000000
+++ /dev/null
@@ -1,1059 +0,0 @@
-
-<H1 ALIGN="CENTER">
-A short description of the new threading scheme
-</H1>
-
-
-<p ALIGN="CENTER">
-  <strong> Wolfgang Bangerth, May 2003</strong>
-</p>
-
-
-<p>
-Since the first deal.II report on
-multithreading was written in 2000 (see the list of deal.II
-publications),
-we have put in place a new
-implementation of the threading scheme (the first release to contain it is
-4.0). The new scheme can do all that you could do before, so the report is in a
-sense still valid, but it describes a syntax that is no more used. We will here
-briefly describe this syntax as well as some considerations that guided us
-while implementing it. For general questions on multithreading, how programs
-that use it must look like, and for pitfalls to watch out for, please still
-refer to the report mentioned above.
-</p>
-
-<p>
-We note that since this report was written, there has been another
-incarnation of support for multicore machines, namely by using the
-Threading Building Blocks and tasks. The documentation module on
-parallel computing, available through the modules page of the deal.II
-manual, explains this new direction in more detail.
-</p>
-
-
-<h3>1. Rationale and Introduction</h3>
-
-
-<p>
-POSIX and other thread libraries only allow functions as thread entry
-points that satisfy the signature
-<code><pre>
-  void *  (*)  (void *)
-</pre></code>
-and starting threads involves a clumsy syntax. Thread entry points
-with another signature need to be "wrapped", i.e. their arguments need
-to be stored in a structure, and we need a function with above
-signature that can be used to "unpack" the arguments and call the
-desired function. This basically forces us to have one such structure
-and entry function for each function signature that we want to start a
-thread with.
-</p>
-
-<p>
-The first incarnations of the threading scheme in deal.II already got a long
-way towards making this simpler, by hiding the thread entry points, the packing
-and unpacking behind a layer of carefully crafted templates. It allowed you to
-call (almost) any function with arbitrary argument lists on a new thread,
-except that functions that returned values were not allowed. Implementing such
-a template scheme is not simple, since, besides simplicity to use, it has to
-take care of the lifetimes of objects that need to be synchronised across
-threads, and in particular since templates do not allow for functions with
-arbitrary numbers of arguments - they need to be repeated for every number of
-arguments, which makes implementation tedious. Nevertheless, the old scheme was
-very much usable.
-</p>
-
-<p>
-However, the old scheme had a number of shortcomings:
-<ul>
-<li>The implementation did not allow for functions returning
-  anything but <code>void</code>. We want to be able to call everything
-  on a new thread that can also be called on the present one.</li>
-<li>Thread objects could not be copied. Rather, thread ids were put into a
-thread manager object that took care of it, but handling single, or even
-detached threads was not too convenient.</li>
-<li>The general syntax for calling a function on a new thread was a
-  little clumsy and not intuitive.</li>
-</ul>
-</p>
-
-<p>
-Regarding the last point, note that any other function is called by
-<code><pre>
-    f(arg1, arg2);
-    obj.f(arg1, arg2);
-</pre></code>
-Ideally, the following syntax for starting any function on a new
-thread would be nice:
-<code><pre>
-    spawn f(arg1, arg2);
-    spawn obj.f(arg1,arg2);
-</pre></code>
-This syntax is not possible in C++, but the following syntax is,
-making it relatively clear what the intent of the statement is:
-<code><pre>
-    spawn (f)(arg1, arg2);
-    spawn (obj, &Class::f)(arg1,arg2);
-</pre></code>
-This is the syntax we will want to achieve (except for the fact that the
-<code>spawn</code> function is in a namespace <code>Threads</code>, just like
-all other entities described here).
-</p>
-
-<p>
-This text will discuss the details that are needed to implement
-this syntax, as well as the following points:
-<ul>
-<li>Overloading <code>spawn(</code>) so as to take unbound functions and member
-functions, whether virtual or static. Of course, every call needs to be type
-safe, i.e. the exact
-  same conversions of arguments need to be performed as in a usual call (except
-  for two additional copies that are necessary).</li>
-<li><code>spawn()</code> needs to return a value that allows us to identify,
-and join a thread. The syntax for this will be
-<code><pre>
-      Thread&lt;&gt; t = spawn(f)(arg1, arg2);
-      t.join ();
-</pre></code>
-  If we don't save the return value of <code>spawn()</code>, as in the examples
-  above, then we have just created a detached thread.</li>
-<li>Return values: if <code>f()</code> returns a value, say, an integer, then
-we want to be able to retrieve it once the thread has finished:
-<code><pre>
-      Thread&lt;int&gt; t = spawn (f)(1., 1.);
-      t.join ();
-      int i = t.return_value ();
-</pre></code>
-  This requires some care when functions return references, but some
-  template magic will save us. Another special case are functions that
-  return <code>void</code>.</li>
-<li>Thread groups: if threads are created inside a loop, we will want to
-  put all of them into a <code>ThreadGroup</code> object, and wait for them
-  collectively, rather than one-by-one.</li>
-</ul>
-</p>
-
-<p>
-Basically, the syntax above is all you need to know. It is as simple as
-that. The rest of this text, in comparison is very much of technical nature. I
-took most of it from a technical discussion I had with the author of the
-threading scheme in boost, William Kempf. It describes the way the threading
-scheme is implemented, the meaning of the various classes, etc. It probably
-doesn't give you much insight how to <em>use</em> it, but should explain in
-reasonable detail how it <em>works</em>. For more examples of use, take a look
-at a number of the example programs in deal.II, or at some places in the
-library itself.
-</p>
-
-
-<p>
-This paper is divided into the following parts:
-<ol>
-<li>This introduction</li>
-<li>Entities (functions, classes) that are used by both and that
-   describe the newly created thread</li>
-<li>Entities that are used on the calling thread</li>
-<li>Entities that are used to create a thread</li>
-<li>Tool classes</li>
-<li>Open problems</li>
-<li>Further suggestions</li>
-</ol>
-We will present the main parts of the code in the text. The implementation is
-in the library; all entities that
-are not to be used by the user are placed into a namespace
-<code>internal</code>, those to be used are in a namespace
-<code>Threads</code>. The implementation uses Boost's shared_ptr. Some parts of
-the implementation parallel the
-boost::function library, but they are small and taylored to the
-particular purpose at hand; in particular, they make heavy use of the
-boost::tuple library. We note that the code has in some places already evolved
-a little bit beyond the state of this paper, but the main ideas are all to be
-found still.
-</p>
-
-
-
-<h3>2. Entities that describe threads</h3>
-
-
-<p>
-Each thread that has been created is described by exactly one object
-of type <code>thread_description&lt;RT&gt;</code>, where <code>RT</code> here and in the
-sequel will always denote the return type of the function being called
-on a new thread. The <code>thread_description</code> class is split into an
-operating system dependent base class, and an independent derived
-class. The base class is responsible for abstracting the OS
-interface to the functions creating, joining, killing, and signalling
-threads. For POSIX threads, this class looks as follows:
-</p>
-
-<code><pre>
-    struct thread_description_base {
-      private:
-        pthread_t                 pt;
-        mutable volatile bool     was_joined;
-        mutable boost::mutex      join_mutex;
-        mutable boost::condition  join_condition;
-
-      public:
-        thread_description_base () : was_joined (false) {};
-        virtual ~thread_description_base () { /* ... */ };
-
-        void create (void * (*p) (void *), void *d) {
-          pthread_create (&pt, 0, p, d);
-        };
-
-        void join () const {
-          if (was_joined)
-            return;
-          boost::mutex::scoped_lock lock(join_mutex);
-          if (!was_joined)
-              pthread_join (pt, 0);
-          was_joined = true;
-        };
-    };
-</pre></code>
-
-<p>
-<code>join()</code> can be called more than once and uses Schmidt's thread-safe
-double-checking pattern for speed. There could be additional functions
-<code>kill()</code> or <code>send_signal()</code>, but these are not presently
-implemented.
-</p>
-
-<p>
-In the destructor, we need to make sure that a thread is joined at
-least once in its lifetime, or if not that it is being detached
-(otherwise, we create the thread equivalent of a zombie process, which
-will lead to a resource leak in the operating system). This is a
-little tricky, since the destructor might be called while the thread
-is still running; comments in the code explain how we work around
-this.
-</p>
-
-<p>
-The <code>thread_description&lt;RT&gt;</code> class is derived from this base
-class:
-<code><pre>
-    template &lt;typename RT&gt;
-    struct thread_description : public thread_description_base
-    {
-        return_value&lt;RT&gt; ret_val;
-    };
-</pre></code>
-</p>
-
-<p>
-Its only purpose is to provide a place of storage for the return
-value of the function being called on the new thread. Since functions
-might return references or just nothing at all, the <code>return_value</code>
-template is used. It is described below in the section on Tool
-Classes. The return value will be set on exit of the function being
-called.
-</p>
-
-<p>
-As mentioned, there is exactly one <code>thread_description&lt;RT&gt;</code>
-object per created thread. It is accessed using <code>boost::shared_ptr</code>
-objects, and references are held from each <code>Thread&lt;RT&gt;</code> object
-for this thread as
-well as from a wrapper function on the new thread. The object is thus
-deleted, when all <code>Thread&lt;RT&gt;</code> objects for this thread have gone out of
-scope (or point to different threads) and the thread itself has
-finished; this is the appropriate time.
-</p>
-
-
-
-<h3>3. Entities that are used on the calling thread</h3>
-
-
-<p>
-On the calling thread, we basically use the <code>Thread&lt;RT&gt;</code>
-class, <code>ThreadGroup&lt;RT&gt;</code> class, and <code>spawn</code>
-function. The <code>Thread&lt;RT&gt;</code> class has the following
-implementation:
-</p>
-
-<code><pre>
-    template &lt;typename RT = void&gt;
-    class Thread {
-      public:
-        Thread () {};
-        Thread (const boost::shared_ptr&lt;thread_description&lt;RT&gt; &gt; &td)
-          : thread_description (td) {};
-
-        void join () const { thread_description-&gt;join (); };
-
-        RT return_value () {
-          join ();
-          return thread_description-&gt;ret_val.get();
-        };
-
-        bool operator == (const thread &t) {
-          return thread_description == t.thread_description;
-        };
-
-      private:
-        boost::shared_ptr&lt;thread_description&lt;RT&gt; &gt; thread_description;
-    };
-</pre></code>
-
-<p>
-Copy constructor and <code>operator=</code> are generated automatically by the
-compiler. Note that asking for the <code>return_value</code> automatically waits
-for the thread to finish, and that for this it is helpful that we can
-call <code>join()</code> more than once on the thread description object. The
-<code>return_value()</code> function also makes use of the fact that if <code>RT=void</code>,
-then the return construct is still valid. Furthermore, since this is
-the most common case, the template argument of the thread class has a
-default of <code>void</code>.
-</p>
-
-<p>
-The <code>ThreadGroup</code> class is a container distributing calls to its
-member functions to all its elements. Elements are added using
-<code>operator+=</code>, and they are stored using a
-<code>std::vector</code>. (A <code>std::set</code> would be more appropriate,
-but then we would have to have <code>operator&lt;</code> for
-<code>Thread&lt;RT&gt;</code> objects.) It has the same default value for the
-template argument:
-</p>
-
-<code><pre>
-    template &lt;typename RT = void&gt;
-    class ThreadGroup
-    {
-      public:
-        ThreadGroup & operator += (const Thread&lt;RT&gt; &t) {
-          threads.push_back (t);
-         return *this;
-        };
-
-        void join_all () const {
-          for (typename std::vector&lt;Thread&lt;RT&gt; &gt;::const_iterator
-                 t=threads.begin(); t!=threads.end(); ++t)
-            t-&gt;join ();
-        };
-
-      private:
-        std::vector&lt;Thread&lt;RT&gt; &gt; threads;
-    };
-</pre></code>
-
-<p>
-Since objects of type <code>Thread&lt;RT&gt;</code> are freely copyable, there
-is no need
-to provide an index operator for <code>ThreadGroup</code>; if you need to index
-its elements (for example to get at the return value), use
-<code>std::vector&lt;Thread&lt;RT&gt; &gt;</code>.
-</p>
-
-<p>
-Finally, there are overloads of the <code>spawn</code> template, for unbound
-functions, as well as <code>const</code> and non-<code>const</code> member
-functions. We only show them for unary member functions:
-<code><pre>
-    template &lt;typename RT, typename C, typename Arg1&gt;
-    mem_fun_encapsulator&lt;RT,C,boost::tuple&lt;Arg1&gt; &gt;
-    spawn (C &c, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator&lt;RT, C, boost::tuple&lt;Arg1&gt; &gt; (c,fun_ptr);
-    }
-
-    template &lt;typename RT, typename C, typename Arg1&gt;
-    mem_fun_encapsulator&lt;RT,const C,boost::tuple&lt;Arg1&gt; &gt;
-    spawn (const C &c, RT (C::*fun_ptr)(Arg1) const) {
-      return mem_fun_encapsulator&lt;RT, const C, boost::tuple&lt;Arg1&gt; &gt; (c,fun_ptr);
-    }
-</pre></code>
-</p>
-
-<p>
-Note that we need two overloaded versions, for <code>const</code> and
-non-<code>const</code>
-member functions. Both create an intermediate object (in the
-<code>internal</code>
-namespace) that will accept arguments in place of the function being
-called on the new thread, make sure a new thread is created, copy the
-arguments to the new thread's stack, and only then return. The exact
-mechanism is described in the next section.
-</p>
-
-<p>
-In the implementation, we have to repeat the functions above for
-binary, ternary, ... member functions, and also for unbound member
-functions. One would really like to have something also for objects other than
-pointers to (member-)functions that provide an
-<code>operator()</code>. However, this doesn't seem to be possible if
-<code>operator()</code> returns something other than <code>void</code> or takes
-arguments. This
-would need some kind of typeof-operator which is not standard C++. See the
-discussion in the Open Problems section.
-</p>
-
-
-<h3>4. Entities that are used to create a thread</h3>
-
-
-<p>
-In this section, we describe the gory details of copying arguments
-from the stack of the old thread to the stack of the new one. These
-details are not necessary to <em>use</em> the <code>spawn()</code> functions,
-so are probably boring and may be skipped.
-</p>
-
-<p>
-The basic idea is the following: <code>spawn()</code> returns an object and provides
-it with the address of the function to be called, and in the case of a
-member function with the address of an object. <code>mem_fun_encapsulator</code>
-looks like this:
-</p>
-
-<code><pre>
-    template &lt;typename RT, typename C, typename ArgList,
-              int length = boost::tuples::length&lt;ArgList&gt;::value&gt;
-    class mem_fun_encapsulator;
-
-    template &lt;typename RT, typename C, typename ArgList&gt;
-    class mem_fun_encapsulator&lt;RT,C,ArgList,1&gt; {
-        typedef typename mem_fun_ptr&lt;RT,C,ArgList&gt;::type MemFunPtr;
-
-      public:
-        mem_fun_encapsulator (C &c, MemFunPtr mem_fun_ptr)
-            : c (c), mem_fun_ptr(mem_fun_ptr) {};
-
-        Thread&lt;RT&gt;
-        operator() (typename boost::tuples::element&lt;0,ArgList&gt;::type arg1) {
-            return mem_fun_wrapper&lt;RT,C,ArgList&gt; (mem_fun_ptr, c,
-                                                  boost::tie(arg1)).fire_up ();
-        };
-
-      private:
-        C         &c;
-        MemFunPtr  mem_fun_ptr;
-    };
-</pre></code>
-
-<p>
-(Note how the default value specification of the last template
-argument automatically redirects uses with three template parameters
-to the correct four-parameter specialization, even though the general
-template is never used.)
-</p>
-
-<p>
-The constructor stores the two addresses. If one calls
-<code><pre>
-    spawn(obj, &C::f) (42);
-</pre></code>
-the next thing that is invoked is the <code>operator()</code> of this class. It
-takes the argument(s), creates a temporary with the two addresses and
-a reference to the argument (that's what <code>boost::tie</code>) does, and calls
-<code>fire_up()</code> on this temporary. <code>fire_up</code> has all the information, and does
-the work. Note that we will not pass references to the individual
-arguments, but bind them all together with <code>boost::tie</code>, so that we need
-not have different versions of the <code>mem_fun_wrapper</code> class for different
-numbers of arguments. (However, we need a separate partial
-specialization of the <code>mem_fun_encapsulator</code> class for each number of
-function arguments.) The <code>tie_args</code> template is used to make a version
-of the <code>ArgList</code> type with all reference types; it is described below.
-</p>
-
-<p>
-The next question, of course, is how <code>mem_fun_wrapper</code> looks like. Let
-us first consider the base class that it has in common with
-<code>fun_wrapper</code>, the wrapping class for non-member function objects:
-<code><pre>
-    template &lt;typename RT, typename EntryPointClass&gt;
-    struct wrapper_base {
-        Thread&lt;RT&gt; fire_up () {
-          thread_descriptor
-            = DescriptionPointer(new typename thread_description&lt;RT&gt;());
-
-          boost::mutex::scoped_lock lock (mutex);
-          thread_descriptor-&gt;create (&EntryPointClass::entry_point,
-                                        (void *)this);
-          condition.wait (lock);
-
-          return thread_descriptor;
-        }
-
-      protected:
-        typedef boost::shared_ptr&lt;thread_description&lt;RT&gt; &gt;
-        DescriptionPointer;
-
-        DescriptionPointer thread_descriptor;
-
-        mutable boost::mutex     mutex;
-        mutable boost::condition condition;
-    };
-</pre></code>
-<p>
-<code>fire_up</code> is the only real function; it creates a thread descriptor
-object, and calls it with a pointer to the present object, and the address of
-the starting point is <code>EntryPointClass::entry_point</code>, where
-<code>EntryPoint</code> is the name of a class that implements this thread
-starting function and is passed as a template argument to
-<code>wrapper_base</code>.
-Before it starts the new thread, it acquires a mutex and
-afterwards wait until a condition is signalled before it finishes by
-using the thread descriptor object to generate a <code>Thread&lt;RT&gt;</code>
-object.
-</p>
-
-<p>
-The magic happens in the derived class:
-<code><pre>
-    template &lt;typename RT, class C, typename ArgList&gt;
-    struct mem_fun_wrapper
-       : public wrapper_base&lt;RT, mem_fun_wrapper&lt;RT,C,ArgList&gt; &gt;
-    {
-        typedef typename mem_fun_ptr&lt;RT,C,ArgList&gt;::type MemFunPtr;
-        typedef typename tie_args&lt;ArgList&gt;::type ArgReferences;
-        mem_fun_wrapper (MemFunPtr            mem_fun_ptr,
-                         C                   &c,
-                         const ArgReferences &args)
-                        : c (c),
-                          mem_fun_ptr (mem_fun_ptr),
-                          args (args)  {};
-      private:
-        mem_fun_wrapper ();
-        mem_fun_wrapper (const mem_fun_wrapper &);
-
-        C            &c;
-        MemFunPtr     mem_fun_ptr;
-        ArgReferences args;
-
-        static void * entry_point (void *arg)
-          {
-            const wrapper_base&lt;RT&gt; *w
-              = reinterpret_cast&lt;const wrapper_base&lt;RT&gt;*&gt; (arg);
-            const mem_fun_wrapper *wrapper
-              = static_cast&lt;const mem_fun_wrapper*&gt; (w);
-            MemFunPtr mem_fun_ptr = wrapper-&gt;mem_fun_ptr;
-            C        &c           = wrapper-&gt;c;
-            ArgList   args        = wrapper-&gt;args;
-
-            boost::shared_ptr&lt;thread_description&lt;RT&gt; &gt;
-              thread_descriptor  = wrapper-&gt;thread_descriptor;
-
-            {
-              boost::mutex::scoped_lock lock (wrapper-&gt;mutex);
-              wrapper-&gt;condition.notify_one ();
-            }
-
-            call (mem_fun_ptr, c, args, thread_descriptor-&gt;ret_val);
-
-            return 0;
-          };
-    };
-</pre></code>
-</p>
-
-<p>
-Note in particular, how this class passes itself as second template parameter
-to the base class, enabling the latter to call the
-<code>mem_fun_wrapper::entry_point</code> function as entry point to the new
-thread. When the fire_up function in the base
-class is called, it creates a new thread that starts inside this
-function, and the argument given to it is the address of the
-<code>wrapper_base</code> object. The first thing the <code>entry_point</code> function does, is
-to cast back this address to the real object's type (it knows the real
-type of the object, since the address of this function has been handed
-down through the template magic), then copies the address of
-the object to work with and the address of the member function to be
-called from the stack of the old thread to the stack of this new
-thread. It then also copies the arguments, which so far have been held
-only as references, but copies them by value. Next, it gets the
-address of the return thread descriptor, and with it the address of
-the return value (the <code>shared_ptr</code> will also make sure that the object
-lives long enough). The part in braces signals the condition to the
-old thread, which hangs in the <code>fire_up</code> function: the arguments have
-been copied, and the old thread can go on, eventually also destroying
-objects that have been copied by value. Finally, it calls the
-requested function with the proper arguments through a generic
-interface (described in the section on tools) and sets the return
-value of the thread.
-</p>
-
-
-<h3>5. Tool classes</h3>
-
-
-<p>
-In the implementation above, some tool classes have been used. These
-are briefly described here.
-</p>
-
-<h4>a) The <code>return_value&lt;T&gt;</code> class template</h4>
-
-<p>
-This class stores a value of type <code>T</code> if <code>T</code> is not a
-reference or <code>void</code>. It offers <code>get()</code> and
-<code>set()</code> functions that get and set the value. If <code>T</code> is a
-reference type, then <code>set()</code> is obviously not possible since
-references cannot be rebound after construction time. The class therefore
-stores a pointer, and <code>set()</code> sets the pointer to the object the
-reference references. <code>get()</code> then returns the reference again. If
-<code>T</code> is <code>void</code>, then the class is empty and there is only
-a <code>get()<code> function that returns <code>void</code>.
-</p>
-
-<code><pre>
-    template &lt;typename RT&gt; struct return_value
-    {
-      private:
-        RT value;
-      public:
-        RT get () const { return value; }
-        void set (RT v) { value = v; }
-    };
-
-    template &lt;typename RT&gt; struct return_value&lt;RT &&gt;
-    {
-      private:
-        RT * value;
-      public:
-        RT & get () const { return *value; }
-        void set (RT & v) { value = &v; }
-    };
-
-    template &lt;&gt; struct return_value&lt;void&gt; {
-        static void get () {};
-    };
-</pre></code>
-
-
-<h4>b) The <code>call</code> function templates</h4>
-
-<p>
-The <code>call</code> function templates take a function pointer, an argument list
-tuple, and the address of the return value object, and call the
-function with these arguments. Since we have to unpack the argument
-list, we have to dispatch to different functions, depending on the
-number of arguments, in the usual way:
-</p>
-
-<code><pre>
-    template &lt;int&gt; struct int2type;
-
-    template &lt;typename RT, typename PFun, typename ArgList&gt;
-    static void call (PFun     fun_ptr,
-                      ArgList &arg_list,
-                      return_value&lt;RT&gt; &ret_val)
-    {
-      Caller&lt;RT&gt;::do_call (fun_ptr, arg_list, ret_val,
-                           int2type&lt;boost::tuples::length&lt;ArgList&gt;::value&gt;());
-    };
-</pre></code>
-
-<p>
-The <code>Caller</code> class has the following member functions:
-
-<code><pre>
-    template &lt;typename RT&gt; struct Caller
-    {
-        template &lt;typename PFun, typename ArgList&gt;
-        static void do_call (PFun     fun_ptr,
-                             ArgList &arg_list,
-                             return_value&lt;RT&gt; &ret_val,
-                             const int2type&lt;1&gt; &)
-        {  ret_val.set ((*fun_ptr) (arg_list.template get&lt;0&gt;()));  };
-
-        // likewise for int2type&lt;0&gt;, int2type&lt;2&gt;, ...
-    };
-</pre></code>
-</p>
-
-
-<p>
-There is a specialization <code>Caller&lt;void&gt;</code> that does not set a return
-value, and for each call and <code>do_call</code> function there is a second
-function for member function pointers that takes an object as
-additional argument.
-</p>
-
-
-<h4>c) <code>mem_fun_ptr</code></h4>
-
-<p>
-In order to form a pointer to member function for both cases of <code>const</code>
-and non-<code>const</code> member functions, we need a simple tool:
-<code><pre>
-    template &lt;typename RT, class C, typename ArgList,
-              int length = boost::tuples::length&lt;ArgList&gt;::value&gt;
-    struct mem_fun_ptr_helper;
-
-    template &lt;typename RT, class C, typename ArgList&gt;
-    struct mem_fun_ptr_helper&lt;RT, C, ArgList, 1&gt;
-    {
-        typedef RT (C::*type) (typename boost::tuples::element&lt;0,ArgList&gt;::type);
-    };
-
-    template &lt;typename RT, class C, typename ArgList&gt;
-    struct mem_fun_ptr_helper&lt;RT, const C, ArgList, 1&gt;
-    {
-        typedef RT (C::*type) (typename boost::tuples::element&lt;0,ArgList&gt;::type) const;
-    };
-
-    template &lt;typename RT, class C, typename ArgList&gt;
-    struct mem_fun_ptr
-    {
-        typedef typename mem_fun_ptr_helper&lt;RT,C,ArgList&gt;::type type;
-    };
-</pre></code>
-</p>
-
-<p>
-Note that if the second template argument is a <code>const C</code>, then we mark
-the member function <code>const</code>. The two templates for <code>mem_fun_ptr_helper</code>
-have to be repeated for every number of arguments that we have in
-mind. Note also that the specification of the default argument in the
-declaration of the general template of <code>mem_fun_ptr_helper</code> saves us
-from recomputing it in <code>mem_fun_ptr</code>.
-</p>
-
-
-
-<h4>d) <code>add_reference</code> for tuples</h4>
-
-<p>
-The following classes add references to the elements of a tuple, thus
-providing the type equivalent of the return value of the <code>boost::tie</code>
-functions. There are probably ways inside boost's tuples library to do
-this, but I couldn't locate this.
-<code><pre>
-    template &lt;int N, typename Tuple&gt;
-    struct add_reference_to_Nth
-    {
-        typedef typename boost::tuples::element&lt;N,Tuple&gt;::type ArgType;
-        typedef typename boost::add_reference&lt;ArgType&gt;::type type;
-    };
-
-    template &lt;typename Tuple, int = boost::tuples::length&lt;Tuple&gt;::value&gt;
-    struct tie_args_helper;
-
-    template &lt;typename Tuple&gt;
-    struct tie_args_helper&lt;Tuple,1&gt;
-    {
-        typedef
-        boost::tuple&lt;typename add_reference_to_Nth&lt;0,Tuple&gt;::type&gt;
-        type;
-    };
-
-    template &lt;typename Tuple&gt;
-    struct tie_args
-    {
-        typedef typename tie_args_helper&lt;Tuple&gt;::type type;
-    };
-</pre></code>
-</p>
-<p>
-The <code>tie_args_helper</code> class is repeated for every number of elements we
-want to use.
-</p>
-
-
-
-<h3>6. Open Problems</h3>
-
-
-<h4>a) A variable lifetime problem</h4>
-<p>
-The only unsolved semantic problem I am aware of at present is the
-following: if we have a function
-<code><pre>
-    void f(const int &amp;i);
-</pre></code>
-then this function can be called as
-<code><pre>
-    f(1);
-</pre></code>
-i.e. the compiler creates a temporary and passes its address to
-<code>f()</code>. When invoking <code>f()</code> on a new thread, however, as in
-<code><pre>
-    spawn (f)(1);
-</pre></code>
-then it is only guaranteed that the call to <code>spawn()</code> does not return
-before the new thread is started and has copied the arguments to
-<code>f()</code>. However, the argument is only the reference to the temporary, not
-its value. <code>f()</code> will thus likely observe corrupted values for its
-argument. On the other hand, copying the value is no option either, of
-course.  Since to the author's best knowledge the language does not
-provide means to avoid taking the address of a temporary, there is
-presently no way to avoid this problem. Suggestions for healing it are
-very welcome.
-</p>
-
-
-<h4>b) Forwarding of <code>operator()</code></h4>
-<p>
-Above, we have not defined an overload of <code>spawn</code> for functor-like
-objects, even though that would be desirable. One way to do so would be
-<code><pre>
-    template &lt;typename C&gt;
-    mem_fun_encapsulator&lt;void,C,boost::tuple&lt;&gt; &gt;
-    spawn (C &c) {
-      return spawn (c, &C::operator());
-    }
-</pre></code>
-This only works if <code>operator()</code> satisfies the signature
-<code><pre>
-    struct C {    void operator() ();  };
-</pre></code>
-</p>
-<p>
-We could add another overload if <code>operator()</code> is
-<code>const</code>. However, what one
-would like is an overload for more general signatures. Unfortunately,
-this requires that we can infer type and number of arguments and
-return type of <code>operator()</code> at the time we declare the return type of
-above overload of <code>spawn()</code>. I have not found a way to infer this
-information just by using the template parameter <code>C</code> -- it just seems
-not possible. What would work if it were supported by compilers is a
-kind of <code>typeof</code>-operator:
-<code><pre>
-    template &lt;typename C&gt;
-    typeof(spawn(c,&C::operator()))          // **
-    spawn (C &c) {
-      return spawn (c, &C::operator());
-    }
-</pre></code>
-</p>
-<p>
-When seeing the declaration, the compiler would automatically check
-which version of the overloaded <code>spawn()</code> function it would call, and
-correspondingly take the return type. gcc does support the <code>typeof</code>
-keyword, but even present CVS snapshots generate an internal compiler
-error on this construct.
-</p>
-
-<h4>c) Using a memory based scheme rather than condition variables</h4>
-<p>
-The scheme using mutices and condition variables to synchronise
-calling and called thread seems expensive. A simpler approach would be
-to replace it by letting the creating thread generate an object on the
-heap that holds copies of the arguments (instead of references as
-presently), spawn the new thread and just go on without any
-synchronisation.
-</p>
-
-<p>
-The calling thread would then not have to copy the arguments onto its
-local stack and signal to the calling thread. It would only have to
-delete the memory after the call to the user-supplied function
-returns. Apart from replacing <code>ArgReferences</code> by
-<code>ArgList</code> in some places,
-the scheme would basically just replace <code>*_encapsulator::operator()</code>,
-<code>fire_up</code>, and <code>thread_entry_point</code>:
-</p>
-
-<code><pre>
-      thread&lt;RT&gt;
-      operator() (typename boost::tuples::element&lt;0,ArgList&gt;::type arg1) {
-        return (new mem_fun_wrapper&lt;RT,C,ArgList&gt; (mem_fun_ptr, c,
-                                                   boost::tie(arg1)))-&gt;fire_up ();
-      };
-
-      thread&lt;RT&gt; fire_up () {
-        thread_descriptor
-          = DescriptionPointer(new typename detail::thread_description&lt;RT&gt;());
-
-        thread_descriptor-&gt;create (entry_point, (void *)this);
-        // no synchronisation here
-        return thread_descriptor;
-      }
-
-      static void * entry_point (void *arg) {
-        wrapper_base&lt;RT&gt; *w       = reinterpret_cast&lt;wrapper_base&lt;RT&gt;*&gt; (arg);
-        fun_wrapper      *wrapper = static_cast&lt;fun_wrapper*&gt; (w);
-        // no copying here; no synchronisation necessary
-        detail::call (wrapper-&gt;fun_ptr, wrapper-&gt;args,
-                      wrapper-&gt;thread_descriptor-&gt;ret_val);
-        // delete memory
-        delete wrapper;
-        return 0;
-      }
-</pre></code>
-
-<p>
-The perceived simplicity without using mutices and condition variable
-might be deceptive, however, since memory allocation and deallocation
-requires locking and unlocking mutices as well, and is generally not a
-cheap operation.
-</p>
-
-<p>
-However, the main problem is that I get spurious segmentation faults
-with this on my Linux box. These always happen inside the memory
-allocation and deallocation functions in the C++ and C language
-support libraries. I believe that these are not bugs in the
-application, but in the language runtime. However, my motivation to
-debug multithreading problems in the libc is very limited; for
-reference, valgrind 1.94 does not show accesses to uninitialized or
-already freed memory portions, even for runs that eventually crash
-later on.
-</p>
-
-
-<h3>7. Alternative Suggestions</h3>
-
-
-<p>
-Here are some additional suggestions for discussion:
-</p>
-
-<h4>a) Conversions between return values</h4>
-
-<p>
-If <code>f()</code> is a function returning an integer, then the following is
-legal:
-<code><pre>
-    double d = f(arg1, arg2);
-</pre></code>
-The question, then, would be: do we want to allow conversions between
-<code>Thread&lt;double&gt;</code> and <code>Thread&lt;int&gt;</code> objects?
-And do we want to allow a
-conversion from <code>Thread&lt;T&gt;</code> to <code>Thread&lt;void&gt;</code>
-(i.e.: casting away the return value)?
-</p>
-
-<p>
-Since one can still assign the return value of the thread to a double,
-<code><pre>
-    double d = thread.return_value();
-</pre></code>
-the only real merit in allowing conversions is in putting threads with
-different return value types into a <code>ThreadGroup</code>:
-<code><pre>
-    double f1 ();
-    int    f2 ();
-
-    ThreadTroup&lt;double&gt; tg;
-    tg += spawn(f1)();
-    tg += spawn(f2)();    // convert Thread&lt;int&gt; to Thread&lt;double&gt;
-    tg.join_all ();
-</pre></code>
-</p>
-<p>
-Being able to do this is probably only syntactic sugar, except for the
-case where we are not interested in the return values of all threads,
-i.e. the conversion <code>Thread&lt;T&gt; -&gt; Thread&lt;void&gt;</code> seems
-like the only one that is really worth it.
-</p>
-
-<p>
-I have made some initial experiments with implementing general
-conversions. The main problem is that we need to allow conversion
-chains:
-<code><pre>
-    thread&lt;double&gt; t1 = spawn (f)(arg1, arg2);
-    thread&lt;int&gt;    t2 = t1;
-    thread&lt;double&gt; t3 = t2;
-</pre></code>
-</p>
-<p>
-If <code>f()</code> returns 1.5, then <code>t3.return_value()</code> needs to
-return 1.0. I believe that such conversions could be implemented, by adding the
-types in the chain into a <code>boost::tuple</code> of growing length, and writing
-a function that converts a value of the first type of this tuple to
-the second, to the third, ..., to the last type in the tuple. However,
-a plethora of internal compiler errors has scared me off doing more
-experiments in this direction.
-</p>
-
-
-<h4>b) Conversions between class types I</h4>
-
-<p>
-When you have a class hierarchy like
-<code><pre>
-    struct B { void f(); };
-    struct D : public B {};
-</pre></code>
-then calling
-<code><pre>
-    spawn (D(), &B::f);
-</pre></code>
-fails for gcc (but succeeds with Intel's icc). Presumably, gcc is
-right: template arguments must match exactly, and <code>D()</code> is of type
-<code>D</code>, while <code>&B::f</code> leads to a class type of
-<code>B</code>. There is no function template for spawn for which this call can
-match without a derived-to-base conversion. We could now change the template
-<code><pre>
-    template &lt;typename RT, typename C, typename Arg1&gt;
-    mem_fun_encapsulator&lt;RT,C,boost::tuple&lt;Arg1&gt; &gt;
-    spawn (C &c, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator&lt;RT, C, boost::tuple&lt;Arg1&gt; &gt; (c,fun_ptr);
-    }
-</pre></code>
-into
-<code><pre>
-    template &lt;typename RT, typename A, typename C, typename Arg1&gt;
-    mem_fun_encapsulator&lt;RT,C,boost::tuple&lt;Arg1&gt; &gt;
-    spawn (A &a, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator&lt;RT, C, boost::tuple&lt;Arg1&gt; &gt; (a,fun_ptr);
-    }
-</pre></code>
-i.e. introduce another class template <code>A</code> for the type of the
-object. Since the arguments of the constructor to the
-<code>mem_fun_encapsulator</code> object are known, the compiler would perform a
-derived-to-base conversion for object <code>a</code> if necessary. I don't know
-whether this is desirable, in particular since also other conversions
-could happen here that one would not want (in the extreme case
-generating a temporary)..
-</p>
-
-
-<h4>c) Conversions between class types II</h4>
-
-<p>
-When one writes
-<code><pre>
-    spawn (this, &X::f)
-</pre></code>
-one gets an error that "'this' is not convertible to type X&". One has
-to write <code>*this<code> instead. It would be simple to have another set of
-overloads of <code>spawn()</code> that accepts a pointer instead of a reference,
-and simply forwards to the existing function. This is just for the
-lazy people, probably, but it is a common case.
-</p>
-
-
-<h4>d) Catching exceptions</h4>
-
-<p>
-When a function on a new thread throws an exception, it only
-propagates up to one of the two <code>entry_point()</code> functions, then vanishes
-into the run-time system and kills the program. Ideally, we would have
-a way to pass it over to the main thread. This, however, would need
-some support from the language. Basically, we would need two
-operations:
-<ul>
-<li>clone an exception without knowing its type; we could then in the
-  <code>entry_point</code> function catch it and stack it somewhere, just like we
-  do for the return value</li>
-<li>back on the main thread, the <code>Thread::join()</code> function must raise this
-  stored exception if there was one, again without knowing its type.</li>
-</ul>
-Given how exceptions are implemented usually, the machinery for these
-operations is probably there, but is not exported to the user through
-the run-time environment. Thus, an implementation of such ideas has to
-wait for changes in the language specification.
-</p>
-
-
-<HR>
-
-<div ALIGN="RIGHT">
-Wolfgang Bangerth, 2003
-</div>
-<p>&nbsp;</P></BODY>
-</HTML>
-
-
-
-</BODY>
-</HTML>
-

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.