From: guido Date: Tue, 30 Aug 2005 12:14:56 +0000 (+0000) Subject: doxygen documentation X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c00726393c50c9f51e9d8bd31ebab9028f9c9625;p=dealii-svn.git doxygen documentation git-svn-id: https://svn.dealii.org/trunk@11341 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/deal.II/include/fe/fe_nedelec.h b/deal.II/deal.II/include/fe/fe_nedelec.h index e4f8b12f20..c316a6e8c8 100644 --- a/deal.II/deal.II/include/fe/fe_nedelec.h +++ b/deal.II/deal.II/include/fe/fe_nedelec.h @@ -35,7 +35,7 @@ template class MappingQ; * is linked from the general documentation page of the library. * * - * @sect3{Restriction on transformations} + *

Restriction on transformations

* * In some sense, the implementation of this element is not complete, * but you will rarely notice. Here is the fact: since the element is @@ -83,7 +83,7 @@ template class MappingQ; * and the curl will be computed correctly as well. * * - * @sect3{Interpolation to finer and coarser meshes} + *

Interpolation to finer and coarser meshes

* * Each finite element class in deal.II provides matrices that are * used to interpolate from coarser to finer meshes and the other way @@ -126,7 +126,7 @@ template class MappingQ; * side), and it also preserves the order of the interpolation. * * - * @sect3{Numbering of the degrees of freedom (DoFs)} + *

Numbering of the degrees of freedom (DoFs)

* * Nedelec elements have their degrees of freedom on edges, with shape * functions being vector valued and pointing in tangential diff --git a/deal.II/deal.II/include/fe/fe_q.h b/deal.II/deal.II/include/fe/fe_q.h index 21588ebe37..ec9baa432d 100644 --- a/deal.II/deal.II/include/fe/fe_q.h +++ b/deal.II/deal.II/include/fe/fe_q.h @@ -30,7 +30,7 @@ * The constructor of this class takes the degree @p p of this finite * element. * - * @sect3{Implementation} + *

Implementation

* * The constructor creates a TensorProductPolynomials object * that includes the tensor product of @p LagrangeEquidistant @@ -63,7 +63,7 @@ * * * - * @sect3{Numbering of the degrees of freedom (DoFs)} + *

Numbering of the degrees of freedom (DoFs)

* * The original ordering of the shape functions represented by the * TensorProductPolynomials is a tensor product @@ -73,7 +73,7 @@ * the hexes. To be explicit, these numberings are listed in the * following: * - * @sect4{Q1 elements} + *

Q1 elements

*
    *
  • 1D case: * @verbatim diff --git a/deal.II/deal.II/include/fe/fe_q_hierarchical.h b/deal.II/deal.II/include/fe/fe_q_hierarchical.h index 1c8aa5e768..6e43e9f023 100644 --- a/deal.II/deal.II/include/fe/fe_q_hierarchical.h +++ b/deal.II/deal.II/include/fe/fe_q_hierarchical.h @@ -52,14 +52,14 @@ template class MappingQ; * The constructor of this class takes the degree @p p of this finite * element. * - * @sect3{Implementation} + *

    Implementation

    * * 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)} + *

    Numbering of the degrees of freedom (DoFs)

    * * The original ordering of the shape functions represented by the * TensorProductPolynomials is a tensor product @@ -69,7 +69,7 @@ template class MappingQ; * the hexes. To be explicit, these numberings are listed in the * following: * - * @sect4{Q1 elements} + *

    Q1 elements

    *
      *
    • 1D case: * @verbatim @@ -111,7 +111,7 @@ template class MappingQ; *
    • Index 7: [0, 1, 1]; *
    *
- * @sect4{Q2 elements} + *

Q2 elements

*
    *
  • 1D case: * @verbatim @@ -185,7 +185,7 @@ template class MappingQ; *
  • Index 26: [1/2, 1/2, 1/2]; *
* - * @sect4{Q3 elements} + *

Q3 elements

*
    *
  • 1D case: * @verbatim @@ -205,7 +205,7 @@ template class MappingQ; * Note the reverse ordering of degrees of freedom on the left and * upper line. *
- * @sect4{Q4 elements} + *

Q4 elements

*
    *
  • 1D case: * @verbatim diff --git a/deal.II/deal.II/include/fe/fe_raviart_thomas.h b/deal.II/deal.II/include/fe/fe_raviart_thomas.h index 2f7f3f07a0..f8f3905150 100644 --- a/deal.II/deal.II/include/fe/fe_raviart_thomas.h +++ b/deal.II/deal.II/include/fe/fe_raviart_thomas.h @@ -41,7 +41,7 @@ template class MappingQ; * each face. * * - * @sect3{Interpolation to finer and coarser meshes} + *

    Interpolation to finer and coarser meshes

    * * Each finite element class in deal.II provides matrices that are * used to interpolate from coarser to finer meshes and the other way @@ -84,7 +84,7 @@ template class MappingQ; * side), and it also preserves the order of the interpolation. * * - * @sect3{Numbering of the degrees of freedom (DoFs)} + *

    Numbering of the degrees of freedom (DoFs)

    * * Raviart-Thomas elements have their degrees of freedom on edges, with shape * functions being vector valued and pointing in normal diff --git a/deal.II/deal.II/include/fe/fe_update_flags.h b/deal.II/deal.II/include/fe/fe_update_flags.h index 43931c6c91..8426632196 100644 --- a/deal.II/deal.II/include/fe/fe_update_flags.h +++ b/deal.II/deal.II/include/fe/fe_update_flags.h @@ -32,7 +32,7 @@ * using the | (bitwise or) operator. * * - * @sect2{Description of Flags} + *

    Description of Flags

    * * The following flags are declared: *
      diff --git a/deal.II/deal.II/include/fe/mapping_q1_eulerian.h b/deal.II/deal.II/include/fe/mapping_q1_eulerian.h index 4e5b949d2b..6851cb9015 100644 --- a/deal.II/deal.II/include/fe/mapping_q1_eulerian.h +++ b/deal.II/deal.II/include/fe/mapping_q1_eulerian.h @@ -26,7 +26,7 @@ * functions. Each cell is thus shifted in space by values given to * the mapping through a finite element field. * - * @sect3{Usage} + *

      Usage

      * * The constructor of this class takes two arguments: a reference to * the vector that defines the mapping from the reference diff --git a/deal.II/deal.II/include/grid/grid_reordering.h b/deal.II/deal.II/include/grid/grid_reordering.h index 01c0ebc809..a82e5f1ce5 100644 --- a/deal.II/deal.II/include/grid/grid_reordering.h +++ b/deal.II/deal.II/include/grid/grid_reordering.h @@ -29,7 +29,7 @@ * and converting them to deal.II triangulations. * * - * @sect3{Statement of problems} + *

      Statement of problems

      * * 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 @@ -124,7 +124,7 @@ * unfortunately. * * - * @sect3{Examples of problems} + *

      Examples of problems

      * * As noted, reordering the vertex lists of cells such that the * resulting grid is not a trivial problem. In particular, it is often @@ -238,7 +238,7 @@ * entered long ago. * * - * @sect3{Solution} + *

      Solution

      * * 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, @@ -304,7 +304,7 @@ * and memory. We will describe these algorithms in the following. * * - * @sect3{The 2d linear complexity algorithm} + *

      The 2d linear complexity algorithm

      * * The algorithm uses the fact that opposite faces of a cell need to * have the same orientation. So you start with one arbitrary line, @@ -432,7 +432,7 @@ * library. * * - * @sect3{For the curious} + *

      For the curious

      * * Prior to the implementation of the algorithms developed by Michael Anderson * and described above, we used a branch-and-cut algorithm initially diff --git a/deal.II/deal.II/include/grid/intergrid_map.h b/deal.II/deal.II/include/grid/intergrid_map.h index ee74a2bd03..3463b1d2ef 100644 --- a/deal.II/deal.II/include/grid/intergrid_map.h +++ b/deal.II/deal.II/include/grid/intergrid_map.h @@ -75,7 +75,7 @@ * consumpion. * * - * @sect2{Usage} + *

      Usage

      * * In practice, use of this class is as follows: * @verbatim diff --git a/deal.II/deal.II/include/grid/persistent_tria.h b/deal.II/deal.II/include/grid/persistent_tria.h index eec385505c..7f07f46ca3 100644 --- a/deal.II/deal.II/include/grid/persistent_tria.h +++ b/deal.II/deal.II/include/grid/persistent_tria.h @@ -47,7 +47,7 @@ * vectors computed on the original grid on the reconstructed grid as well. * * - * @sect3{Usage} + *

      Usage

      * 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 diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h index cec405425d..6faee8b0fb 100644 --- a/deal.II/deal.II/include/grid/tria.h +++ b/deal.II/deal.II/include/grid/tria.h @@ -343,7 +343,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * specialized versions for distinct dimensions. * * - * @sect3{Structure and iterators} + *

      Structure and iterators

      * * The actual data structure of a Triangulation object is rather complex * and quite inconvenient if one attempted to operate on it directly, since @@ -453,7 +453,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> *
    * * - * @sect3{Usage} + *

    Usage

    * * Usage of a Triangulation is mainly done through the use of iterators. * An example probably shows best how to use it: @@ -497,7 +497,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * @endverbatim * * - * @sect3{Creating a triangulation} + *

    Creating a triangulation

    * * There are several possibilities to create a triangulation: *
      @@ -629,7 +629,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * * - * @sect3{Refinement and coarsening of a triangulation} + *

      Refinement and coarsening of a triangulation

      * * 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 @@ -673,7 +673,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * elements. These functions can be found in the GridRefinement class. * * - * @sect3{Smoothing of a triangulation} + *

      Smoothing of a triangulation

      * * Some degradation of approximation properties has been observed * for grids which are too unstructured. Therefore, the @@ -830,7 +830,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> *
    * * - * @sect3{Material and boundary information} + *

    Material and boundary information

    * * Each line, quad, etc stores one byte of information denoting the * material of a cell or the part of the boundary, a lower @@ -869,7 +869,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * the different handling of vertices from lines and quads. * * - * @sect3{History of a triangulation} + *

    History of a triangulation

    * * It is possible to reconstruct a grid from its refinement history, which * can be stored and loaded through the @p save_refine_flags and @@ -917,7 +917,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * afterwards. * * - * @sect3{User flags and data} + *

    User flags and data

    * * A triangulation offers one bit per line, quad, etc for user data. * This field can be @@ -976,7 +976,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * unlike the structured objects lines and quads. * * - * @sect3{Boundary approximation} + *

    Boundary approximation

    * * You can specify a boundary function for each boundary * component. If a new vertex is created on a side or face at the @@ -1027,9 +1027,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * coarse grid. * * - * @sect3{Technical details} + *

    Technical details

    * - * @sect4{Algorithms for mesh regularization and smoothing upon refinement} + *

    Algorithms for mesh regularization and smoothing upon refinement

    * * We chose an inductive point of view: since upon creation of the * triangulation all cells are on the same level, all regularity assumptions @@ -1112,7 +1112,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * upon later. * * - * @sect4{Implementation conventions for two spatial dimensions} + *

    Implementation conventions for two spatial dimensions

    * * 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 @@ -1144,7 +1144,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * variables of the GeometryInfo classes. * * - * @sect4{Coordinate systems} + *

    Coordinate systems

    * * When explicit coordinates are required for points in a cell (e.g for * quadrature formulae or the point of definition of trial functions), we @@ -1161,7 +1161,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * coordinates (1,0), vertex 2 at (1,1) and vertex 3 at (0,1). * * - * @sect3{Implementation conventions for three spatial dimensions} + *

    Implementation conventions for three spatial dimensions

    * * By convention, we will use the following numbering conventions * for vertices, lines and faces of hexahedra in three space @@ -1189,7 +1189,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * member functions and variables of the GeometryInfo classes. * * - * @sect4{Vertices} + *

    Vertices

    * * 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 @@ -1208,7 +1208,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * 0-------1 0-------1 * @endverbatim * - * @sect4{Lines} + *

    Lines

    * * 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. @@ -1254,7 +1254,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * for you, by reorienting cells and edges of an arbitrary list of * input cells that need not be already sorted. * - * @sect4{Faces} + *

    Faces

    * * The faces are numbered in the same order as the lines were numbered: front * face, back face, then the four side faces: @@ -1366,7 +1366,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * where you need this information actually, but a few places in the * library make use of this. * - * @sect4{Children} + *

    Children

    * * The eight children of a cell are numbered as follows: * @verbatim @@ -1417,7 +1417,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * GeometryInfo<3>::child_cell_on_face is best avoided due to * these problems. * - * @sect4{Coordinate systems} + *

    Coordinate systems

    * * We define the following coordinate system for the explicit coordinates of * the vertices of the unit cell: @@ -1453,7 +1453,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> *
* * - * @sect3{Warning} + *

Warning

* * It seems impossible to preserve @p constness of a triangulation through * iterator usage. Thus, if you declare pointers to a @p const triangulation diff --git a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h index 16e360eee2..e81dfda211 100644 --- a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h +++ b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h @@ -210,7 +210,7 @@ class MGDoFObjectAccessor<0, dim> * lines in 1D-, 2D-, etc dimensions). * * - * @sect3{Usage} + *

Usage

* * The DoFDimensionInfo classes inherited by the DoFHandler classes * declare typedefs to iterators using the accessors declared in this class @@ -219,7 +219,7 @@ class MGDoFObjectAccessor<0, dim> * as they provide easier typing (much less complicated names!). * * - * @sect3{Notes about the class hierarchy structure} + *

Notes about the class hierarchy structure

* * Inheritance from MGDoFObjectAccessor_Inheritance<1,dim>::BaseClass yields * inheritance from DoFCellAccessor<1> if dim==1 and from diff --git a/deal.II/lac/include/lac/compressed_sparsity_pattern.h b/deal.II/lac/include/lac/compressed_sparsity_pattern.h index 307dd7f5ec..26acdcd5a0 100644 --- a/deal.II/lac/include/lac/compressed_sparsity_pattern.h +++ b/deal.II/lac/include/lac/compressed_sparsity_pattern.h @@ -46,7 +46,7 @@ template class SparseMatrix; * allocation of a certain amount of memory, but grows as necessary. * * - * @sect3{Rationale} + *

Rationale

* * When constructing the sparsity pattern of a matrix, you usually * first have to provide an empty sparsity pattern object with a fixed @@ -80,7 +80,7 @@ template class SparseMatrix; * then final set of necessary indices. * * - * @sect3{Interface} + *

Interface

* * Since this class is intended as an intermediate replacement of the * SparsityPattern class, it has mostly the same interface, with @@ -89,7 +89,7 @@ template class SparseMatrix; * pattern are the same. * * - * @sect3{Usage} + *

Usage

* * Use this class as follows: * @verbatim diff --git a/deal.II/lac/include/lac/filtered_matrix.h b/deal.II/lac/include/lac/filtered_matrix.h index b43b9ad0c9..b3bb4f7450 100644 --- a/deal.II/lac/include/lac/filtered_matrix.h +++ b/deal.II/lac/include/lac/filtered_matrix.h @@ -99,7 +99,7 @@ template class Vector; * hand side, through the apply_constraints() function. * * - * @sect3{Connection to other classes} + *

Connection to other classes

* * The function @p MatrixTools::apply_boundary_values does exactly * the same that this class does, except for the fact that that @@ -120,7 +120,7 @@ template class Vector; * one then can work. For these cases, this class is meant. * * - * @sect3{Usage} + *

Usage

* * Usage is simple: create an object of this type, point it to a * matrix that shall be used for $A$ above (either through the @@ -166,7 +166,7 @@ template class Vector; * @endverbatim * * - * @sect3{Template arguments} + *

Template arguments

* * This class takes as template arguments a matrix and a vector * class. The former must provide @p vmult, @p Tvmult, and @@ -176,7 +176,7 @@ template class Vector; * assignment through operator=. * * - * @sect3{Thread-safety} + *

Thread-safety

* * The functions that operate as a matrix and do not change the * internal state of this object are synchronised and thus diff --git a/deal.II/lac/include/lac/matrix_out.h b/deal.II/lac/include/lac/matrix_out.h index dde6631fe5..f3f165f415 100644 --- a/deal.II/lac/include/lac/matrix_out.h +++ b/deal.II/lac/include/lac/matrix_out.h @@ -54,7 +54,7 @@ * description of these flags. * * - * @sect3{Internals} + *

Internals

* * To avoid a compiler error in Sun's Forte compiler, we derive * privately from DataOutBase. Since the base class diff --git a/deal.II/lac/include/lac/precondition_selector.h b/deal.II/lac/include/lac/precondition_selector.h index d17547cc6a..917868f719 100644 --- a/deal.II/lac/include/lac/precondition_selector.h +++ b/deal.II/lac/include/lac/precondition_selector.h @@ -40,7 +40,7 @@ template class SparseMatrix; * of other preconditioners, like BlockSOR or ILU should be handled in * derived classes by the user. * - * @sect3{Usage} + *

Usage

* The simplest use of this class is the following: * @verbatim * // generate a @p SolverControl and diff --git a/deal.II/lac/include/lac/solver.h b/deal.II/lac/include/lac/solver.h index 38b4436049..247638de74 100644 --- a/deal.II/lac/include/lac/solver.h +++ b/deal.II/lac/include/lac/solver.h @@ -28,7 +28,7 @@ class SolverControl; * 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} + *

Requirements for template classes

* * Since iterative solvers do not rely on any special structure of * matrices or the format of storage, but only require that matrices @@ -106,7 +106,7 @@ class SolverControl; * which denotes the application of the preconditioner. * * - * @sect3{AdditionalData} + *

AdditionalData

* * Several solvers need additional data, like the damping parameter @p omega * of the @p SolverRichardson class or the maximum number of temporary diff --git a/deal.II/lac/include/lac/solver_cg.h b/deal.II/lac/include/lac/solver_cg.h index bea064239e..104464d53a 100644 --- a/deal.II/lac/include/lac/solver_cg.h +++ b/deal.II/lac/include/lac/solver_cg.h @@ -38,7 +38,7 @@ * temporary vectors. For this class, there is a switch allowing for * additional output for the computation of eigenvalues of the matrix. * - * @sect3{Eigenvalue computation} + *

Eigenvalue computation

* * See Y. Saad: "Iterative methods for Sparse Linear Systems", section * 6.7.3 for details. diff --git a/deal.II/lac/include/lac/solver_selector.h b/deal.II/lac/include/lac/solver_selector.h index 095ba76d59..a24f7e4b6e 100644 --- a/deal.II/lac/include/lac/solver_selector.h +++ b/deal.II/lac/include/lac/solver_selector.h @@ -37,7 +37,7 @@ * the @p solve function of that @p Solver that was specified in the constructor * of this class. * - * @sect3{Usage} + *

Usage

* The simplest use of this class is the following: * @verbatim * // generate a @p SolverControl and diff --git a/deal.II/lac/include/lac/sparse_decomposition.h b/deal.II/lac/include/lac/sparse_decomposition.h index 3e7e3d81c6..7a053ce765 100644 --- a/deal.II/lac/include/lac/sparse_decomposition.h +++ b/deal.II/lac/include/lac/sparse_decomposition.h @@ -30,8 +30,8 @@ * 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 protected rather than public. - - * @sect3{Fill-in} + * + *

Fill-in

* * The sparse LU decompositions are frequently used with additional * fill-in, i.e. the sparsity structure of the decomposition is denser @@ -45,7 +45,7 @@ * copy-constructor of the SparsityPattern class which allows the addition * of side-diagonals to a given sparsity structure. * - * @sect3{Unified use of preconditioners} + *

Unified use of preconditioners

* * An object of this class can be used in the same form as all * PreconditionBlock preconditioners: diff --git a/deal.II/lac/include/lac/sparse_vanka.h b/deal.II/lac/include/lac/sparse_vanka.h index ca0cd10aa9..881948eb11 100644 --- a/deal.II/lac/include/lac/sparse_vanka.h +++ b/deal.II/lac/include/lac/sparse_vanka.h @@ -84,7 +84,7 @@ template class SparseBlockVanka; * Remark: the Vanka method is a non-symmetric preconditioning method. * * - * @sect3{Example of Use} + *

Example of Use

* 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. @@ -111,7 +111,7 @@ template class SparseBlockVanka; * @endverbatim * * - * @sect4{Implementor's remark} + *

Implementor's remark

* 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.) @@ -390,7 +390,7 @@ class SparseVanka * mentioned, this reduces the preconditioning properties. * * - * @sect3{Splitting the matrix into blocks} + *

Splitting the matrix into blocks

* * 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 @@ -465,7 +465,7 @@ class SparseVanka * * * - * @sect3{Typical results} + *

Typical results

* * As a prototypical test case, we use a nonlinear problem from * optimization, which leads to a series of saddle point problems,