]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
doxygen documentation
authorguido <guido@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 30 Aug 2005 12:14:56 +0000 (12:14 +0000)
committerguido <guido@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 30 Aug 2005 12:14:56 +0000 (12:14 +0000)
git-svn-id: https://svn.dealii.org/trunk@11341 0785d39b-7218-0410-832d-ea1e28bc413d

20 files changed:
deal.II/deal.II/include/fe/fe_nedelec.h
deal.II/deal.II/include/fe/fe_q.h
deal.II/deal.II/include/fe/fe_q_hierarchical.h
deal.II/deal.II/include/fe/fe_raviart_thomas.h
deal.II/deal.II/include/fe/fe_update_flags.h
deal.II/deal.II/include/fe/mapping_q1_eulerian.h
deal.II/deal.II/include/grid/grid_reordering.h
deal.II/deal.II/include/grid/intergrid_map.h
deal.II/deal.II/include/grid/persistent_tria.h
deal.II/deal.II/include/grid/tria.h
deal.II/deal.II/include/multigrid/mg_dof_accessor.h
deal.II/lac/include/lac/compressed_sparsity_pattern.h
deal.II/lac/include/lac/filtered_matrix.h
deal.II/lac/include/lac/matrix_out.h
deal.II/lac/include/lac/precondition_selector.h
deal.II/lac/include/lac/solver.h
deal.II/lac/include/lac/solver_cg.h
deal.II/lac/include/lac/solver_selector.h
deal.II/lac/include/lac/sparse_decomposition.h
deal.II/lac/include/lac/sparse_vanka.h

index e4f8b12f20eb44bd011c361a5b3cd8d924106760..c316a6e8c880d82714826c2291dd517d709ab7ef 100644 (file)
@@ -35,7 +35,7 @@ template <int dim> class MappingQ;
  * 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
@@ -83,7 +83,7 @@ template <int dim> class MappingQ;
  * 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
@@ -126,7 +126,7 @@ template <int dim> class MappingQ;
  * 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
index 21588ebe374f3fbf4c1c04a240380eeeec5baf88..ec9baa432d30d6c9daa46c556258f8a23a4280c2 100644 (file)
@@ -30,7 +30,7 @@
  * 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
@@ -63,7 +63,7 @@
  *   </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
@@ -73,7 +73,7 @@
  * the hexes. To be explicit, these numberings are listed in the
  * following:
  *
- * @sect4{Q1 elements}
+ * <h4>Q1 elements</h4>
  * <ul>
  * <li> 1D case:
  *   @verbatim
index 1c8aa5e7689821e302380b7ed1980233bd7f2678..6e43e9f0238aaec758e4f8f22a55ba86a9d1a841 100644 (file)
@@ -52,14 +52,14 @@ template <int dim> class MappingQ;
  * 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
@@ -69,7 +69,7 @@ template <int dim> class MappingQ;
  * the hexes. To be explicit, these numberings are listed in the
  * following:
  *
- * @sect4{Q1 elements}
+ * <h4>Q1 elements</h4>
  * <ul>
  * <li> 1D case:
  *   @verbatim
@@ -111,7 +111,7 @@ template <int dim> class MappingQ;
  *   <li> Index 7: <tt>[0, 1, 1]</tt>;
  *   </ul>
  * </ul>
- * @sect4{Q2 elements}
+ * <h4>Q2 elements</h4>
  * <ul>
  * <li> 1D case:
  *   @verbatim
@@ -185,7 +185,7 @@ template <int dim> class MappingQ;
  *   <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
@@ -205,7 +205,7 @@ template <int dim> class MappingQ;
  *   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
index 2f7f3f07a01a131aa767537dcbafdef3aaf03c62..f8f3905150d2c30122df921a7f26c0259f854384 100644 (file)
@@ -41,7 +41,7 @@ template <int dim> class MappingQ;
  * 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
@@ -84,7 +84,7 @@ template <int dim> class MappingQ;
  * 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
index 43931c6c91eb1b7ae0084020f285a5f50e8a41fc..8426632196beead973c55ffefa4447fc29396072 100644 (file)
@@ -32,7 +32,7 @@
  * using the <tt>|</tt> (bitwise <tt>or</tt>) operator.
  *
  *
- * @sect2{Description of Flags}
+ * <h3>Description of Flags</h3>
  *
  * The following flags are declared:
  * <ul>
index 4e5b949d2b9f6ed11e0833cd529b0c79d1acd84f..6851cb9015625472e2317eeb8ccf8908311fdf8b 100644 (file)
@@ -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} 
+ * <h3>Usage</h3> 
  *
  * The constructor of this class takes two arguments: a reference to
  * the vector that defines the mapping from the reference
index 01c0ebc809465f0314dba7b47ea7b823fb20d3eb..a82e5f1ce52c6232484cfb97c04b27083983cf55 100644 (file)
@@ -29,7 +29,7 @@
  * 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
index ee74a2bd035ca82edf2621971526f97aa1c90fd4..3463b1d2ef614451176b34290b5543e946f2ee84 100644 (file)
@@ -75,7 +75,7 @@
  * consumpion.
  *
  *
- * @sect2{Usage}
+ * <h3>Usage</h3>
  *
  * In practice, use of this class is as follows:
  * @verbatim
index eec385505cd4f6244dd3ee66e4762865b6ff7fdd..7f07f46ca39bdbfc98e3b1d17e8e1e45c3df03ca 100644 (file)
@@ -47,7 +47,7 @@
  * 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
index cec405425d2ce0db3da45f2c8377b75b8d8a1925..6faee8b0fb6c5f37dc14ae6abaefe413e8023d4b 100644 (file)
@@ -343,7 +343,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  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
@@ -453,7 +453,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  </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:
@@ -497,7 +497,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  @endverbatim
  *
  *  
- *  @sect3{Creating a triangulation}
+ *  <h3>Creating a triangulation</h3>
  *
  *  There are several possibilities to create a triangulation:
  *  <ul>
@@ -629,7 +629,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *
  *
- *   @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
@@ -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}
+ *   <h3>Smoothing of a triangulation</h3>
  *
  *   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>
  *   </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
@@ -869,7 +869,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -917,7 +917,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -976,7 +976,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1027,9 +1027,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1112,7 +1112,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1144,7 +1144,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1161,7 +1161,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1189,7 +1189,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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
@@ -1208,7 +1208,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     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.
@@ -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}
+ *   <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:
@@ -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}
+ *   <h4>Children</h4>
  *
  *   The eight children of a cell are numbered as follows:
  *   @verbatim
@@ -1417,7 +1417,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   <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:
@@ -1453,7 +1453,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   </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
index 16e360eee234ee7af1f8f0d59e5b7728dc315517..e81dfda211820274c58dfe0e0e6a15cc4290a433 100644 (file)
@@ -210,7 +210,7 @@ class MGDoFObjectAccessor<0, dim>
  * 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
@@ -219,7 +219,7 @@ class MGDoFObjectAccessor<0, dim>
  * 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
index 307dd7f5ec0dd8a6b86b35b1570350790016c58c..26acdcd5a01fbc16480fe8f7e7fc22fab01bd294 100644 (file)
@@ -46,7 +46,7 @@ template <typename number> class SparseMatrix;
  * 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
@@ -80,7 +80,7 @@ template <typename number> class SparseMatrix;
  * 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
@@ -89,7 +89,7 @@ template <typename number> class SparseMatrix;
  * pattern are the same.
  *
  *
- * @sect3{Usage}
+ * <h3>Usage</h3>
  *
  * Use this class as follows:
  * @verbatim
index b43b9ad0c9f60ca55873b71c8ae5be942e78937c..b3bb4f7450c42520e2c354762c48d87d537636c3 100644 (file)
@@ -99,7 +99,7 @@ template <typename number> class Vector;
  * 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
@@ -120,7 +120,7 @@ template <typename number> class Vector;
  * 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
@@ -166,7 +166,7 @@ template <typename number> class Vector;
  * @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
@@ -176,7 +176,7 @@ template <typename number> class Vector;
  * 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
index dde6631fe59fd924aa1d377597419f7a3de65416..f3f165f4157af88432e527d6efa449a46fdcc12a 100644 (file)
@@ -54,7 +54,7 @@
  * 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
index d17547cc6af9dc8fb925ba24cbd463bdb9806f54..917868f71919c3abaa08645f80bc4340667feff8 100644 (file)
@@ -40,7 +40,7 @@ template <class number> class SparseMatrix;
  * 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
index 38b4436049e86e833f5797ab72e635d6e0c2b97f..247638de74d814aa0d96ea056cb87d12edea7721 100644 (file)
@@ -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}
+ * <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
@@ -106,7 +106,7 @@ class SolverControl;
  * 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
index bea064239e0cce1c12a67fc16f7801c99551f357..104464d53a7718fcd1eef9191755ba57a808db48 100644 (file)
@@ -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}
+ * <h3>Eigenvalue computation</h3>
  *
  * See Y. Saad: "Iterative methods for Sparse Linear Systems", section
  * 6.7.3 for details.
index 095ba76d59c4bdc97a6843ca4b72bfbc8e7b42d5..a24f7e4b6e97e58c4be8b876eeaf452207d75606 100644 (file)
@@ -37,7 +37,7 @@
  * 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
index 3e7e3d81c6fe5b1633361696546fa4b5c0db8c9d..7a053ce765652495920842a47ec982f8471a32f3 100644 (file)
@@ -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 <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
@@ -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}
+ * <h3>Unified use of preconditioners</h3>
  *
  * An object of this class can be used in the same form as all
  * PreconditionBlock preconditioners:
index ca0cd10aa9c3a791bd58578b844648c3344f8b95..881948eb11fc1a361c2c0379569cecab3aa3bde2 100644 (file)
@@ -84,7 +84,7 @@ template <typename number> class SparseBlockVanka;
  * 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.
@@ -111,7 +111,7 @@ template <typename number> class SparseBlockVanka;
  * @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.)
@@ -390,7 +390,7 @@ class SparseVanka
  * 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
@@ -465,7 +465,7 @@ class SparseVanka
  * </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,

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

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.