* is linked from the general documentation page of the library.
*
*
- * @sect3{Restriction on transformations}
+ * <h3>Restriction on transformations</h3>
*
* In some sense, the implementation of this element is not complete,
* but you will rarely notice. Here is the fact: since the element is
* and the curl will be computed correctly as well.
*
*
- * @sect3{Interpolation to finer and coarser meshes}
+ * <h3>Interpolation to finer and coarser meshes</h3>
*
* Each finite element class in deal.II provides matrices that are
* used to interpolate from coarser to finer meshes and the other way
* side), and it also preserves the order of the interpolation.
*
*
- * @sect3{Numbering of the degrees of freedom (DoFs)}
+ * <h3>Numbering of the degrees of freedom (DoFs)</h3>
*
* Nedelec elements have their degrees of freedom on edges, with shape
* functions being vector valued and pointing in tangential
* The constructor of this class takes the degree @p p of this finite
* element.
*
- * @sect3{Implementation}
+ * <h3>Implementation</h3>
*
* The constructor creates a TensorProductPolynomials object
* that includes the tensor product of @p LagrangeEquidistant
* </ul>
* </ul>
*
- * @sect3{Numbering of the degrees of freedom (DoFs)}
+ * <h3>Numbering of the degrees of freedom (DoFs)</h3>
*
* The original ordering of the shape functions represented by the
* TensorProductPolynomials is a tensor product
* the hexes. To be explicit, these numberings are listed in the
* following:
*
- * @sect4{Q1 elements}
+ * <h4>Q1 elements</h4>
* <ul>
* <li> 1D case:
* @verbatim
* The constructor of this class takes the degree @p p of this finite
* element.
*
- * @sect3{Implementation}
+ * <h3>Implementation</h3>
*
* The constructor creates a TensorProductPolynomials object
* that includes the tensor product of @p Hierarchical
* polynomials of degree @p p. This @p TensorProductPolynomials
* object provides all values and derivatives of the shape functions.
*
- * @sect3{Numbering of the degrees of freedom (DoFs)}
+ * <h3>Numbering of the degrees of freedom (DoFs)</h3>
*
* The original ordering of the shape functions represented by the
* TensorProductPolynomials is a tensor product
* the hexes. To be explicit, these numberings are listed in the
* following:
*
- * @sect4{Q1 elements}
+ * <h4>Q1 elements</h4>
* <ul>
* <li> 1D case:
* @verbatim
* <li> Index 7: <tt>[0, 1, 1]</tt>;
* </ul>
* </ul>
- * @sect4{Q2 elements}
+ * <h4>Q2 elements</h4>
* <ul>
* <li> 1D case:
* @verbatim
* <li> Index 26: <tt>[1/2, 1/2, 1/2]</tt>;
* </ul>
* </ul>
- * @sect4{Q3 elements}
+ * <h4>Q3 elements</h4>
* <ul>
* <li> 1D case:
* @verbatim
* Note the reverse ordering of degrees of freedom on the left and
* upper line.
* </ul>
- * @sect4{Q4 elements}
+ * <h4>Q4 elements</h4>
* <ul>
* <li> 1D case:
* @verbatim
* each face.
*
*
- * @sect3{Interpolation to finer and coarser meshes}
+ * <h3>Interpolation to finer and coarser meshes</h3>
*
* Each finite element class in deal.II provides matrices that are
* used to interpolate from coarser to finer meshes and the other way
* side), and it also preserves the order of the interpolation.
*
*
- * @sect3{Numbering of the degrees of freedom (DoFs)}
+ * <h3>Numbering of the degrees of freedom (DoFs)</h3>
*
* Raviart-Thomas elements have their degrees of freedom on edges, with shape
* functions being vector valued and pointing in normal
* using the <tt>|</tt> (bitwise <tt>or</tt>) operator.
*
*
- * @sect2{Description of Flags}
+ * <h3>Description of Flags</h3>
*
* The following flags are declared:
* <ul>
* functions. Each cell is thus shifted in space by values given to
* the mapping through a finite element field.
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
*
* The constructor of this class takes two arguments: a reference to
* the vector that defines the mapping from the reference
* and converting them to deal.II triangulations.
*
*
- * @sect3{Statement of problems}
+ * <h3>Statement of problems</h3>
*
* Triangulations in deal.II have a special structure, in that there
* are not only cells, but also faces, and in 3d also edges, that are
* unfortunately.
*
*
- * @sect3{Examples of problems}
+ * <h3>Examples of problems</h3>
*
* As noted, reordering the vertex lists of cells such that the
* resulting grid is not a trivial problem. In particular, it is often
* entered long ago.
*
*
- * @sect3{Solution}
+ * <h3>Solution</h3>
*
* From the examples above, it is obvious that if we encounter a cell
* that cannot be added to the cells which have already been entered,
* and memory. We will describe these algorithms in the following.
*
*
- * @sect3{The 2d linear complexity algorithm}
+ * <h3>The 2d linear complexity algorithm</h3>
*
* The algorithm uses the fact that opposite faces of a cell need to
* have the same orientation. So you start with one arbitrary line,
* library.
*
*
- * @sect3{For the curious}
+ * <h3>For the curious</h3>
*
* Prior to the implementation of the algorithms developed by Michael Anderson
* and described above, we used a branch-and-cut algorithm initially
* consumpion.
*
*
- * @sect2{Usage}
+ * <h3>Usage</h3>
*
* In practice, use of this class is as follows:
* @verbatim
* vectors computed on the original grid on the reconstructed grid as well.
*
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
* You can use objects of this class almost in the same way as objects of the
* Triangulation class. One of the few differences is that you can only
* construct such an object by giving a coarse grid to the constructor. The
* specialized versions for distinct dimensions.
*
*
- * @sect3{Structure and iterators}
+ * <h3>Structure and iterators</h3>
*
* The actual data structure of a Triangulation object is rather complex
* and quite inconvenient if one attempted to operate on it directly, since
* </ul>
*
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
*
* Usage of a Triangulation is mainly done through the use of iterators.
* An example probably shows best how to use it:
* @endverbatim
*
*
- * @sect3{Creating a triangulation}
+ * <h3>Creating a triangulation</h3>
*
* There are several possibilities to create a triangulation:
* <ul>
*
*
*
- * @sect3{Refinement and coarsening of a triangulation}
+ * <h3>Refinement and coarsening of a triangulation</h3>
*
* Refinement of a triangulation may be done through several ways. The most
* low-level way is directly through iterators: let @p i be an iterator to
* elements. These functions can be found in the GridRefinement class.
*
*
- * @sect3{Smoothing of a triangulation}
+ * <h3>Smoothing of a triangulation</h3>
*
* Some degradation of approximation properties has been observed
* for grids which are too unstructured. Therefore, the
* </ul>
*
*
- * @sect3{Material and boundary information}
+ * <h3>Material and boundary information</h3>
*
* Each line, quad, etc stores one byte of information denoting the
* material of a cell or the part of the boundary, a lower
* the different handling of vertices from lines and quads.
*
*
- * @sect3{History of a triangulation}
+ * <h3>History of a triangulation</h3>
*
* It is possible to reconstruct a grid from its refinement history, which
* can be stored and loaded through the @p save_refine_flags and
* afterwards.
*
*
- * @sect3{User flags and data}
+ * <h3>User flags and data</h3>
*
* A triangulation offers one bit per line, quad, etc for user data.
* This field can be
* unlike the structured objects lines and quads.
*
*
- * @sect3{Boundary approximation}
+ * <h3>Boundary approximation</h3>
*
* You can specify a boundary function for each boundary
* component. If a new vertex is created on a side or face at the
* coarse grid.
*
*
- * @sect3{Technical details}
+ * <h3>Technical details</h3>
*
- * @sect4{Algorithms for mesh regularization and smoothing upon refinement}
+ * <h4>Algorithms for mesh regularization and smoothing upon refinement</h4>
*
* We chose an inductive point of view: since upon creation of the
* triangulation all cells are on the same level, all regularity assumptions
* upon later.
*
*
- * @sect4{Implementation conventions for two spatial dimensions}
+ * <h4>Implementation conventions for two spatial dimensions</h4>
*
* There is a convention about the direction of the bounding lines of quads in
* 2D. The direction of a line is the direction of point 0 towards point 1. We
* variables of the GeometryInfo classes.
*
*
- * @sect4{Coordinate systems}
+ * <h4>Coordinate systems</h4>
*
* When explicit coordinates are required for points in a cell (e.g for
* quadrature formulae or the point of definition of trial functions), we
* coordinates <tt>(1,0)</tt>, vertex 2 at <tt>(1,1)</tt> and vertex 3 at <tt>(0,1)</tt>.
*
*
- * @sect3{Implementation conventions for three spatial dimensions}
+ * <h3>Implementation conventions for three spatial dimensions</h3>
*
* By convention, we will use the following numbering conventions
* for vertices, lines and faces of hexahedra in three space
* member functions and variables of the GeometryInfo classes.
*
*
- * @sect4{Vertices}
+ * <h4>Vertices</h4>
*
* The vertices on the front face are numbered exactly the same way as are
* the vertices on a quadrilateral. The vertices on the back face are numbered
* 0-------1 0-------1
* @endverbatim
*
- * @sect4{Lines}
+ * <h4>Lines</h4>
*
* Here, the same holds as for the vertices: the lines of the front face are
* numbered as for the quadrilateral, for the back face they are just shifted.
* for you, by reorienting cells and edges of an arbitrary list of
* input cells that need not be already sorted.
*
- * @sect4{Faces}
+ * <h4>Faces</h4>
*
* The faces are numbered in the same order as the lines were numbered: front
* face, back face, then the four side faces:
* where you need this information actually, but a few places in the
* library make use of this.
*
- * @sect4{Children}
+ * <h4>Children</h4>
*
* The eight children of a cell are numbered as follows:
* @verbatim
* <tt>GeometryInfo<3>::child_cell_on_face</tt> is best avoided due to
* these problems.
*
- * @sect4{Coordinate systems}
+ * <h4>Coordinate systems</h4>
*
* We define the following coordinate system for the explicit coordinates of
* the vertices of the unit cell:
* </ul>
*
*
- * @sect3{Warning}
+ * <h3>Warning</h3>
*
* It seems impossible to preserve @p constness of a triangulation through
* iterator usage. Thus, if you declare pointers to a @p const triangulation
* lines in 1D-, 2D-, etc dimensions).
*
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
*
* The DoFDimensionInfo classes inherited by the DoFHandler classes
* declare typedefs to iterators using the accessors declared in this class
* as they provide easier typing (much less complicated names!).
*
*
- * @sect3{Notes about the class hierarchy structure}
+ * <h3>Notes about the class hierarchy structure</h3>
*
* Inheritance from <tt>MGDoFObjectAccessor_Inheritance<1,dim>::BaseClass</tt> yields
* inheritance from <tt>DoFCellAccessor<1></tt> if <tt>dim==1</tt> and from
* allocation of a certain amount of memory, but grows as necessary.
*
*
- * @sect3{Rationale}
+ * <h3>Rationale</h3>
*
* When constructing the sparsity pattern of a matrix, you usually
* first have to provide an empty sparsity pattern object with a fixed
* then final set of necessary indices.
*
*
- * @sect3{Interface}
+ * <h3>Interface</h3>
*
* Since this class is intended as an intermediate replacement of the
* SparsityPattern class, it has mostly the same interface, with
* pattern are the same.
*
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
*
* Use this class as follows:
* @verbatim
* hand side, through the apply_constraints() function.
*
*
- * @sect3{Connection to other classes}
+ * <h3>Connection to other classes</h3>
*
* The function @p MatrixTools::apply_boundary_values does exactly
* the same that this class does, except for the fact that that
* one then can work. For these cases, this class is meant.
*
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
*
* Usage is simple: create an object of this type, point it to a
* matrix that shall be used for $A$ above (either through the
* @endverbatim
*
*
- * @sect3{Template arguments}
+ * <h3>Template arguments</h3>
*
* This class takes as template arguments a matrix and a vector
* class. The former must provide @p vmult, @p Tvmult, and
* assignment through <tt>operator=</tt>.
*
*
- * @sect3{Thread-safety}
+ * <h3>Thread-safety</h3>
*
* The functions that operate as a matrix and do not change the
* internal state of this object are synchronised and thus
* description of these flags.
*
*
- * @sect3{Internals}
+ * <h3>Internals</h3>
*
* To avoid a compiler error in Sun's Forte compiler, we derive
* privately from DataOutBase. Since the base class
* of other preconditioners, like BlockSOR or ILU should be handled in
* derived classes by the user.
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
* The simplest use of this class is the following:
* @verbatim
* // generate a @p SolverControl and
* This class defines possible return states of linear solvers and
* provides interfaces to a memory pool and the control object.
*
- * @sect3{Requirements for template classes}
+ * <h3>Requirements for template classes</h3>
*
* Since iterative solvers do not rely on any special structure of
* matrices or the format of storage, but only require that matrices
* which denotes the application of the preconditioner.
*
*
- * @sect3{AdditionalData}
+ * <h3>AdditionalData</h3>
*
* Several solvers need additional data, like the damping parameter @p omega
* of the @p SolverRichardson class or the maximum number of temporary
* temporary vectors. For this class, there is a switch allowing for
* additional output for the computation of eigenvalues of the matrix.
*
- * @sect3{Eigenvalue computation}
+ * <h3>Eigenvalue computation</h3>
*
* See Y. Saad: "Iterative methods for Sparse Linear Systems", section
* 6.7.3 for details.
* the @p solve function of that @p Solver that was specified in the constructor
* of this class.
*
- * @sect3{Usage}
+ * <h3>Usage</h3>
* The simplest use of this class is the following:
* @verbatim
* // generate a @p SolverControl and
* The decomposition is stored as a sparse matrix which is why this
* class is derived from the SparseMatrix. Since it is not a matrix in
* the usual sense, the derivation is <tt>protected</tt> rather than <tt>public</tt>.
-
- * @sect3{Fill-in}
+ *
+ * <h3>Fill-in</h3>
*
* The sparse LU decompositions are frequently used with additional
* fill-in, i.e. the sparsity structure of the decomposition is denser
* copy-constructor of the SparsityPattern class which allows the addition
* of side-diagonals to a given sparsity structure.
*
- * @sect3{Unified use of preconditioners}
+ * <h3>Unified use of preconditioners</h3>
*
* An object of this class can be used in the same form as all
* PreconditionBlock preconditioners:
* Remark: the Vanka method is a non-symmetric preconditioning method.
*
*
- * @sect3{Example of Use}
+ * <h3>Example of Use</h3>
* This little example is taken from a program doing parameter optimization.
* The Lagrange multiplier is the third component of the finite element
* used. The system is solved by the GMRES method.
* @endverbatim
*
*
- * @sect4{Implementor's remark}
+ * <h4>Implementor's remark</h4>
* At present, the local matrices are built up such that the degree of freedom
* associated with the local Lagrange multiplier is the first one. Thus, usually
* the upper left entry in the local matrix is zero. It is not clear to me (W.B.)
* mentioned, this reduces the preconditioning properties.
*
*
- * @sect3{Splitting the matrix into blocks}
+ * <h3>Splitting the matrix into blocks</h3>
*
* Splitting the matrix into blocks is always done in a way such that
* the blocks are not necessarily of equal size, but such that the
* </ul>
*
*
- * @sect3{Typical results}
+ * <h3>Typical results</h3>
*
* As a prototypical test case, we use a nonlinear problem from
* optimization, which leads to a series of saddle point problems,
projects / dealii-svn.git / commitdiff