From: maier Date: Mon, 11 Nov 2013 15:51:49 +0000 (+0000) Subject: Move reports over to the homepage X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f54659a95900b9ec7d0629305bbf8e73dfa52f2b;p=dealii-svn.git Move reports over to the homepage git-svn-id: https://svn.dealii.org/trunk@31626 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/reports/assemble/assemble.pdf b/deal.II/doc/reports/assemble/assemble.pdf deleted file mode 100644 index 073d8afaf8..0000000000 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 index 6e0e9669a0..0000000000 --- a/deal.II/doc/reports/assemble/assemble.tex +++ /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 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 local_dof_indices (dofs_per_cell); -\end{verbatim} -The next step is then to loop over all cells: -\begin{verbatim} - typename DoFHandler::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; iget_dof_indices (local_dof_indices); - - for (unsigned int i=0; i}, 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} 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) 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 index 6d1e056206..0000000000 --- a/deal.II/doc/reports/class-hierarchies/1d-dof.fig +++ /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 index d443b95dac..0000000000 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 index 5670f0c8ea..0000000000 --- a/deal.II/doc/reports/class-hierarchies/1d-tria.eps +++ /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 index 3f46e3c583..0000000000 --- a/deal.II/doc/reports/class-hierarchies/1d-tria.fig +++ /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 index c074ca3b8c..0000000000 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 index 6d185a71a1..0000000000 --- a/deal.II/doc/reports/class-hierarchies/2d-dof.eps +++ /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 index ba45b2c4b9..0000000000 --- a/deal.II/doc/reports/class-hierarchies/2d-dof.fig +++ /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 index caf1cc2217..0000000000 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 index ec95b92e0d..0000000000 --- a/deal.II/doc/reports/class-hierarchies/2d-tria.eps +++ /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 index b5276f025b..0000000000 --- a/deal.II/doc/reports/class-hierarchies/2d-tria.fig +++ /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 index 93a7c4dfe8..0000000000 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 index 7dffc7bcab..0000000000 --- a/deal.II/doc/reports/class-hierarchies/3d-dof.eps +++ /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 index fc810f6e1a..0000000000 --- a/deal.II/doc/reports/class-hierarchies/3d-dof.fig +++ /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 index b69962dbfe..0000000000 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 index 75ea1372b8..0000000000 --- a/deal.II/doc/reports/class-hierarchies/3d-tria.eps +++ /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 index 784a1a4b70..0000000000 --- a/deal.II/doc/reports/class-hierarchies/3d-tria.fig +++ /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 index 6aa0d0b821..0000000000 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 index f2c3ac547e..0000000000 --- a/deal.II/doc/reports/class-hierarchies/index.html +++ /dev/null @@ -1,996 +0,0 @@ - - - - - The deal.II Homepage - - - - - - -

-Description of the C++ class hierarchy for the -accessor classes -

- - -

- Wolfgang Bangerth, 1998, 1999, 2000 -

- - -

-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. -

- -

-Furthermore, it lists the member functions that can be queried to -obtain information from an iterator. -

- - -Table of contents - - - - -

-What iterators and accessors are -

- -

-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). -

- -

-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. -

- -

-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 --> 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 list<T> 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. -

- -

-Additionally, there are different versions of the iterators which -behave differently when being incremented or decremented: while -raw iterators let the associated accessor point to any of the -objects it is made for, normal 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. -

- -

-Finally, there are active 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. -

- - - - -

-The triangulation accessor hierarchy -

- -

-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: -

    -
  • TriaAccessor<dim> is a general base class - which is of not much interest. -
  • TriaObjectAccessor<objectdim,spacedim> denotes - an accessor for an object with dimension - objectdim in a spacedim dimensional - space. It is derived from TriaAccessor<spacedim>. -
  • CellAccessor<dim> presents the special - properties that a cell has. It is therefore derived from - TriaObjectAccessor<spacedimdim,spacedim>. -
-

- -

-Their inheritance trees in the different space dimensions therefore -look like this: -

- -
- -
- -
-

- -

- -
- -
-

- -

- -
- -
-

- -

- -

-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. -

- - - - -

-Typedefs of the Triangulation class to iterators and accessors -

- -

-The Triangulation<1> class declares the following data -types which involve accessors: -

-    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; 
-
-Since lines are cells in one space dimension, all line iterators are -cell iterators as well. -

- -

-In two space dimensions, the following types are declared by the -Triangulation<2> class: -

-    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;    
-
-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. -

- - -

-In three space dimensions, the following types are declared by the -Triangulation<3> class: -

-    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;    
-
-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. -

- - - - -

Functions offered by triangulation accessors

- -

-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 -API -documentation of the `grid' classes. These functions can be -accessed by iterator->function() if iterator -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. -

- -
-
- level () -
- -
- Return the hierarchical refinement level on - which this object lives. -
- - -
- index () -
- -
- Return the index within the hierarchical refinement level on - which this object lives. -
- - -
- get_triangulation () -
- -
- Return a reference to the triangulation to which this object belongs. -
- - -
- vertex_index (vertex_number) -
- -
- Return the global index of one of the vertices of this object. -
- - -
- vertex (vertex_number) -
- -
- Return the position of the respective vertex in space. -
- - -
- used () -
- -
- Return whether the object is used. The return value is - true for all iterators that are either normal iterators - or active iterators, only raw iterators can return - false. Since raw iterators are only used in the - interiors of the library, you will not usually need this function. -
- - -
- set_used () / clear_used () -
- -
- Set or clear the flag that describes whether the object is used by - the triangulation. Only for internal use. -
- - -
- user_flag_set () -
- -
- Return whether the user flag is set. -
- - -
- set_user_flag () / clear_user_flag () -
- -
- Set or clear the flag that might be used by a user to indicate that - something should happen with this object. -
- - -
- recursively_set_user_flag () / recursively_clear_user_flag () -
- -
- Set or clear the user flag for this cell and all its descendants. -
- - -
- user_pointer () -
- -
- Query the pointer belonging to this object which may be used by - the user to store additional information with this object. -
- - -
- set_user_pointer () / clear_user_pointer () -
- -
- Set or clear a pointer belonging to this object which may be used by - the user to store additional information with this object. -
- - -
- child (child_number) -
- -
- Return an iterator to one of the children of this object. -
- - -
- child_index (child_number) -
- -
- Return the index of the child within the next finer level of the - triangulation. -
- - -
- set_children (index), clear_children () -
- -
- Only for internal use. -
- - -
- has_children () -
- -
- Return whether an object has children, i.e. whether it is further - refined. If it has children, then it is not active. -
- - -
- max_refinement_depth () -
- -
- Return how often this cell or one of its children is refined. -
- - -
- boundary_indicator -
- -
- Return the number of the boundary at which this object lies, if the - object has a dimension less than the space dimension. -
- - -
- set_boundary_indicator (boundary_id) -
- -
- Set the number of the boundary to which this object belongs. -
- - -
- at_boundary () -
- -
- 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. -
- - -
- has_boundary_lines () -
- -
- Return whether one of the lines bounding this cell is at the - boundary. For 1d and 2d this is equivalent to at_boundary, - 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.) -
- - -
- diameter () -
- -
- Return the diameter of the object. -
- - -
- center () -
- -
- Return the coordinates of the center of the object. -
- - -
- barycenter () -
- -
- Return the coordinates of the barycenter of the object. -
- - -
- measure () -
- -
- Return the length, area, or volume of an object, depending on the - dimension of the object. -
- - -
- point_inside (point) -
- -
- 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.) -
- - -
- number_of_children () -
- -
- Accumulated number of children and their children. -
- - -
- line (line_number) -
- -
- Return an iterator to one of the bounding lines of this object. (Only - for iterators to quadrilaterals and hexahedra.) -
- - -
- line_index (line_number) -
- -
- 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.) -
- - -
- quad (quad_number) -
- -
- Return an iterator to one of the bounding quadrilaterals of this - object. (Only for iterators to hexahedra.) -
- - -
- line_index (line_number) -
- -
- 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.) -
- - -
- neighbor (neighbor_number) -
- -
- Return iterator to one of the neighbors. (Only for cell iterators.) -
- - -
- neighbor_index (neighbor_number) / neighbor_level (neighbor_number) -
- -
- Return number and level of one of the neighbors. (Only for cell - iterators.) -
- - -
- set_neighbor () -
- -
- Set a neighbor. Only for internal use. (Only for cell iterators.) -
- - -
- neighbor_of_neighbor (neighbor_number) -
- -
- Return the how-manyth neighbor the present cell is of the neighbor - specified by the argument. (Only for cell iterators.) -
- - -
- at_boundary (face_number) -
- -
- Return whether this cell's given face is at the boundary. (Only for - cell iterators.) -
- - -
- refine_flag_set () -
- -
- Return whether the refinement flag is set or not for the present - cell. (Only for cell iterators.) -
- - -
- set_refine_flag () / clear_refine_flag () -
- -
- Set/clear the flag indicating refinement. (Only for cell iterators.) -
- - -
- coarsen_flag_set () -
- -
- Query whether the flag indicating coarsening is set for this - object. (Only for cell iterators.) -
- - -
- set_coarsen_flag () / claer_coarsen_flag () -
- -
- Set/clear the flag indicating coarsening. (Only for cell iterators.) -
- - -
- face (face_number) -
- -
- Return an iterator to one of the faces of this cell, if dimension is - greater than one. (Only for cell iterators.) -
- - -
- material_id () -
- -
- Return the material number of this cell. (Only for cell iterators.) -
- - -
- set_material_id (id) -
- -
- Set the material number of this cell. (Only for cell iterators.) -
- - -
- active () -
- -
- Return whether this cell is active, i.e. has no children. (Only for - cell iterators.) -
-
- - - - -

-The degree of freedom accessor hierarchy -

- -

-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. - -

- -
- -
-

- - -

- -
- -
-

- - -

- -
- -
-

- -

- -

-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. -

- -

-For the named reason, it is necessary to derive the -DoFObjectAccessor<1,dim> from the -TriaObjectAccessor<1,dim> class of the -triangulation accessor hierarchy, as well as the -DoFObjectAccessor<2,dim> from the -TriaObjectAccessor<2,dim>. 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 DoFObjectAccessor<1,1> is derived from -CellAccessor<1>, while when in higher dimensions, it is derived -from DoFObjectAccessor<1,dim>; the same applies for -the DoFObjectAccessor<2,dim> 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. -

- - - -

-Typedefs of the DoFHandler class to iterators and accessors -

- -

-The typedefs done by the DoFHandler class are much alike those done by -the Triangulation class. They could be summarized as follows: -

- -

-For one space dimension: -

-    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; 
-
-Since lines are cells in one space dimension, all line iterators are -cell iterators as well. -

- -

-For two space dimensions: -

-    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;    
-
-

- -

-For three space dimensions: -

-    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;    
-
-

- - - - -

Functions offered by degree of freedom accessors

- -

-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 -API -documentation of the `DoF' classes. -

- - -
-
- dof_index (dof_number) -
- -
- Return the global index of one of the DoFs on this object. -
- - -
- set_dof_index (dof_number, index) -
- -
- Set the index of a DoF. Only for internal use. -
- - -
- vertex_dof_index (vertex_number, dof_number) -
- -
- Return the index of one of the DoFs on one of the vertices of this - object. -
- - -
- set_vertex_dof_index (...) -
- -
- Set the vertex DoF index. Only for internal use. -
- - -
- get_dof_indices (vector_of_indices) -
- -
- Return a vector of the indices of the DoFs on this object. -
- - -
- get_dof_values (global_values, local_values) -
- -
- Extract and return the values of the DoFs on this object from a data - vector defined on all DoFs. -
- - -
- set_dof_values (local_values, global_values) -
- -
- Reverse operation: take values of DoFs on this object, and set them - into a global data vector. -
- - -
- distribute_local_to_global (local_source, global_destination) -
- -
- 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. -
- - -
- get_interpolated_dof_values (global_values, local_interpolation) -
- -
- 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.) -
- - -
- set_dof_values_by_interpolation (local_values, global_interpolation) -
- -
- 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.) -
-
- - -
- -
-Wolfgang Bangerth, 1998, 1999, 2000 -
-

 

- - - - - - - 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 index d64a5e5bc0..0000000000 Binary files a/deal.II/doc/reports/codimension-one/desimone-heltai-manigrasso.pdf and /dev/null differ diff --git a/deal.II/doc/reports/index.html b/deal.II/doc/reports/index.html index 025527d4c7..9a2246b474 100644 --- a/deal.II/doc/reports/index.html +++ b/deal.II/doc/reports/index.html @@ -24,7 +24,7 @@
  • A brief report about the classes involved in the - iterators and accessors used to access cells in the triangulations and the data thereon, such as their geometry, the number of the @@ -35,7 +35,7 @@
  • - A brief report on mapping functions of higher polynomial degrees (by Ralf Hartmann). These allow the realisation of higher order boundary approximations. This report @@ -45,7 +45,7 @@
  • A report on - assembling matrices (by Wolfgang Bangerth). This report looks in particular at how matrices are assembled for vector-valued problems, and @@ -57,7 +57,7 @@
  • A very detailed report on - Nedelec elements (by Anna Schneebeli, University of Basel, Switzerland). It explains the construction and application of Nedelec @@ -68,7 +68,7 @@
  • A report on the - codimension one 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 index 3afa2db8d0..0000000000 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 index f1b1253237..0000000000 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 index f3a7034453..0000000000 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 index 7e40605864..0000000000 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 index c7a3aeaac1..0000000000 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 index e9c184cb6e..0000000000 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 index 0bab0d582f..0000000000 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 index 655453fbd7..0000000000 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 index d16cfa2bcf..0000000000 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 index 273a7d4f6a..0000000000 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 index 7254199946..0000000000 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 index 91c5ff7155..0000000000 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 index 55356960d2..0000000000 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 index 0398f353ff..0000000000 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 index de29603058..0000000000 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 index af5f661ee6..0000000000 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 index 8725fa85d8..0000000000 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 index 4a18c7e7be..0000000000 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 index 3a9ba08d64..0000000000 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 index 99087f0b31..0000000000 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 index 707c7df44a..0000000000 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 index edd5bfb79a..0000000000 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 index 55356960d2..0000000000 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 index cd04d32788..0000000000 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 index e9a9003034..0000000000 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 index 38306f0b72..0000000000 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 index b8d2b5021c..0000000000 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 index aea6c3eed7..0000000000 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 index 2dbcd8168b..0000000000 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 index f8bfdf0abe..0000000000 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 index 65d5c0741f..0000000000 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 index 231b0e86a1..0000000000 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 index ff944c6f4e..0000000000 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 index 3ebda319e9..0000000000 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 index b4a8f2ab8f..0000000000 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 index d95a0f01c1..0000000000 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 index d28a084615..0000000000 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 index b3d5a1a909..0000000000 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 index 86cc1179d7..0000000000 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 index 09dcfea500..0000000000 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 index 1e1590e8a6..0000000000 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 index 0239071c22..0000000000 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 index 15674c4a25..0000000000 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 index ad5cc2d73e..0000000000 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 index 95d2ce653d..0000000000 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 index 6f0caf54da..0000000000 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 index fd296a61dc..0000000000 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 index 2d477dab17..0000000000 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 index 18070cf724..0000000000 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 index 91c5ff7155..0000000000 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 index 5e6633a055..0000000000 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 index 487a4d79de..0000000000 --- a/deal.II/doc/reports/mapping_q/index.html +++ /dev/null @@ -1,867 +0,0 @@ - - - - -No Title - - - - - - - - - -

    -In modified form taken from -
    -
    -Ralf Hartmann -
    -Adaptive Finite Element Methods for the Compressible Euler Equations -
    -PhD thesis, University of Heidelberg, 2002. -

    - - -

    -

    -Higher order Boundary approximation - -
    -

    -Introduction: In many numerical applications the domain - - -$\Omega\subset\mathbb R^d$, -$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 $\hat K$ -to the element - - -$K=\sigma_K(\hat K)$ -in real space, whereas on cells K at the -boundary, i.e. - -$\partial K\cap\Gamma=\emptyset$, -the mappings -$\sigma_K$ -are given by polynomial functions of higher degree. - -

    -Elements with general mapping functions $\sigma_K$. We begin -by first introducing some notation. Let $K\in T_h$ -be a cell of the -triangulation Th with - -$K=\sigma_K(\hat K)$, -where $\sigma_K$is a smooth bijective mapping of the reference element (unit square) -$\hat K$ -to the element K in real space, see Figure -1. -
    -

       - - - -
    Figure: -Mapping $\sigma $ -of reference element $\hat K$ -to the element K in real space.
    -
    - - -\includegraphics[scale=0.3]{figures/m1.ps}
    -
    -
    -

    -In the following and for the sake of simplicity we suppress the letter -K in the subscript and write $\sigma $ -instead of $\sigma_K$. - -

    -Mapping functions of higher polynomial degree. A mapping -function $\sigma $, -that maps the reference element $\hat K$ -to an -arbitrary quadrilateral cell K with straight boundaries, can in -general be represented by a bilinear function, i.e. by a -Q1-mapping. For the case that the cell K includes curved -boundaries it might be necessary to employ polynomial mapping -functions of higher degree. - -

    -Given a degree p>0, a cell $K\in T_h$, -and (p+1)d mapping -support points $p_i\in K$, - - -$i=0,\ldots,(p+1)^d-1$, -we define a -Qp-mapping - -$\sigma\in [Q_p]^d$ -as follows -

    -
    - - - - - - -
     \begin{displaymath} -\sigma(\hat x)=\sum_{i=0}^{(p+1)^d-1}p_i\phi_i(\hat x). -\end{displaymath} -(1)
    -
    -

    -Here, $\phi_i$, - - -$i=0,\ldots,(p+1)^d-1$ -denote the Lagrange interpolation -basis functions, that satisfy -

    -
    - - - -\begin{displaymath}\phi_i(\hat p_j)=\delta_{ij}, \quad i,j=0,\ldots,(p+1)^d-1, -\end{displaymath} -
    -
    -

    -where $\hat p_i$, - - -$i=0,\ldots,(p+1)^d-1$ -denote the Lagrange support -points on the unit cell $\hat K$. -The definition of $\sigma $(1) ensures that each of the unit support points -$\hat p_i$ -is mapped onto the corresponding mapping support points -pi, i.e. -

    -
    - - - - - - -
     \begin{displaymath} -\sigma(\hat p_i)=p_i, \quad i=0,\ldots,(p+1)^d-1 -\end{displaymath} -(2)
    -
    -

    -Analogous to Lagrange finite elements the unit Lagrange support points -$\hat p_i$ -are equidistantly distributed on $\hat K$ -based on a tensor -product mesh. In the following we only consider the two-dimensional -case, d=2. For that case, Figure 2 -shows the distributions of the unit support points $\hat p_i$, - - -$i=0,\ldots,(p+1)^2-1$ -for degrees - -$p=1,\ldots ,4$. -
    -
       - - - -
    Figure: -Unit support points $\hat p_i$, - - -$0\leq i<(p+1)^2$, -for degrees - -$p=1,\ldots ,4$.
    -
    - - -\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q1_n.eps} - - -\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q2_n.eps} - - -\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q3_n.eps} - - -\includegraphics*[width=2.750cm]{../../../phd/figures/boundary_approximation/mapping/unit_points_q4_n.eps}
    -
    -
    -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 -2. Thus the first 4p points are placed -on the boundary - -$\partial\hat K$ -of the reference cell, i.e. -

    -
    - - - -\begin{displaymath}\hat p_k\in\partial\hat K, \quad k=0,\ldots,4p-1. -\end{displaymath} -
    -
    -

    -According to (2) these points are mapped to the -mapping support points pk, - -$k=0,\ldots,4p-1$ -that are chosen to be -placed on the boundary of the real cell in approximatively equal -distances, i.e. -

    -
    - - - -\begin{displaymath}p_k\in\partial K, \quad k=0,\ldots,4p-1. -\end{displaymath} -
    -
    -

    -While the support points pk, - -$k=0,\ldots,4p-1$ -on the boundary are -given by the boundary description of the real cell K, the inner - mapping support points -

    -
    - - - -\begin{displaymath}p_i\in K\setminus\partial K, \quad i=4p,\ldots,(p+1)^2-1 -\end{displaymath} -
    -
    -

    -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 $\sigma $ -for a cell K may degenerate, i.e. the -mapping $\sigma $ -for some cell K may not be bijective. - -

    -Computation of inner support points by smooth transformation. -In the following we will define the positions of the inner mapping -support points so that the mapping does - in all practical cases - not -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. - -

    -The smooth transformation mentioned above is based on solutions to the -Laplace equation that is solved on the reference cell $\hat K$. -Discrete boundary conditions are imposed that are given by the -coordinates of the mapping support points pk, - -$k=0,\ldots,4p-1$, -on -the boundary of the cell K in real space. - -

    -To be more explicite we define a Laplace problem on the unit -cell $\hat K$ -

    -
    - - - - - - -
     \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} -(3)
    -
    -

    -for each component $\sigma_l$, -l=1,2, of the Qp mapping -$\sigma $. -Here, the discrete boundary function - -$g\in [Q_p]^2$ -is -given by -

    -
    - - - - - - -
     \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} -(4)
    -
    -

    -where (pi)l denotes the lth component of the support point pi, -and $\phi_i$ -the corresponding Lagrangian interpolation basis -function. We recall that the numbering of the mapping support points -involves - -$p_k\in\partial K$ -for - -$k=0,\ldots,4p-1$. -Substituting -

    -
    - - - - - - -
     \begin{displaymath} -\tilde \sigma_l:=\sigma_l-g_l, \quad l=1,2, -\end{displaymath} -(5)
    -
    -

    -into the Laplace problem (3) yields the -zero boundary value problem, -

    -
    - - - - - - -
     \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} -(6)
    -
    -

    -that is equivalent to the following variational formulation -

    -
    - - - -\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} -
    -
    -

    -Discretisation of this problem -

    -
    - - - -\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} -
    -
    -

    -and recalling definitions (1), (5) and (4) gives -

    -
    - - - - - - -
     \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} -(7)
    -
    -

    -with the matrices - -$S_{ij}\in\mathbb R^{(p-1)^2\times(p-1)^2}$ -and - -$T_{ik}\in\mathbb R^{(p-1)^2\times 4p}$ -given by -

    -
    - - - -\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} -
    -
    -

    -and -

    -
    - - - -\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} -
    -
    -

    -The solutions to problem (7) for l=1,2 are -

    -
    - - - -\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} -
    -
    -

    -that may be written in compact form: -

    -
    - - - - - - -
     \begin{displaymath} -p_{4p+j}=\sum_{k=0}^{4p-1}c_{jk}p_k, \quad j=0,\ldots,(p-1)^2-1, -\end{displaymath} -(8)
    -
    -

    -where cjk represents the coefficient -

    -
    - - - - - - -
     \begin{displaymath} -c_{jk}=-\sum_{i=0}^{(p-1)^2-1}S^{-1}_{ji}T_{ik}. -\end{displaymath} -(9)
    -
    -

    -of the linear combination (8), that -represents the dependency of the jth inner mapping support point -p4p+j on the support points pk, - -$k=0,\ldots,4p-1$, -that are -placed on the boundary of the cell K. For a fixed degree p, these -coefficients cjk are the same for the mapping of all cells -K in real space because the cjk depend only on the reference -element $\hat K$. -Therefore the coefficients cjk can be -precomputed and result in following linear combinations: - -

    -For p=2 the linear combination turns out to be -

    -
    - - - -\begin{displaymath}p_8=\tfrac{1}{16}\sum_{k=0}^3p_k+\tfrac{3}{16}\sum_{k=4}^7p_k, -\end{displaymath} -
    -
    -

    -see also Figure 3, left. -
    -
       - - - -
    Figure 3: -Left: Coefficients c8,k for Q2 mapping. Right: Coefficients c12,k for Q3 mapping.
    -
    - - -\includegraphics*[scale=0.4]{figures/m2.ps}
    -
    -
    -For the case that p=3, Figure 3, right, shows the coefficients c12,k of the linear combination for the inner mapping support point p12. The coefficents for the points p13, p14 and p15 can be obtain by rotation of the coefficients. - -

    -Implementation in deal.II. The coefficients cjk, see -(9), are represented in the MappingQ -class by the laplace_on_quad_vector as follows -

    -
    - - - -\begin{displaymath}\mbox{\textit{laplace\_on\_quad\_vector}[j][k]}=c_{jk} -\end{displaymath} -
    -
    -

    -These coefficients are the same for the mapping of all cells -K in real space because the cjk depend only on the reference -element $\hat K$. -Hence for a given degree p the -laplace_on_quad_vector can be filled by the constructor of -the MappingQ class. This is done by calling the -MappingQ::set_laplace_on_quad_vector function that -includes the coefficients hardcoded for p=2 and p=3 in d=2 dimensions, and a routine for computing the coefficients according to -(9) for all other cases. The mapping support -points $p_i\in K$, - - -$i=0,\ldots,(p+1)^d-1$ -are computed once for each -MappingQ object by the -MappingQ::compute_support_points_laplace that is invoked -by the virtual compute_mapping_support_points function of -the base Mapping class. In -MappingQ::compute_support_points_laplace, first the 4p points on the boundary of the cell are computed (by calling -MappingQ::add_line_support_points), then by calling -MappingQ::apply_laplace_vector the remaining (p-1)2 inner mapping supports points are computed, where -MappingQ::apply_laplace_vector just performs the linear -combination given in (8). -
    - -
    -Ralf Hartmann -
    2001-09-03 -
    - - diff --git a/deal.II/doc/reports/nedelec/nedelec.pdf b/deal.II/doc/reports/nedelec/nedelec.pdf deleted file mode 100644 index 1ed9f2effa..0000000000 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 index b146117901..0000000000 --- a/deal.II/doc/reports/new-threads/index.html +++ /dev/null @@ -1,1059 +0,0 @@ - -

    -A short description of the new threading scheme -

    - - -

    - Wolfgang Bangerth, May 2003 -

    - - -

    -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. -

    - -

    -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. -

    - - -

    1. Rationale and Introduction

    - - -

    -POSIX and other thread libraries only allow functions as thread entry -points that satisfy the signature -

    -  void *  (*)  (void *)
-
    -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. -

    - -

    -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. -

    - -

    -However, the old scheme had a number of shortcomings: -

      -
    • The implementation did not allow for functions returning - anything but void. We want to be able to call everything - on a new thread that can also be called on the present one.
      • -
    • 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.
      • -
    • The general syntax for calling a function on a new thread was a - little clumsy and not intuitive.
      • -
    -

    - -

    -Regarding the last point, note that any other function is called by -

    -    f(arg1, arg2);
-    obj.f(arg1, arg2);
-
    -Ideally, the following syntax for starting any function on a new -thread would be nice: -
    -    spawn f(arg1, arg2);
-    spawn obj.f(arg1,arg2);
-
     -This syntax is not possible in C++, but the following syntax is, -making it relatively clear what the intent of the statement is: -
    -    spawn (f)(arg1, arg2);
-    spawn (obj, &Class::f)(arg1,arg2);
-
     -This is the syntax we will want to achieve (except for the fact that the -spawn function is in a namespace Threads, just like -all other entities described here). -

    - -

    -This text will discuss the details that are needed to implement -this syntax, as well as the following points: -

      -
    • Overloading spawn() 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).
      • -
    • spawn() needs to return a value that allows us to identify, -and join a thread. The syntax for this will be -
      -      Thread<> t = spawn(f)(arg1, arg2);
-      t.join ();
-
       - If we don't save the return value of spawn(), as in the examples - above, then we have just created a detached thread.
      • -
    • Return values: if f() returns a value, say, an integer, then -we want to be able to retrieve it once the thread has finished: -
      -      Thread<int> t = spawn (f)(1., 1.);
-      t.join ();
-      int i = t.return_value ();
-
       - This requires some care when functions return references, but some - template magic will save us. Another special case are functions that - return void.
      • -
    • Thread groups: if threads are created inside a loop, we will want to - put all of them into a ThreadGroup object, and wait for them - collectively, rather than one-by-one.
      • -
    -

    - -

    -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 use it, but should explain in -reasonable detail how it works. 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. -

    - - -

    -This paper is divided into the following parts: -

      -
    1. This introduction
      2. -
    2. Entities (functions, classes) that are used by both and that - describe the newly created thread
      3. -
    3. Entities that are used on the calling thread
      4. -
    4. Entities that are used to create a thread
      5. -
    5. Tool classes
      6. -
    6. Open problems
      7. -
    7. Further suggestions
      8. -
    -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 -internal, those to be used are in a namespace -Threads. 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. -

    - - - -

    2. Entities that describe threads

    - - -

    -Each thread that has been created is described by exactly one object -of type thread_description<RT>, where RT here and in the -sequel will always denote the return type of the function being called -on a new thread. The thread_description 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: -

    - -
    -    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;
-        };
-    };
-
     - -

    -join() can be called more than once and uses Schmidt's thread-safe -double-checking pattern for speed. There could be additional functions -kill() or send_signal(), but these are not presently -implemented. -

    - -

    -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. -

    - -

    -The thread_description<RT> class is derived from this base -class: -

    -    template <typename RT>
-    struct thread_description : public thread_description_base
-    {
-        return_value<RT> ret_val;
-    };
-
    -

    - -

    -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 return_value -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. -

    - -

    -As mentioned, there is exactly one thread_description<RT> -object per created thread. It is accessed using boost::shared_ptr -objects, and references are held from each Thread<RT> object -for this thread as -well as from a wrapper function on the new thread. The object is thus -deleted, when all Thread<RT> 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. -

    - - - -

    3. Entities that are used on the calling thread

    - - -

    -On the calling thread, we basically use the Thread<RT> -class, ThreadGroup<RT> class, and spawn -function. The Thread<RT> class has the following -implementation: -

    - -
    -    template <typename RT = void>
-    class Thread {
-      public:
-        Thread () {};
-        Thread (const boost::shared_ptr<thread_description<RT> > &td)
-          : thread_description (td) {};
-
-        void join () const { thread_description->join (); };
-
-        RT return_value () {
-          join ();
-          return thread_description->ret_val.get();
-        };
-
-        bool operator == (const thread &t) {
-          return thread_description == t.thread_description;
-        };
-
-      private:
-        boost::shared_ptr<thread_description<RT> > thread_description;
-    };
-
     - -

    -Copy constructor and operator= are generated automatically by the -compiler. Note that asking for the return_value automatically waits -for the thread to finish, and that for this it is helpful that we can -call join() more than once on the thread description object. The -return_value() function also makes use of the fact that if RT=void, -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 void. -

    - -

    -The ThreadGroup class is a container distributing calls to its -member functions to all its elements. Elements are added using -operator+=, and they are stored using a -std::vector. (A std::set would be more appropriate, -but then we would have to have operator< for -Thread<RT> objects.) It has the same default value for the -template argument: -

    - -
    -    template <typename RT = void>
-    class ThreadGroup
-    {
-      public:
-        ThreadGroup & operator += (const Thread<RT> &t) {
-          threads.push_back (t);
-	  return *this;
-        };
-
-        void join_all () const {
-          for (typename std::vector<Thread<RT> >::const_iterator
-                 t=threads.begin(); t!=threads.end(); ++t)
-            t->join ();
-        };
-
-      private:
-        std::vector<Thread<RT> > threads;
-    };
-
     - -

    -Since objects of type Thread<RT> are freely copyable, there -is no need -to provide an index operator for ThreadGroup; if you need to index -its elements (for example to get at the return value), use -std::vector<Thread<RT> >. -

    - -

    -Finally, there are overloads of the spawn template, for unbound -functions, as well as const and non-const member -functions. We only show them for unary member functions: -

    -    template <typename RT, typename C, typename Arg1>
-    mem_fun_encapsulator<RT,C,boost::tuple<Arg1> >
-    spawn (C &c, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator<RT, C, boost::tuple<Arg1> > (c,fun_ptr);
-    }
-
-    template <typename RT, typename C, typename Arg1>
-    mem_fun_encapsulator<RT,const C,boost::tuple<Arg1> >
-    spawn (const C &c, RT (C::*fun_ptr)(Arg1) const) {
-      return mem_fun_encapsulator<RT, const C, boost::tuple<Arg1> > (c,fun_ptr);
-    }
-
    -

    - -

    -Note that we need two overloaded versions, for const and -non-const -member functions. Both create an intermediate object (in the -internal -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. -

    - -

    -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 -operator(). However, this doesn't seem to be possible if -operator() returns something other than void or takes -arguments. This -would need some kind of typeof-operator which is not standard C++. See the -discussion in the Open Problems section. -

    - - -

    4. Entities that are used to create a thread

    - - -

    -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 use the spawn() functions, -so are probably boring and may be skipped. -

    - -

    -The basic idea is the following: spawn() 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. mem_fun_encapsulator -looks like this: -

    - -
    -    template <typename RT, typename C, typename ArgList,
-              int length = boost::tuples::length<ArgList>::value>
-    class mem_fun_encapsulator;
-
-    template <typename RT, typename C, typename ArgList>
-    class mem_fun_encapsulator<RT,C,ArgList,1> {
-        typedef typename mem_fun_ptr<RT,C,ArgList>::type MemFunPtr;
-
-      public:
-        mem_fun_encapsulator (C &c, MemFunPtr mem_fun_ptr)
-            : c (c), mem_fun_ptr(mem_fun_ptr) {};
-
-        Thread<RT>
-        operator() (typename boost::tuples::element<0,ArgList>::type arg1) {
-            return mem_fun_wrapper<RT,C,ArgList> (mem_fun_ptr, c,
-                                                  boost::tie(arg1)).fire_up ();
-        };
-
-      private:
-        C         &c;
-        MemFunPtr  mem_fun_ptr;
-    };
-
     - -

    -(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.) -

    - -

    -The constructor stores the two addresses. If one calls -

    -    spawn(obj, &C::f) (42);
-
    -the next thing that is invoked is the operator() of this class. It -takes the argument(s), creates a temporary with the two addresses and -a reference to the argument (that's what boost::tie) does, and calls -fire_up() on this temporary. fire_up 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 boost::tie, so that we need -not have different versions of the mem_fun_wrapper class for different -numbers of arguments. (However, we need a separate partial -specialization of the mem_fun_encapsulator class for each number of -function arguments.) The tie_args template is used to make a version -of the ArgList type with all reference types; it is described below. -

    - -

    -The next question, of course, is how mem_fun_wrapper looks like. Let -us first consider the base class that it has in common with -fun_wrapper, the wrapping class for non-member function objects: -

    -    template <typename RT, typename EntryPointClass>
-    struct wrapper_base {
-        Thread<RT> fire_up () {
-          thread_descriptor
-            = DescriptionPointer(new typename thread_description<RT>());
-
-          boost::mutex::scoped_lock lock (mutex);
-          thread_descriptor->create (&EntryPointClass::entry_point,
-                                        (void *)this);
-          condition.wait (lock);
-
-          return thread_descriptor;
-        }
-
-      protected:
-        typedef boost::shared_ptr<thread_description<RT> >
-        DescriptionPointer;
-
-        DescriptionPointer thread_descriptor;
-
-        mutable boost::mutex     mutex;
-        mutable boost::condition condition;
-    };
-
    -

    -fire_up 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 EntryPointClass::entry_point, where -EntryPoint is the name of a class that implements this thread -starting function and is passed as a template argument to -wrapper_base. -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 Thread<RT> -object. -

    - -

    -The magic happens in the derived class: -

    -    template <typename RT, class C, typename ArgList>
-    struct mem_fun_wrapper
-       : public wrapper_base<RT, mem_fun_wrapper<RT,C,ArgList> >
-    {
-        typedef typename mem_fun_ptr<RT,C,ArgList>::type MemFunPtr;
-        typedef typename tie_args<ArgList>::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<RT> *w
-              = reinterpret_cast<const wrapper_base<RT>*> (arg);
-            const mem_fun_wrapper *wrapper
-              = static_cast<const mem_fun_wrapper*> (w);
-            MemFunPtr mem_fun_ptr = wrapper->mem_fun_ptr;
-            C        &c           = wrapper->c;
-            ArgList   args        = wrapper->args;
-
-            boost::shared_ptr<thread_description<RT> >
-              thread_descriptor  = wrapper->thread_descriptor;
-
-            {
-              boost::mutex::scoped_lock lock (wrapper->mutex);
-              wrapper->condition.notify_one ();
-            }
-
-            call (mem_fun_ptr, c, args, thread_descriptor->ret_val);
-
-            return 0;
-          };
-    };
-
    -

    - -

    -Note in particular, how this class passes itself as second template parameter -to the base class, enabling the latter to call the -mem_fun_wrapper::entry_point 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 -wrapper_base object. The first thing the entry_point 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 shared_ptr 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 fire_up 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. -

    - - -

    5. Tool classes

    - - -

    -In the implementation above, some tool classes have been used. These -are briefly described here. -

    - -

    a) The return_value<T> class template

    - -

    -This class stores a value of type T if T is not a -reference or void. It offers get() and -set() functions that get and set the value. If T is a -reference type, then set() is obviously not possible since -references cannot be rebound after construction time. The class therefore -stores a pointer, and set() sets the pointer to the object the -reference references. get() then returns the reference again. If -T is void, then the class is empty and there is only -a get() function that returns void. -

    - -
    -    template <typename RT> struct return_value
-    {
-      private:
-        RT value;
-      public:
-        RT get () const { return value; }
-        void set (RT v) { value = v; }
-    };
-
-    template <typename RT> struct return_value<RT &>
-    {
-      private:
-        RT * value;
-      public:
-        RT & get () const { return *value; }
-        void set (RT & v) { value = &v; }
-    };
-
-    template <> struct return_value<void> {
-        static void get () {};
-    };
-
     - - -

    b) The call function templates

    - -

    -The call 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: -

    - -
    -    template <int> struct int2type;
-
-    template <typename RT, typename PFun, typename ArgList>
-    static void call (PFun     fun_ptr,
-                      ArgList &arg_list,
-                      return_value<RT> &ret_val)
-    {
-      Caller<RT>::do_call (fun_ptr, arg_list, ret_val,
-                           int2type<boost::tuples::length<ArgList>::value>());
-    };
-
     - -

    -The Caller class has the following member functions: - -

    -    template <typename RT> struct Caller
-    {
-        template <typename PFun, typename ArgList>
-        static void do_call (PFun     fun_ptr,
-                             ArgList &arg_list,
-                             return_value<RT> &ret_val,
-                             const int2type<1> &)
-        {  ret_val.set ((*fun_ptr) (arg_list.template get<0>()));  };
-
-        // likewise for int2type<0>, int2type<2>, ...
-    };
-
    -

    - - -

    -There is a specialization Caller<void> that does not set a return -value, and for each call and do_call function there is a second -function for member function pointers that takes an object as -additional argument. -

    - - -

    c) mem_fun_ptr

    - -

    -In order to form a pointer to member function for both cases of const -and non-const member functions, we need a simple tool: -

    -    template <typename RT, class C, typename ArgList,
-              int length = boost::tuples::length<ArgList>::value>
-    struct mem_fun_ptr_helper;
-
-    template <typename RT, class C, typename ArgList>
-    struct mem_fun_ptr_helper<RT, C, ArgList, 1>
-    {
-        typedef RT (C::*type) (typename boost::tuples::element<0,ArgList>::type);
-    };
-
-    template <typename RT, class C, typename ArgList>
-    struct mem_fun_ptr_helper<RT, const C, ArgList, 1>
-    {
-        typedef RT (C::*type) (typename boost::tuples::element<0,ArgList>::type) const;
-    };
-
-    template <typename RT, class C, typename ArgList>
-    struct mem_fun_ptr
-    {
-        typedef typename mem_fun_ptr_helper<RT,C,ArgList>::type type;
-    };
-
    -

    - -

    -Note that if the second template argument is a const C, then we mark -the member function const. The two templates for mem_fun_ptr_helper -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 mem_fun_ptr_helper saves us -from recomputing it in mem_fun_ptr. -

    - - - -

    d) add_reference for tuples

    - -

    -The following classes add references to the elements of a tuple, thus -providing the type equivalent of the return value of the boost::tie -functions. There are probably ways inside boost's tuples library to do -this, but I couldn't locate this. -

    -    template <int N, typename Tuple>
-    struct add_reference_to_Nth
-    {
-        typedef typename boost::tuples::element<N,Tuple>::type ArgType;
-        typedef typename boost::add_reference<ArgType>::type type;
-    };
-
-    template <typename Tuple, int = boost::tuples::length<Tuple>::value>
-    struct tie_args_helper;
-
-    template <typename Tuple>
-    struct tie_args_helper<Tuple,1>
-    {
-        typedef
-        boost::tuple<typename add_reference_to_Nth<0,Tuple>::type>
-        type;
-    };
-
-    template <typename Tuple>
-    struct tie_args
-    {
-        typedef typename tie_args_helper<Tuple>::type type;
-    };
-
    -

    -

    -The tie_args_helper class is repeated for every number of elements we -want to use. -

    - - - -

    6. Open Problems

    - - -

    a) A variable lifetime problem

    -

    -The only unsolved semantic problem I am aware of at present is the -following: if we have a function -

    -    void f(const int &i);
-
    -then this function can be called as -
    -    f(1);
-
     -i.e. the compiler creates a temporary and passes its address to -f(). When invoking f() on a new thread, however, as in -
    -    spawn (f)(1);
-
     -then it is only guaranteed that the call to spawn() does not return -before the new thread is started and has copied the arguments to -f(). However, the argument is only the reference to the temporary, not -its value. f() 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. -

    - - -

    b) Forwarding of operator()

    -

    -Above, we have not defined an overload of spawn for functor-like -objects, even though that would be desirable. One way to do so would be -

    -    template <typename C>
-    mem_fun_encapsulator<void,C,boost::tuple<> >
-    spawn (C &c) {
-      return spawn (c, &C::operator());
-    }
-
    -This only works if operator() satisfies the signature -
    -    struct C {    void operator() ();  };
-
     -

    -

    -We could add another overload if operator() is -const. 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 operator() at the time we declare the return type of -above overload of spawn(). I have not found a way to infer this -information just by using the template parameter C -- it just seems -not possible. What would work if it were supported by compilers is a -kind of typeof-operator: -

    -    template <typename C>
-    typeof(spawn(c,&C::operator()))          // **
-    spawn (C &c) {
-      return spawn (c, &C::operator());
-    }
-
    -

    -

    -When seeing the declaration, the compiler would automatically check -which version of the overloaded spawn() function it would call, and -correspondingly take the return type. gcc does support the typeof -keyword, but even present CVS snapshots generate an internal compiler -error on this construct. -

    - -

    c) Using a memory based scheme rather than condition variables

    -

    -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. -

    - -

    -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 ArgReferences by -ArgList in some places, -the scheme would basically just replace *_encapsulator::operator(), -fire_up, and thread_entry_point: -

    - -
    -      thread<RT>
-      operator() (typename boost::tuples::element<0,ArgList>::type arg1) {
-        return (new mem_fun_wrapper<RT,C,ArgList> (mem_fun_ptr, c,
-                                                   boost::tie(arg1)))->fire_up ();
-      };
-
-      thread<RT> fire_up () {
-        thread_descriptor
-          = DescriptionPointer(new typename detail::thread_description<RT>());
-
-        thread_descriptor->create (entry_point, (void *)this);
-        // no synchronisation here
-        return thread_descriptor;
-      }
-
-      static void * entry_point (void *arg) {
-        wrapper_base<RT> *w       = reinterpret_cast<wrapper_base<RT>*> (arg);
-        fun_wrapper      *wrapper = static_cast<fun_wrapper*> (w);
-        // no copying here; no synchronisation necessary
-        detail::call (wrapper->fun_ptr, wrapper->args,
-                      wrapper->thread_descriptor->ret_val);
-        // delete memory
-        delete wrapper;
-        return 0;
-      }
-
     - -

    -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. -

    - -

    -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. -

    - - -

    7. Alternative Suggestions

    - - -

    -Here are some additional suggestions for discussion: -

    - -

    a) Conversions between return values

    - -

    -If f() is a function returning an integer, then the following is -legal: -

    -    double d = f(arg1, arg2);
-
    -The question, then, would be: do we want to allow conversions between -Thread<double> and Thread<int> objects? -And do we want to allow a -conversion from Thread<T> to Thread<void> -(i.e.: casting away the return value)? -

    - -

    -Since one can still assign the return value of the thread to a double, -

    -    double d = thread.return_value();
-
    -the only real merit in allowing conversions is in putting threads with -different return value types into a ThreadGroup: -
    -    double f1 ();
-    int    f2 ();
-
-    ThreadTroup<double> tg;
-    tg += spawn(f1)();
-    tg += spawn(f2)();    // convert Thread<int> to Thread<double>
-    tg.join_all ();
-
     -

    -

    -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 Thread<T> -> Thread<void> seems -like the only one that is really worth it. -

    - -

    -I have made some initial experiments with implementing general -conversions. The main problem is that we need to allow conversion -chains: -

    -    thread<double> t1 = spawn (f)(arg1, arg2);
-    thread<int>    t2 = t1;
-    thread<double> t3 = t2;
-
    -

    -

    -If f() returns 1.5, then t3.return_value() needs to -return 1.0. I believe that such conversions could be implemented, by adding the -types in the chain into a boost::tuple 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. -

    - - -

    b) Conversions between class types I

    - -

    -When you have a class hierarchy like -

    -    struct B { void f(); };
-    struct D : public B {};
-
    -then calling -
    -    spawn (D(), &B::f);
-
     -fails for gcc (but succeeds with Intel's icc). Presumably, gcc is -right: template arguments must match exactly, and D() is of type -D, while &B::f leads to a class type of -B. 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 -
    -    template <typename RT, typename C, typename Arg1>
-    mem_fun_encapsulator<RT,C,boost::tuple<Arg1> >
-    spawn (C &c, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator<RT, C, boost::tuple<Arg1> > (c,fun_ptr);
-    }
-
     -into -
    -    template <typename RT, typename A, typename C, typename Arg1>
-    mem_fun_encapsulator<RT,C,boost::tuple<Arg1> >
-    spawn (A &a, RT (C::*fun_ptr)(Arg1)) {
-      return mem_fun_encapsulator<RT, C, boost::tuple<Arg1> > (a,fun_ptr);
-    }
-
     -i.e. introduce another class template A for the type of the -object. Since the arguments of the constructor to the -mem_fun_encapsulator object are known, the compiler would perform a -derived-to-base conversion for object a 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).. -

    - - -

    c) Conversions between class types II

    - -

    -When one writes -

    -    spawn (this, &X::f)
-
    -one gets an error that "'this' is not convertible to type X&". One has -to write *this instead. It would be simple to have another set of -overloads of spawn() 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. -

    - - -

    d) Catching exceptions

    - -

    -When a function on a new thread throws an exception, it only -propagates up to one of the two entry_point() 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: -

      -
    • clone an exception without knowing its type; we could then in the - entry_point function catch it and stack it somewhere, just like we - do for the return value
      • -
    • back on the main thread, the Thread::join() function must raise this - stored exception if there was one, again without knowing its type.
      • -
    -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. -

    - - -
    - -
    -Wolfgang Bangerth, 2003 -
    -

     

    - - - - - - -