* result in a strange kind of behaviour, though every reasonable
* operating system should disallow access through that pointer.
* The reason we do not check for the null pointer in the
- * constructor which gets passed the @p{DoFHandler} pointer is that
+ * constructor which gets passed the @ref{DoFHandler} pointer is that
* if we did we could not make dof iterators member of other classes
- * (like in the @p{FEValues} class) if we did not know about the
- * @p{DoFHandler} object to be used upon construction of that object.
+ * (like in the @ref{FEValues} class) if we did not know about the
+ * @ref{DoFHandler} object to be used upon construction of that object.
* Through the way this class is implemented here, we allow the
* creation of a kind of virgin object which only gets useful if
* assigned to from another object before first usage.
/**
* Return a handle on the
- * @p{DoFHandler} object which we
+ * @ref{DoFHandler} object which we
* are using.
*/
const DoFHandler<dim> &
protected:
/**
- * Store the address of the @p{DoFHandler} object
+ * Store the address of the @ref{DoFHandler} object
* to be accessed.
*/
DoFHandler<dim> *dof_handler;
/**
* This is a switch class which only declares a @p{typedef}. It is meant to
- * determine which class a @p{DoFObjectAccessor} class is to be derived
+ * determine which class a @ref{DoFObjectAccessor} class is to be derived
* from. By default, @p{DoFObjectAccessor<celldim,dim>} derives from
* the @p{typedef} in the general @p{DoFObjectAccessor_Inheritance<celldim,dim>}
* class, which is @p{TriaObjectAccessor<celldim,dim>},
* but if @p{celldim==dim}, then the specialization @p{DoFObjectAccessor_Inheritance<dim,dim>}
* is used which declares its local type to be @p{CellAccessor<dim>}. Therefore,
- * the inheritance is automatically chosen to be from @p{CellAccessor} if the
+ * the inheritance is automatically chosen to be from @ref{CellAccessor} if the
* object under consideration has full dimension, i.e. constitutes a cell.
*
* @author Wolfgang Bangerth, 1999
/**
* This is a switch class which only declares a @p{typedef}. It is meant to
- * determine which class a @p{DoFObjectAccessor} class is to be derived
+ * determine which class a @ref{DoFObjectAccessor} class is to be derived
* from. By default, @p{DoFObjectAccessor<celldim,dim>} derives from
* the @p{typedef} in the general @p{DoFObjectAccessor_Inheritance<celldim,dim>}
* class, which is @p{TriaObjectAccessor<celldim,dim>},
* but if @p{celldim==dim}, then the specialization @p{DoFObjectAccessor_Inheritance<dim,dim>}
* is used which declares its local type to be @p{CellAccessor<dim>}. Therefore,
- * the inheritance is automatically chosen to be from @p{CellAccessor} if the
+ * the inheritance is automatically chosen to be from @ref{CellAccessor} if the
* object under consideration has full dimension, i.e. constitutes a cell.
*
* @author Wolfgang Bangerth, 1999
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
DoFObjectAccessor (Triangulation<dim> *tria,
const int level,
*
* The input vector may be either
* a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
* to this function.
*
* The output vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
quad (const unsigned int i) const;
/**
- * @p{i}th child as a @p{DoFObjectAccessor}
+ * @p{i}th child as a @ref{DoFObjectAccessor}
* iterator. This function is needed since
* the child function of the base
* class returns a hex accessor without
/**
* This function does much the same as the
- * @p{distribute_local_to_global(dVector,dVector)}
+ * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
* function, but operates on matrices
* instead of vectors. The sparse matrix
* is supposed to have non-zero entry
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
DoFObjectAccessor (Triangulation<dim> *tria,
const int level,
* cells.
*
* The input vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
* have the right size beforehand.
*
* The output vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
/**
* This function does much the same as the
- * @p{distribute_local_to_global(dVector,dVector)}
+ * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
* function, but operates on matrices
* instead of vectors. The sparse matrix
* is supposed to have non-zero entry
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
DoFObjectAccessor (Triangulation<dim> *tria,
const int level,
* cells.
*
* The input vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
* have the right size beforehand.
*
* The output vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
/**
* This function does much the same as the
- * @p{distribute_local_to_global(dVector,dVector)}
+ * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
* function, but operates on matrices
* instead of vectors. The sparse matrix
* is supposed to have non-zero entry
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
DoFObjectAccessor (Triangulation<dim> *tria,
const int level,
* cells.
*
* The input vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
* have the right size beforehand.
*
* The output vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
/**
* This function does much the same as the
- * @p{distribute_local_to_global(dVector,dVector)}
+ * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
* function, but operates on matrices
* instead of vectors. The sparse matrix
* is supposed to have non-zero entry
};
+
/**
* Grant access to the degrees of freedom on a cell. In fact, since all
* access to the degrees of freedom has been enabled by the classes
* one and two, respectively, this class only collects the pieces
* together by deriving from the appropriate @p{DoF*Accessor} and the
* right @p{CellAccessor<dim>} and finally adding two functions which give
- * access to the neighbors and children as @p{DoFCellAccessor} objects
- * rather than @p{CellAccessor} objects (the latter function was inherited
+ * access to the neighbors and children as @ref{DoFCellAccessor} objects
+ * rather than @ref{CellAccessor} objects (the latter function was inherited
* from the @p{CellAccessor<dim>} class).
*
* Note that since for the class we derive from, i.e. @p{DoFObjectAccessor<dim,dim>},
* the two template parameters are equal, the base class is actually derived from
- * @p{CellAccessor}, which makes the functions of this class available to the
- * @p{DoFCellAccessor} class as well.
+ * @ref{CellAccessor}, which makes the functions of this class available to the
+ * @ref{DoFCellAccessor} class as well.
*
* @author Wolfgang Bangerth, 1998
*/
* objects.
*
* The output vector may be either
- * a @p{Vector<float>},
- * @p{Vector<double>}, or a
- * @p{BlockVector<...,double>}. It
+ * a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>}, or a
+ * @ref{BlockVector}@p{<...,double>}. It
* is in the responsibility of
* the caller to assure that the
* types of the numbers stored in
* operation.
*
* Condensation is done in four steps: first the large matrix sparsity pattern
- * is created (e.g. using @p{DoFHandler::create_sparsity_pattern}), then the
+ * is created (e.g. using @ref{DoFHandler}@p{::create_sparsity_pattern}), then the
* sparsity pattern of the condensed matrix is made out of the large sparsity
* pattern and the constraints. After that the global matrix is assembled and
* finally condensed. To do these steps, you have (at least) two possibilities:
* entries of @p{condensed} be zero!
*
* The @p{VectorType} may be a
- * @p{Vector<float>},
- * @p{Vector<double>},
- * @p{BlockVector<...>}, or any
+ * @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>},
+ * @ref{BlockVector}@p{<...>}, or any
* other type having the same
* interface.
*/
/**
* Condense the given vector
* in-place. The @p{VectorType} may
- * be a @p{Vector<float>},
- * @p{Vector<double>},
- * @p{BlockVector<...>}, or any
+ * be a @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>},
+ * @ref{BlockVector}@p{<...>}, or any
* other type having the same
* interface.
*/
* @p{condense}.
*
* The @p{VectorType} may be a
- * @p{Vector<float>},
- * @p{Vector<double>},
- * @p{BlockVector<...>}, or any
+ * @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>},
+ * @ref{BlockVector}@p{<...>}, or any
* other type having the same
* interface.
*/
* Re-distribute the elements of
* the vector in-place. The
* @p{VectorType} may be a
- * @p{Vector<float>},
- * @p{Vector<double>},
- * @p{BlockVector<...>}, or any
+ * @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>},
+ * @ref{BlockVector}@p{<...>}, or any
* other type having the same
* interface.
*/
* vector. Sets all hanging node
* values to zero. The
* @p{VectorType} may be a
- * @p{Vector<float>},
- * @p{Vector<double>},
- * @p{BlockVector<...>}, or any
+ * @ref{Vector}@p{<float>},
+ * @ref{Vector}@p{<double>},
+ * @ref{BlockVector}@p{<...>}, or any
* other type having the same
* interface.
*/
* For the reason why we use a vector
* instead of a map and the consequences
* thereof, the same applies as what is
- * said for @p{ConstraintMatrix::lines}.
+ * said for @ref{ConstraintMatrix}@p{::lines}.
*/
vector<pair<unsigned int,double> > entries;
*
* The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
*/
-class DoFDimensionInfo<1> {
+class DoFDimensionInfo<1>
+{
public:
typedef TriaRawIterator<1,DoFCellAccessor<1> > raw_line_iterator;
typedef TriaIterator<1,DoFCellAccessor<1> > line_iterator;
};
+
/**
* Define some types for the DoF handling in two dimensions.
*
* The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
*/
-class DoFDimensionInfo<2> {
+class DoFDimensionInfo<2>
+{
public:
typedef TriaRawIterator<2,DoFObjectAccessor<1, 2> > raw_line_iterator;
typedef TriaIterator<2,DoFObjectAccessor<1, 2> > line_iterator;
};
+
/**
* Define some types for the DoF handling in two dimensions.
*
* The types have the same meaning as those declared in @ref{TriaDimensionInfo<3>}.
*/
-class DoFDimensionInfo<3> {
+class DoFDimensionInfo<3>
+{
public:
typedef TriaRawIterator<3,DoFObjectAccessor<1, 3> > raw_line_iterator;
typedef TriaIterator<3,DoFObjectAccessor<1, 3> > line_iterator;
};
+
/**
* Manage the distribution and numbering of the degrees of freedom for
* non-multigrid algorithms.
* by offering @p{begin()} and @p{end()} functions which return iterators
* to walk on the DoF structures as well as the triangulation data.
* These iterators work much like those described in the documentation
- * of the @p{Triangulation} class and of the iterator classes themselved,
+ * of the @ref{Triangulation} class and of the iterator classes themselved,
* but offer more functionality than pure triangulation iterators. The
* order in which dof iterators are presented by the @p{++} and @p{--} operators
* is the same as that for the alike triangulation iterators.
*
* This numbering implies very large bandwiths of the resulting matrices and
* is thus vastly suboptimal for some solution algorithms. For this reason,
- * the @p{DoFRenumbering} class offers the function @p{renumber_dofs} which reorders
+ * the @ref{DoFRenumbering} class offers the function @p{renumber_dofs} which reorders
* the dof numbering according to some scheme. See there for a discussion of
* the implemented algorithms.
*
*
* @sect3{User defined renumbering schemes}
*
- * The @p{DoFRenumbering} class offers a fixed number of renumbering
+ * The @ref{DoFRenumbering} class offers a fixed number of renumbering
* schemes like the Cuthill-McKey scheme. Basically, the function sets
* up an array in which for each degree of freedom the index is stored
* which is to be assigned by the renumbering. Using this array, the
* Lagrange elements this is the point where it has the function value @p{1}), is
* located on the boundary. We do not check this directly, the criterion is
* rather defined through the information the finite element class gives: the
- * @p{FiniteElementBase} class defines the numbers of basis functions per vertex,
+ * @ref{FiniteElementBase} class defines the numbers of basis functions per vertex,
* per line, and so on and the basis functions are numbered after this
* information; a basis function is to be considered to be on the face of a
* cell (and thus on the boundary if the cell is at the boundary) according
* This is the maximum number of entries
* per line in the system matrix; this
* information can therefore be used upon
- * construction of the @p{SparsityPattern}
+ * construction of the @ref{SparsityPattern}
* object.
*
* The returned number is not really the
* Store the indices of the degrees of freedom which are located on the lines.
* Declare it to have a template parameter, but do not actually declare
* other types than those explicitely instantiated.
+ *
+ * @author Wolfgang Bangerth, 1998
*/
template <int N>
class DoFLevel
/**
* Store the indices of the degrees of freedom which are located on the lines.
*
- * @sect3{Information for all @p{DoFLevel} classes}
+ * @sect3{Information for all @ref{DoFLevel} classes}
*
- * The @p{DoFLevel<N>} classes
+ * The @ref{DoFLevel}@p{<N>} classes
* store the global indices of the degrees of freedom for each cell on a
* certain level. The index or number of a degree of freedom is the zero-based
* index of the according value in the solution vector and the row and column
* $\ldots, u_1^m, u_2^m, u_1^{m+1}, u_2^{m+1},\ldots$ with $m$ denoting the
* $m$th basis function, or $\ldots, u_1^m, u_1^{m+1}, u_1^{m+2}, \ldots,
* u_2^m, u_2^{m+1}, u_2^{m+2}, \ldots$, respectively). Likewise, the
- * constraint matrix returned by @p{DoFHandler::make_hanging_node_constraints ()}
+ * constraint matrix returned by @ref{DoFHandler}@p{::make_hanging_node_constraints ()}
* is then
* to be understood as a block matrix.
*
* The storage format of the degrees of freedom indices (short: DoF indices) is
* somewhat like a mirror of the data structures of the triangulation classes.
- * There is a hierarchy of @p{DoFLevel<dim>} classes for the different dimensions
+ * There is a hierarchy of @ref{DoFLevel}@p{<dim>} classes for the different dimensions
* which have objects named @p{line_dofs}, @p{quad_dofs} and so on, in which the
* indices of DoFs located on lines and quads, respectively, are stored. The
* indices are stored levelwise. The layout in
* these arrays is as follows: if for a selected finite element (use
- * @p{DoFHandler::distribute_dofs()} to select a finite element) the number of
+ * @ref{DoFHandler}@p{::distribute_dofs()} to select a finite element) the number of
* DoFs on each line (without those in the vertices) is @p{N}, then the length
* of the @p{line_dofs} array is @p{N} times the number of lines on this level. The
* DoF indices for the @p{i}th line are at the positions @p{N*i...(N+1)*i-1}.
*
* The DoF indices for vertices are not stored this way, since they need
* different treatment in multigrid environments. If no multigrid is used, the
- * indices are stored in the @p{vertex_dofs} array of the @p{DoFHandler} class.
+ * indices are stored in the @p{vertex_dofs} array of the @ref{DoFHandler} class.
+ *
+ * @author Wolfgang Bangerth, 1998
*/
class DoFLevel<1>
{
};
+
/**
* Store the indices of the degrees of freedom which are located on quads.
* See @ref{DoFLevel<1>} for more information.
+ *
+ * @author Wolfgang Bangerth, 1998
*/
-class DoFLevel<2> : public DoFLevel<1> {
+class DoFLevel<2> : public DoFLevel<1>
+{
public:
/**
* Store the global indices of the degrees
};
+
/**
* Store the indices of the degrees of freedom which are located on hexhedra.
* See @ref{DoFLevel<1>} for more information.
+ *
+ * @author Wolfgang Bangerth, 1998
*/
-class DoFLevel<3> : public DoFLevel<2> {
+class DoFLevel<3> : public DoFLevel<2>
+{
public:
/**
* Store the global indices of the degrees
* documentation stating some commonalities.
*
* All member functions are static, so there is no need to create an
- * object of class @p{DoFTools}.
+ * object of class @ref{DoFTools}.
*
* @sect3{Setting up sparsity patterns}
*
* of hanging nodes. They have
* to be taken care of by a call
* to
- * @p{ConstraintMatrix::condense()}
+ * @ref{ConstraintMatrix}@p{::condense()}
* afterwards.
*
* Remember using
- * @p{SparsityPattern::compress()}
+ * @ref{SparsityPattern}@p{::compress()}
* after generating the pattern.
*
* The actual type of the
* sparsity pattern may be
- * @p{SparsityPattern},
- * @p{BlockSparsityPattern}, or any
+ * @ref{SparsityPattern},
+ * @ref{BlockSparsityPattern}, or any
* other class that satisfies
* similar requirements.
*/
*
* in two space dimensions,
* using stable Q2/Q1 mixed
- * elements (using the @p{FESystem}
+ * elements (using the @ref{FESystem}
* class), then you don't want
* all degrees of freedom to
* couple in each equation. You
* @end{verbatim}
* where "1" indicates that two
* variables (i.e. components of
- * the @p{FESystem}) couple in the
+ * the @ref{FESystem}) couple in the
* respective equation, and a "0"
* means no coupling, in which
* case it is not necessary to
* allocate space in the matrix
* structure. Obviously, the mask
* refers to components of the
- * composed @p{FESystem}, rather
+ * composed @ref{FESystem}, rather
* than to the degrees of freedom
* contained in there.
*
*
* The actual type of the
* sparsity pattern may be
- * @p{SparsityPattern},
- * @p{BlockSparsityPattern}, or any
+ * @ref{SparsityPattern},
+ * @ref{BlockSparsityPattern}, or any
* other class that satisfies
* similar requirements.
*/
* nodes. The sparsity pattern
* is not compressed, since if
* you want to call
- * @p{ConstraintMatrix::condense(1)}
+ * @ref{ConstraintMatrix}@p{::condense(1)}
* afterwards, new entries have
* to be added. However, if you
* don't want to call
- * @p{ConstraintMatrix::condense(1)},
+ * @ref{ConstraintMatrix}@p{::condense(1)},
* you have to compress the
* matrix yourself, using
- * @p{SparsityPattern::compress()}.
+ * @ref{SparsityPattern}@p{::compress()}.
*
* Since this function is
* obviously useless in one
* function.
*
* To condense a given sparsity pattern,
- * use @p{ConstraintMatrix::condense}.
+ * use @ref{ConstraintMatrix}@p{::condense}.
* Before doing so, you need to close
* the constraint object, which must be
* done after all constraints are entered.
* continuous at hanging nodes. This can,
* however, easily be arranged by calling
* the appropraite @p{distribute} function
- * of a @p{ConstraintMatrix} object created
- * for this @p{DoFHandler} object.
+ * of a @ref{ConstraintMatrix} object created
+ * for this @ref{DoFHandler} object.
*
* It is assumed that the number of
* elements in @p{cell_data} equals the
* of freedom belonging to certain
* components. The bit vector @p{select}
* defines, which components of an
- * @p{FESystem} are to be extracted
- * from the DoFHandler @p{dof}. The
+ * @ref{FESystem} are to be extracted
+ * from the @ref{DoFHandler} @p{dof}. The
* respective entries in @p{selected_dofs}
* are then flagged @p{true}, while all
* others are set to @p{false}.
* to the variable ``q''; zero
* would be ``u'', two would be
* ``lambda''). Furthermore, an
- * object of type @p{IntergridMap}
+ * object of type @ref{IntergridMap}
* is needed; this could in
* principle be generated by the
* function itself from the two
* it. Finally, the computed
* constraints are entered into a
* variable of type
- * @p{ConstraintMatrix}; the
+ * @ref{ConstraintMatrix}; the
* constraints are added,
* i.e. previous contents which
* may have, for example, be
*
* The faces of a hexahedron are arranged in a way such that
* some must be viewed from the inside and some from the outside of the cell to
- * show this order; refer to the documentation of the @p{Triangulation} class for
+ * show this order; refer to the documentation of the @ref{Triangulation} class for
* the definition of this.
*
* If of the cells adjacent to one line more than one is refined and there is
* of this class.
*
* This also is used in some sense in the
- * @p{DoFHandler::distribute_cell_to_dof_vector} where it is assumed that
+ * @ref{DoFHandler}@p{::distribute_cell_to_dof_vector} where it is assumed that
* the degrees of freedom denote function values and not derivatives or
* the like.
*
*
* This assumption is used in the @p{VectorTools::project_boundary_values},
* @p{MatrixCreator::create_boundary_mass_matrix},
- * @p{DoFHandler::make_boundary_sparsity_pattern},
- * @p{DoFHandler::map_dof_to_boundary_indices} and may be a few other places.
- * The places in the @p{DoFHandler} class are probably not that dangerous,
+ * @ref{DoFHandler}@p{::make_boundary_sparsity_pattern},
+ * @ref{DoFHandler}@p{::map_dof_to_boundary_indices} and may be a few other places.
+ * The places in the @ref{DoFHandler} class are probably not that dangerous,
* since wrong results will most likely lead to internal errors through
* the @p{Assert} mechanism, but the first places will lead to undiscovered
* errors if not thought of properly.
* constrained nodes happens with the face nodes on the large call. If
* the assumption does not hold, then the distribution has to happen
* with all nodes on the small and the large cells. This is not
- * implemented in the @p{DoFHandler} class as of now.
+ * implemented in the @ref{DoFHandler} class as of now.
* @end{itemize}
*
* @author Wolfgang Bangerth, 1998
* quadrature points which also
* use the standard direction of
* faces as laid down by the
- * @p{Triangulation} class.
+ * @ref{Triangulation} class.
*
* There is a standard
* implementation for dimensions
* is declared.
*
* The function takes a
- * @p{DoFHandler} iterator, which
+ * @ref{DoFHandler} iterator, which
* provides a superset of
* information to the geometrical
* information needed for the
* computations. The additional
* data should not be used,
- * however a @p{DoFHandler}
+ * however a @ref{DoFHandler}
* iterator was preferred over a
- * @p{Triangulation} iterator
+ * @ref{Triangulation} iterator
* since this is what usually is
* available in places where this
* function is called.
* Gives the interpolation of a the
* @p{dof1}-function @p{u1} to a
* @p{dof2}-function @p{u2}. @p{dof1} and
- * @p{dof2} need to be @p{DoFHandler}s
+ * @p{dof2} need to be @ref{DoFHandler}s
* based on the same triangulation.
*
* If the elements @p{fe1} and @p{fe2}
* extrapolation of a @p{dof1}
* function @p{z1} to a @p{dof2}
* function @p{z2}. @p{dof1} and
- * @p{dof2} need to be @p{DoFHandler}
+ * @p{dof2} need to be @ref{DoFHandler}
* based on the same triangulation.
*
* This function is interesting for
* the need to pass the cell iterator again to these two functions,
* which guarantees that the cell used here is in sync with that used
* for the @p{reinit} function. You should, however, make sure that
- * nothing substantial happens to the @p{DoFHandler} object or any
+ * nothing substantial happens to the @ref{DoFHandler} object or any
* other involved instance between the @p{reinit} and the @p{get_function_*}
* functions are called.
*
* the convention is used that the unit cell/face be the tensor product of the
* interval $[-1,1]$, which is to distinguished properly. A subface is the
* child of a face; they are numbered in the way laid down in the
- * @p{Triangulation} class.
+ * @ref{Triangulation} class.
*
* Just like in the @p{FEValues} class, function values and gradients on the unit
* face or subface are evaluated at the quadrature points only once, and stored
template <int _dim> struct GeometryInfo;
/**
- * Pseudo-class for recursive functions in @p{GeometryInfo<dim>}.
+ * Pseudo-class for recursive functions in @ref{GeometryInfo}@p{<dim>}.
*/
struct GeometryInfo<0>
{
};
+
/**
* Topological description of cells.
*
* This class contains as static members information on vertices and
- * faces of a @p{dim}-dimensinal grid cell. The interface is the same
+ * faces of a @p{dim}-dimensional grid cell. The interface is the same
* for all dimensions. If a value is of no use in a low dimensional
* cell, it is (correctly) set to zero, e.g. @p{sub_faces_per_cell} in
* 1d.
* For three spatial dimensions,
* the exact order of the children is
* laid down in the documentation of
- * the @p{Triangulation} class.
+ * the @ref{Triangulation} class.
*/
static unsigned int child_cell_on_face (unsigned int face,
unsigned int subface);
* the middle line would get the direction @p{1->4} when viewed from both cells.
* The numbering (0 1 4 3) and (5 4 1 2) would not be allowed, since the left
* quad would give the common line the direction @p{1->4}, while the right one
- * would want to use @p{4->1}, leading to ambiguity. The @p{Triangulation} object
+ * would want to use @p{4->1}, leading to ambiguity. The @ref{Triangulation} object
* is capable of detecting this special case, which can be eliminated by
* rotating the indices of the right quad by two. However, it would not
* know what to do if you gave the vertex indices (4 1 2 5), since then it
* the different output functions based on a parameter given, e.g., through
* a parameter file, thus making user programs invariant of the number and
* names of the file formats implemented in this class. The main advantage of
- * this class over the @p{DataOut} class is that it does not have to mess around
- * with actual data vectors and that no @p{DoFHandler} object is needed to
+ * this class over the @ref{DataOut} class is that it does not have to mess around
+ * with actual data vectors and that no @ref{DoFHandler} object is needed to
* write the pure geometrical information involved here.
*
* Available output formats can be found in the functions with names @p{write_...}
* GridOut().write (tria, output_file, output_format);
* @end{verbatim}
* The function @p{get_output_format_names()} provides a list of possible names of
- * output formats in a string that is understandable by the @p{ParameterHandler} class.
+ * output formats in a string that is understandable by the @ref{ParameterHandler} class.
*
- * Note that here, we have created an unnamed object of type @p{GridOut} and called
+ * Note that here, we have created an unnamed object of type @ref{GridOut} and called
* one of its @p{write_*} functions. This looks like as if the respective function
* could really be made @p{static}. This was not done in order to allow for
* parameters to be passed to the different output functions in a way compatible
* output format supported which it may then pass on to the respective output
* function.
*
- * Rather, we have chosen to let each object of this class @p{GridOut} have a
+ * Rather, we have chosen to let each object of this class @ref{GridOut} have a
* set of parameters for each supported output format. These are collected
- * in structures @p{EpsFlags}, @p{GnuplotFlags}, etc and you can set your preferred
+ * in structures @ref{EpsFlags}, @ref{GnuplotFlags}, etc and you can set your preferred
* flags like this:
* @begin{verbatim}
* GridOut grid_out;
* flags controlling the output
* can be found in the
* documentation of the
- * @p{GridOut::GnuplotFlags} class.
+ * @ref{GridOut::GnuplotFlags} class.
*/
template <int dim>
void write_gnuplot (const Triangulation<dim> &tria,
* only, you can decide through
* additional flags (see below,
* and the documentation of the
- * @p{GridOut::UcdFlags} class)
+ * @ref{GridOut::UcdFlags} class)
* whether boundary faces with
* non-zero boundary indicator
* shall be written to the file
* flags controlling the output
* can be found in the
* documentation of the
- * @p{GridOut::UcdFlags} class.
+ * @ref{GridOut::UcdFlags} class.
*/
template <int dim>
void write_ucd (const Triangulation<dim> &tria,
* shall fit into is determined
* by the output flags (see
* below, and the documentation
- * of the @p{GridOut::EpsFlags}
+ * of the @ref{GridOut::EpsFlags}
* class).
*
* The bounding box is close to
* flags controlling the output
* can be found in the
* documentation of the
- * @p{GridOut::EpsFlags}
+ * @ref{GridOut::EpsFlags}
* class. Especially the
* viewpoint for three
* dimensional grids is of
*
* To get a list of presently available
* format names, e.g. to give it to the
- * @p{ParameterHandler} class, use the
+ * @ref{ParameterHandler} class, use the
* function @p{get_output_format_names ()}.
*/
static OutputFormat parse_output_format (const string &format_name);
* Return a list of implemented output
* formats. The different names are
* separated by vertical bar signs (@p{`|'})
- * as used by the @p{ParameterHandler}
+ * as used by the @ref{ParameterHandler}
* classes.
*/
static string get_output_format_names ();
*
* The implementation of this class is such that not only cell iterators
* into triangulations can be mapped, but also iterators into objects of
- * type @p{DoFHandler} and @p{MGDoFHandler}. The extension to other classes
+ * type @ref{DoFHandler} and @ref{MGDoFHandler}. The extension to other classes
* offering iterator functions and some minor additional requirements is
* simple.
*
* Note that the template parameters to this class have to be given as
* @p{InterGridMap<DoFHandler,2>}, i.e. the dimension is given explicitely and
* no dimension is attributed to the first parameter, which here is
- * @p{DoFHandler} (and could equally well be @p{Triangulation} or @p{MGDoFHandler}).
+ * @ref{DoFHandler} (and could equally well be @ref{Triangulation} or @ref{MGDoFHandler}).
*
* @author Wolfgang Bangerth, 1999
*/
* of cell numbers to the geometrical cells.
*
* Basically, this is a drop-in replacement for the triangulation. Since it
- * is derived from the @p{Triangulation<dim>} class, it shares all the
+ * is derived from the @ref{Triangulation} class, it shares all the
* functionality, but it overrides some virtual functions and adds some
* functions, too. The main change to the base class is that it overrides
* the @p{execute_coarsening_and_refinement} function, where the new version
*
* We note that since the triangulation is created in exactly the same state
* as it was before, other objects working on it should result in the same
- * state as well. This holds in particular for the @p{DoFHandler} object, which
+ * state as well. This holds in particular for the @ref{DoFHandler} object, which
* will assign the same degrees of freedom to the original cells and the ones
* after reconstruction of the triangulation. You can therefore safely use data
* vectors computed on the original grid on the reconstructed grid as well.
*
* @sect3{Usage}
* You can use objects of this class almost in the same way as objects of the
- * @p{Triangulation} class. One of the few differences is that you can only
+ * @ref{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
* coarse grid will be used to base the triangulation on, and therefore the
* lifetime of the coarse grid has to be longer than the lifetime of the
* };
* @end{verbatim}
*
- * Note that initially, the @p{PersistentTriangulation} object does not
+ * Note that initially, the @ref{PersistentTriangulation} object does not
* constitute a triangulation; it only becomes one after @p{restore} is first
* called. Note also that the @p{execute_coarsening_and_refinement} stores
* all necessary flags for later reconstruction using the @p{restore} function.
- * @p{Triangulation<dim>::clear ()} resets the underlying triangulation to a
+ * @ref{Triangulation}@p{<dim>::clear ()} resets the underlying triangulation to a
* virgin state, but does not affect the stored refinement flags needed for
* later reconstruction and does also not touch the coarse grid which is
* used withing @p{restore()}.
/**
- * @p{Triangulation}s denote a hierarchy of levels of elements which together
+ * @ref{Triangulation}s denote a hierarchy of levels of elements which together
* form a region in @p{dim} spatial dimensions.
*
* This class is written to be as independent of the dimension as possible
*
* @sect3{Structure and iterators}
*
- * The actual data structure of a @p{Triangulation} object is rather complex
+ * The actual data structure of a @ref{Triangulation} object is rather complex
* and quite inconvenient if one attempted to operate on it directly, since
* data is spread over quite a lot of arrays and other places. However,
* there are ways powerful enough to work on these data structures
* is reasonable for a cell in the respective dimension, i.e. a @p{Line} in
* one dimension, a @p{Quad} in two dimensions, and so on.
*
- * The @p{Triangulation} class provides iterator which enable looping over all
+ * The @ref{Triangulation} class provides iterator which enable looping over all
* lines, cells,
* etc without knowing the exact representation used to describe them. Their
* names are typedefs in the @ref{TriaDimensionInfo} base class (thus making them
* cell is be a vertex in 1D and a line in 2D; however, vertices are
* handled in a different way and therefore lines have no faces.
*
- * The @p{Triangulation} class offers functions like @p{begin_active} which gives
+ * The @ref{Triangulation} class offers functions like @p{begin_active} which gives
* you an iterator to the first active cell. There are quite a lot of functions
* returning iterators. Take a look at the class doc to get an overview.
*
* Usage of these iterators works mostly like with the STL iterators. Some
- * examples taken from the @p{Triangulation} source code follow.
+ * examples taken from the @ref{Triangulation} source code follow.
* @begin{itemize}
* @item @em{Counting the number of cells on a specific level}
* @begin{verbatim}
*
* @sect3{Usage}
*
- * Usage of a @p{Triangulation} is mainly done through the use of iterators.
+ * Usage of a @ref{Triangulation} is mainly done through the use of iterators.
* An example probably shows best how to use it:
* @begin{verbatim}
* void main () {
* @p{execute_*} stand for @p{execute_coarsening_and_refinement}.
*
* For the purpose of smoothing, the
- * @p{Triangulation} constructor takes an argument specifying whether a
+ * @ref{Triangulation} constructor takes an argument specifying whether a
* smoothing step shall be performed on the grid each time @p{execute_*}
* is called. The default is that such a step not be done, since this results
* in additional cells being produced, which may not be necessary in all
* boundary, this function is used to compute where it will be
* placed. The boundary indicator of the face will be used to
* determine the proper component. See @ref{Boundary} for the
- * details. Usage with the @p{Triangulation} object is then like this
+ * details. Usage with the @ref{Triangulation} object is then like this
* (let @p{Ball} be a class derived from @ref{Boundary}@p{<2>}):
*
* @begin{verbatim}
};
+
/**
* Common template for line, quad, hex accessors.
* According to @p{celldim} objects of this class represent lines,
*/
void set (const Line&) const;
+
/**
* Copy the data of the given quad. Only
* implemented for @p{celldim==2}.
*/
void set (const Quad&) const;
+
/**
* Copy the data of the given hex. Only
* implemented for @p{celldim==3}.
* Index of vertex. The convention regarding the
* numbering of vertices is laid down
* in the documentation of the
- * @p{Triangulation} class.
+ * @ref{Triangulation} class.
*/
int vertex_index (const unsigned int i) const;
* the use of this function is only
* possible for @p{dim>celldim};
* however, for @p{dim==celldim}, an object is
- * a cell and the @p{CellAccessor} class
+ * a cell and the @ref{CellAccessor} class
* offers another possibility to
* determine whether a cell is at the
* boundary or not.
};
+
/**
* Closure class to stop induction of classes. Should never be called and thus
* producesan error when created.
};
+
/**
* Accessor to dereference the data of lines. This accessor is used to
* point to lines in @p{dim} space dimensions. There is a derived class
* interior of the domain. Obviously,
* this is only possible for @p{dim>1};
* however, for @p{dim==1}, a line is
- * a cell and the @p{CellAccessor} class
+ * a cell and the @ref{CellAccessor} class
* offers another possibility to
* determine whether a cell is at the
* boundary or not.
};
+
/**
* Accessor to dereference the data of quads. This accessor is used to
* point to quads in @p{dim} space dimensions (only @p{dim>=2} seems reasonable
/**
* Return a pointer to the @p{i}th line
- * bounding this @p{Quad}.
+ * bounding this @ref{Quad}.
*/
TriaIterator<dim,TriaObjectAccessor<1, dim> >
line (const unsigned int i) const;
* interior of the domain. Obviously,
* this function is only useful for @p{dim>2};
* however, for @p{dim==2}, a quad is
- * a cell and the @p{CellAccessor} class
+ * a cell and the @ref{CellAccessor} class
* offers another possibility to
* determine whether a cell is at the
* boundary or not.
};
+
/**
* Accessor to dereference the data of hexahedra. This accessor is used to
* point to hexs in @p{dim} space dimensions (only @p{dim>=3} seems reasonable
* a hex. The convention regarding the
* numbering of vertices is laid down
* in the documentation of the
- * @p{Triangulation} class.
+ * @ref{Triangulation} class.
*/
int vertex_index (const unsigned int i) const;
* the use of this function is only
* possible for @p{dim>3};
* however, for @p{dim==3}, a hex is
- * a cell and the @p{CellAccessor} class
+ * a cell and the @ref{CellAccessor} class
* offers another possibility to
* determine whether a cell is at the
* boundary or not.
};
+
/**
* This class allows access to a cell: a line in one dimension, a quad
* in two dimension, etc.
};
+
// if in optimized mode: include more templates
#ifndef DEBUG
# include "tria_accessor.templates.h"
* about boundary indicators and the like, as well as all other information
* provided by these objects.
*
- * There are specialisations, @p{StraightBoundary<dim>}, which places
+ * There are specialisations, @ref{StraightBoundary}, which places
* the new point right into the middle of the given points, and
- * @p{HyperBallBoundary<dim>} creating a hyperball with given radius
+ * @ref{HyperBallBoundary} creating a hyperball with given radius
* around a given center point.
*
* @author Wolfgang Bangerth, 1999
*/
template <int dim>
-class Boundary : public Subscriptor {
+class Boundary : public Subscriptor
+{
public:
/**
* Destructor. Does nothing here, but
};
+
/**
* Specialisation of @ref{Boundary}<dim>, which places the new point right
* into the middle of the given points. The middle is defined as the
};
+
/*---------------------------- boundary-function.h ---------------------------*/
#endif
* The center of the ball and its radius may be given upon construction of
* an object of this type. They default to the origin and a radius of 1.0.
*
- * This class is derived from @p{StraightBoundary} rather than from
- * @p{Boundary}, which would seem natural, since this way we can use the
- * @p{StraightBoundary<dim>::in_between(neighbors)} function.
+ * This class is derived from @ref{StraightBoundary} rather than from
+ * @ref{Boundary}, which would seem natural, since this way we can use the
+ * @ref{StraightBoundary}@p{<dim>::in_between(neighbors)} function.
*
* @author Wolfgang Bangerth, 1998
*/
/**
- * Variant of @p{HyperBallBoundary} which denotes a half hyper ball
+ * Variant of @ref{HyperBallBoundary} which denotes a half hyper ball
* where the first coordinate is restricted to the range $x>=0$ (or
* $x>=center(0)$). In two dimensions, this equals the right half
* circle, in three space dimensions it is a half ball. This class
/**
- * Variant of @p{HyperShellBoundary} which denotes a half hyper shell
+ * Variant of @ref{HyperShellBoundary} which denotes a half hyper shell
* where the first coordinate is restricted to the range $x>=0$ (or
* $x>=center(0)$). In two dimensions, this equals the right half arc,
* in three space dimensions it is a half shell. This class might be
* of the triangulation.
*
* For conventions on the numbering of faces, lines and vertices within a
- * hexahedron, refer to the documentation of the @p{Triangulation} class.
+ * hexahedron, refer to the documentation of the @ref{Triangulation} class.
*
* @author Wolfgang Bangerth, 1998
*/
-class Hexahedron {
+class Hexahedron
+{
public:
/**
inline
Hexahedron::Hexahedron (const int i0, const int i1,
const int i2, const int i3,
- const int i4, const int i5) {
+ const int i4, const int i5)
+{
quads[0] = i0;
quads[1] = i1;
quads[2] = i2;
};
+
inline
-int Hexahedron::quad (const int i) const {
+int Hexahedron::quad (const int i) const
+{
Assert ((i>=0) && (i<6),
ExcRange(i));
return quads[i];
};
+
inline
-void Hexahedron::set_quad (const int i, const int index) {
+void Hexahedron::set_quad (const int i, const int index)
+{
Assert ((i>=0) && (i<6),
ExcRange(i));
quads[i] = index;
* the creation and copying of these iterators is rather expensive
* compared to normal pointers.
*
- * The objects pointed to by iterators are @p{TriangulationLevel<1>::LinesData},
- * @p{TriangulationLevel<2>::LinesData}
- * and @p{TriangulationLevel<2>::QuadsData}. To chose which of those, the
+ * The objects pointed to by iterators are @ref{TriangulationLevel<1>}@p{::LinesData},
+ * @ref{TriangulationLevel<2>}@p{::LinesData}
+ * and @ref{TriangulationLevel<2>}@p{::QuadsData}. To chose which of those, the
* template parameter @p{Pointee} is used.
*
- * Since the names as is are quite unhandy, the @p{Triangulation<>} class which
+ * Since the names as is are quite unhandy, the @ref{Triangulation} class which
* uses these iterators declares typedef'd versions. See there for more
* information.
*
- * The objects pointed to are, as mentioned, @p{LinesData} etc. To be
- * more exact, when dereferencing an iterator, you do not get a @p{LineData}
+ * The objects pointed to are, as mentioned, @ref{LinesData} etc. To be
+ * more exact, when dereferencing an iterator, you do not get a @ref{LineData}
* object (or the like, but we will assume that you have a @p{line_iterator}
* in the following), but a @em{virtual} object (called @em{accessor}) which
* behaves as if it stored the data of a line. It does not contain any data
*
* Since the data of one line is splitted to
* several arrays (@p{lines}, @p{children} and @p{used}) for performance reasons
- * rather than keeping all information in a @p{Line} struct, access through
+ * rather than keeping all information in a @ref{Line} struct, access through
* an accessor is usually much simpler than handling the exact data structure
* and also less error prone since the data structure itself can be changed
* in an arbitrary way while the only pieces of code which access these
* your own version (non-virtual, since we use templates) to add functionality.
*
* There is a standard implementation, using classes which are derived from
- * @ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
+ * @ref{TriaAccessor}. These classes point to @ref{Line}s, @ref{Quad}s and the like.
* For advanced use of the iterator classes, derive classes from
* @p{{Line|Quad|Cell}Accessor} which also dereference data structures in other
* objects, e.g. in a finite element context. An iterator with such an accessor
* then simultaneously points to (for example) a cell in the triangulation and
* the data stored on it in the finite element class.
*
- * Derived accessor classes may need additional data (e.g. the @p{DoFAccessor}
- * needs a pointer to the @p{DoFHandler} to work on). This data can be
+ * Derived accessor classes may need additional data (e.g. the @ref{DoFAccessor}
+ * needs a pointer to the @ref{DoFHandler} to work on). This data can be
* set upon construction through the last argument of the constructors.
* The data type of this additional data is given by the local data type
- * @p{AccessorData} explained above. The iterator classes take a pointer to
+ * @ref{AccessorData} explained above. The iterator classes take a pointer to
* an object of that data type; by default, this parameter equals the
* @p{NULL} pointer.
*
* past the end; in all other cases, the iterator is considered invalid.
* You can check this by calling the @p{state()} function.
*
- * An iterator is also invalid, if the pointer pointing to the @p{Triangulation}
+ * An iterator is also invalid, if the pointer pointing to the @ref{Triangulation}
* object is invalid or zero.
*
* Finally, an iterator is invalid, if the element pointed to by
* class of this object. One such path
* would be derived class to base class,
* which for example may be used to get
- * a @p{Triangulation::raw_cell_iterator} from
- * a @p{DoFHandler::raw_cell_iterator}, since
- * the @p{DoFAccessor} class is derived from
- * the @p{TriaAccessor} class.
+ * a @ref{Triangulation}@p{::raw_cell_iterator} from
+ * a @ref{DoFHandler}@p{::raw_cell_iterator}, since
+ * the @ref{DoFAccessor} class is derived from
+ * the @ref{TriaAccessor} class.
*
- * Since @p{TriaIterator} and
- * @p{TriaActiveIterator} are derived classes
+ * Since @ref{TriaIterator} and
+ * @ref{TriaActiveIterator} are derived classes
* of this class, this constructor also
* serves to convert these iterators with
* other accessor classes.
* class of this object. One such path
* would be derived class to base class,
* which for example may be used to get
- * a @p{Triangulation::cell_iterator} from
- * a @p{DoFHandler::cell_iterator}, since
- * the @p{DoFAccessor} class is derived from
- * the @p{TriaAccessor} class.
+ * a @ref{Triangulation}@p{::cell_iterator} from
+ * a @ref{DoFHandler}@p{::cell_iterator}, since
+ * the @ref{DoFAccessor} class is derived from
+ * the @ref{TriaAccessor} class.
*
- * Since @p{TriaActiveIterator} is a derived
+ * Since @ref{TriaActiveIterator} is a derived
* class of this class, this constructor
* also serves to convert these iterators
* with other accessor classes.
* class of this object. One such path
* would be derived class to base class,
* which for example may be used to get
- * a @p{Triangulation::active_cell_iterator} from
- * a @p{DoFHandler::active_cell_iterator}, since
- * the @p{DoFAccessor} class is derived from
- * the @p{TriaAccessor} class.
+ * a @ref{Triangulation}@p{::active_cell_iterator} from
+ * a @ref{DoFHandler}@p{::active_cell_iterator}, since
+ * the @ref{DoFAccessor} class is derived from
+ * the @ref{TriaAccessor} class.
*/
template <typename OtherAccessor>
TriaActiveIterator (const TriaActiveIterator<dim,OtherAccessor> &i);
/**
* Store all information which belongs to one level of the multilevel hierarchy.
*
- * In @p{TriangulationLevel<0>} all data is stored which is not
+ * In @ref{TriangulationLevel<0>} all data is stored which is not
* dependant on the dimension, e.g. a field to store the
* refinement flag for the cells (what a cell actually is
* is declared elsewhere), etc. Actually, it is only cell-based
* called with the prepro flag @p{DEBUG}
* set. The function should be called from
* the functions of the higher
- * @p{TriangulationLevel} classes.
+ * @ref{TriangulationLevel} classes.
*/
void monitor_memory (const unsigned int true_dimension) const;
*
* In one dimension, this is a list of the lines associated with this level,
* as well as a list with the indices of the children of these lines.
- * The @p{TriangulationsLevel} objects of higher dimensions are derived from
+ * The @ref{TriangulationsLevel} objects of higher dimensions are derived from
* this one.
*
* @author Wolfgang Bangerth, 1998
* stored in this list. A line is
* called active if it has no
* children. The function
- * @p{TriaIterator::active()}
+ * @ref{TriaIterator}@p{::active()}
* tests for this.
*/
vector<int> children;
* already been processed.
*
* You can clear all used flags using
- * @p{Triangulation<>::clear_user_flags()}.
+ * @ref{Triangulation}@p{::clear_user_flags()}.
*/
vector<bool> user_flags;
* between the number of new quads and
* the number of new lines, etc.). Also
* don't forget to call the
- * @p{TriangulationLevel<0>::reserve_space}
+ * @ref{TriangulationLevel<0>}@p{::reserve_space}
* function.
*/
void reserve_space (const unsigned int new_lines);
* called with the prepro flag @p{DEBUG}
* set. The function should be called from
* the functions of the higher
- * @p{TriangulationLevel} classes.
+ * @ref{TriangulationLevel} classes.
*/
void monitor_memory (const unsigned int true_dimension) const;
};
* information about the children of these lines and quads.
*
* The vector of lines and their children is derived from
- * @p{TriangulationLevel<1>}.
+ * @ref{TriangulationLevel<1>}.
*
* @author Wolfgang Bangerth, 1998
*/
* level.
*
* It is fully analogous to the
- * @p{LinesData} structure inherited from
- * @p{Triangulation<1>}.
+ * @ref{TriangulationLevel<1>::LinesData} structure inherited from
+ * @ref{Triangulation}@p{<1>}.
*/
struct QuadsData
{
*/
vector<Quad> quads;
/**
- * Same as for the @p{LineData::chilren}
+ * Same as for the @ref{TriangulationLevel<1>::LinesData}@p{::chilren}
* array, but since there are four
* children, the index points to the
* first while the other three are
vector<int> children;
/**
- * Same as for @p{LineData::used}.
+ * Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
*/
vector<bool> used;
/**
- * Same as for @p{LineData::used}.
+ * Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
*/
vector<bool> user_flags;
* called with the prepro flag @p{DEBUG}
* set. The function should be called from
* the functions of the higher
- * @p{TriangulationLevel} classes.
+ * @ref{TriangulationLevel} classes.
*/
void monitor_memory (const unsigned int true_dimension) const;
};
* information about the children of these lines, quads and hexs.
*
* The vectors of lines and quads and their children are derived from
- * @p{TriangulationLevel<2>}.
+ * @ref{TriangulationLevel<2>}.
*
* @author Wolfgang Bangerth, 1998
*/
* level.
*
* It is fully analogous to the
- * @p{LinesData} structure inherited from
- * @p{Triangulation<1>}.
+ * @ref{TriangulationLevel<1>::LinesData} structure inherited from
+ * @ref{Triangulation<1>}.
*/
struct HexesData
{
*/
vector<Hexahedron> hexes;
/**
- * Same as for the @p{LineData::chilren}
+ * Same as for the @ref{TriangulationLevel<1>::LinesData}@p{::chilren}
* array, but since there are four
* children, the index points to the
* first while the other three are
vector<int> children;
/**
- * Same as for @p{LineData::used}.
+ * Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
*/
vector<bool> used;
/**
- * Same as for @p{LineData::used}.
+ * Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
*/
vector<bool> user_flags;
* called with the prepro flag @p{DEBUG}
* set. The function should be called from
* the functions of the higher
- * @p{TriangulationLevel} classes.
+ * @ref{TriangulationLevel} classes.
*/
void monitor_memory (const unsigned int true_dimension) const;
};
*
* @author Wolfgang Bangerth, 1998
*/
-class Line {
+class Line
+{
public:
/**
* Construct a line with end point
inline // wahrlich inline hier!
-Line::Line (const int i0, const int i1) {
+Line::Line (const int i0, const int i1)
+{
end_points[0] = i0;
end_points[1] = i1;
};
+
inline
-int Line::vertex (const int i) const {
+int Line::vertex (const int i) const
+{
Assert ((i==0) || (i==1),
ExcRange(i));
return end_points[i];
};
+
inline
-void Line::set_vertex (const int i, const int index) {
+void Line::set_vertex (const int i, const int index)
+{
Assert ((i==0) || (i==1),
ExcRange(i));
end_points[i] = index;
*
* @author Wolfgang Bangerth, 1998
*/
-class Quad {
+class Quad
+{
public:
/**
inline
-Quad::Quad (const int i0, const int i1, const int i2, const int i3) {
+Quad::Quad (const int i0, const int i1, const int i2, const int i3)
+{
lines[0] = i0;
lines[1] = i1;
lines[2] = i2;
};
+
inline
-int Quad::line (const int i) const {
+int Quad::line (const int i) const
+{
Assert ((i>=0) && (i<4),
ExcRange(i));
return lines[i];
};
+
inline
-void Quad::set_line (const int i, const int index) {
+void Quad::set_line (const int i, const int index)
+{
Assert ((i>=0) && (i<4),
ExcRange(i));
lines[i] = index;
* result in a strange kind of behaviour, though every reasonable
* operating system should disallow access through that pointer.
* The reason we do not check for the null pointer in the
- * constructor which gets passed the @p{DoFHandler} pointer is that
+ * constructor which gets passed the @ref{DoFHandler} pointer is that
* if we did we could not make dof iterators member of other classes
* (like in the @p{FEValues} class) if we did not know about the
- * @p{DoFHandler} object to be used upon construction of that object.
+ * @ref{DoFHandler} object to be used upon construction of that object.
* Through the way this class is implemented here, we allow the
* creation of a kind of virgin object which only gets useful if
* assigned to from another object before first usage.
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
MGDoFObjectAccessor (Triangulation<dim> *tria,
const int level,
/**
* Constructor. The @p{local_data}
* argument is assumed to be a pointer
- * to a @p{DoFHandler<dim>} object.
+ * to a @ref{DoFHandler} object.
*/
MGDoFObjectAccessor (Triangulation<dim> *tria,
const int level,
* distribute the degrees of freedoms
* needed for the given finite element
* according to the given distribution
- * method. We first call the @p{DoFHandler}'s
+ * method. We first call the @ref{DoFHandler}'s
* function and then distribute the
* levelwise numbers.
*
/**
* Space to store the DoF numbers for the
* different levels. Unlike the @p{levels}
- * object in the @p{DoFHandler}, these are
+ * object in the @ref{DoFHandler}, these are
* not global numbers but rather are
* numbers which start from zero on each
* level.
* This is a collection of functions operating on, and manipulating
* the numbers of degrees of freedom in a multilevel triangulation. It
* is similar in purpose and function to the @p{DoFTools} class, but
- * operates on @p{MGDoFHandler} objects instead of @p{DoFHandler}
+ * operates on @p{MGDoFHandler} objects instead of @ref{DoFHandler}
* objects. See there and the documentation of the member functions
* for more information.
*
* Encapsulated Postscript supports Q1-Elements only.
*
* It allows the user to attach a degree of freedom handler object
- * (@p{DoFHandler}) which also gives access to the geometry data of the
+ * (@ref{DoFHandler}) which also gives access to the geometry data of the
* underlying triangulation and to add data vectors of which the values
* are to be written.
*
/**
* This is an abstract class which provides the functionality to generate
* patches for output by base classes from data vectors on a grid. It alloes
- * to store a pointer to a @p{DoFHandler} object and one or more pointers to
+ * to store a pointer to a @ref{DoFHandler} object and one or more pointers to
* node and cell data denoting functions on the grid which shall later
* be written in any of the implemented data formats.
*
* @sect3{User visible interface}
*
* The user visible interface of this class consists of functions which allow
- * a user to make a @p{DoFHandler} object known to this class and to add data
+ * a user to make a @ref{DoFHandler} object known to this class and to add data
* vectors which will later be written to a file in some format. Instead of
* pondering about the different functions, an example is probably the best
* way:
* @end{verbatim}
*
* @p{attach_dof_handler} tells this class that all future operations are to take
- * place with the @p{DoFHandler} object and the triangulation it lives on. We then
+ * place with the @ref{DoFHandler} object and the triangulation it lives on. We then
* add the solution vector and the error estimator; note that they have different
* dimensions, because the solution is a nodal vector, here consisting of two
* components ("x-displacement" and "y-displacement") while the error estimator
* to give a name to each component of the vector, which is done through an object
* of type @p{vector<string>} as second argument; if only one component is in the
* vector, for example if we are adding cell data as in the second case, or if
- * the finite element used by the @p{DoFHandler} has only one component, then you
+ * the finite element used by the @ref{DoFHandler} has only one component, then you
* can use the second @p{add_data_vector} function which takes a @p{string} instead
* of the @p{vector<string>}.
*
* to a file and may want to clear this object as soon as possible to reduce
* memory requirements.
*
- * Please note, that in the example above, an object of type @p{DataOut} was
+ * Please note, that in the example above, an object of type @ref{DataOut} was
* used, i.e. an object of a derived class. This is necessary since this
* class does not provide means to actually generate the patches, only aids to
* store and access data.
*
- * Note that the base class of this class, @p{DataOutInterface} offers several
+ * Note that the base class of this class, @ref{DataOutInterface} offers several
* functions to ease programming with run-time determinable output formats
* (i.e. you need not use a fixed format by calling @p{write_xxx} in the above
* example, but you can select it by a run-time parameter without having
* output of a new set of vectors
* without supplying the DoF
* handler again. Therefore, the
- * @p{DataOut} object can be used
+ * @ref{DataOut} object can be used
* in an algebraic context. Note
* that besides the data vectors
* also the patches already
/**
* This class is an actual implementation of the functionality proposed by
- * the @p{DataOut_DoFData} class. It offers a function @p{build_patches} that
+ * the @ref{DataOut_DoFData} class. It offers a function @p{build_patches} that
* generates the patches to be written in some graphics format from the data
* stored in the base class. Most of the interface and an example of its
* use is described in the documentation of the base class.
*
* @sect3{User interface information}
*
- * The base classes of this class, @p{DataOutBase}, @p{DataOutInterface} and
- * @p{DataOut_DoFData} offer several interfaces of their own. Refer to the
- * @p{DataOutBase} class's documentation for a discussion of the different
- * output formats presently supported, @p{DataOutInterface} for ways of
+ * The base classes of this class, @ref{DataOutBase}, @ref{DataOutInterface} and
+ * @ref{DataOut_DoFData} offer several interfaces of their own. Refer to the
+ * @ref{DataOutBase} class's documentation for a discussion of the different
+ * output formats presently supported, @ref{DataOutInterface} for ways of
* selecting which format to use upon output at run-time and without
* the need to adapt your program when new formats become available, as
- * well as for flags to determine aspects of output. The @p{DataOut_DoFData}
+ * well as for flags to determine aspects of output. The @ref{DataOut_DoFData}
* class's documentation has an example of using nodal data to generate
* output.
*
* space-time output file, or for example to connect the results of
* solutions of a parameter dependent equation for several parameter
* value together into one. The interface is mostly modelled after the
- * @p{DataOut} class.
+ * @ref{DataOut} class.
*
* We will explain the concept for a time dependent problem, but
* instead of the time any parameter can be substituted. In our
* is named @p{solution} and that a vector @p{error} is computed which
* contains an error indicator for each spatial cell.
*
- * Note that unlike for the @p{DataOut} class it is necessary to first
+ * Note that unlike for the @ref{DataOut} class it is necessary to first
* declare data vectors and the names of the components before first
* use. This is because on all time levels the same data should be
* present to produce reasonable time-space output. The output is
*
* This version may be called if the
* finite element presently used by the
- * @p{DoFHandler} (and previously attached
+ * @ref{DoFHandler} (and previously attached
* to this object) has only one component
* and therefore only one name needs to
* be given.
*
* This version must be called if the
* finite element presently used by the
- * @p{DoFHandler} (and previously attached
+ * @ref{DoFHandler} (and previously attached
* to this object) has more than one
* component and therefore more than one
* name needs to be given. However, you
*
* This version may be called if the
* finite element presently used by the
- * @p{DoFHandler} (and previously attached
+ * @ref{DoFHandler} (and previously attached
* to this object) has only one component
* and therefore only one name needs to
* be given.
*
* This version must be called if the
* finite element presently used by the
- * @p{DoFHandler} (and previously attached
+ * @ref{DoFHandler} (and previously attached
* to this object) has more than one
* component and therefore more than one
* name needs to be given. However, you
* Actually build the patches for output
* by the base classes from the data
* stored in the data vectors and using
- * the previously attached @p{DoFHandler}
+ * the previously attached @ref{DoFHandler}
* object.
*
* By @p{n_subdivisions} you can decide
* This is the function through
* which derived classes propagate
* preprocessed data in the form of
- * @p{Patch} structures (declared in
- * the base class @p{DataOutBase}) to
+ * @ref{Patch} structures (declared in
+ * the base class @ref{DataOutBase}) to
* the actual output function.
*/
virtual const vector<DataOutBase::Patch<dim+1> > & get_patches () const;
* the values of the finite element field at the centers of the cells
* are taken. It might therefore only be useful to use this class for
* discontinuous, piecewise constant elements (i.e. using the
- * @p{FEDG_Q0} class), since all other finite elements can approximate
+ * @ref{FEDG_Q0} class), since all other finite elements can approximate
* gradients themselves.
*
*
typedef double ProjectedDerivative;
/**
- * Given an @p{FEValues} object
+ * Given an @ref{FEValues} object
* initialized to a cell, and a
* solution vector, extract the
* desired derivative at the
typedef Tensor<1,dim> ProjectedDerivative;
/**
- * Given an @p{FEValues} object
+ * Given an @ref{FEValues} object
* initialized to a cell, and a
* solution vector, extract the
* desired derivative at the
#include <iomanip>
#include <fstream>
+
+
/**
* Print intermediate solutions in solvers.
* This is derived from a solver class provided as template argument.
* It implements the @p{print_vector} function of the solver using a
- * @ref DoFHandler. This way, the intermediate vectors can be viewed as
+ * @ref{DoFHandler}. This way, the intermediate vectors can be viewed as
* finite element functions.
*
* This class may produce enormous amounts of data!
*
* The renumbering algorithms need quite a lot of memory, since they have
* to store for each dof with which other dofs it couples. This is done
- * using a @p{SparsityPattern} object used to store the sparsity pattern of
+ * using a @ref{SparsityPattern} object used to store the sparsity pattern of
* matrices. It
* is not useful for the user to do anything between distributing the dofs
- * and renumbering, i.e. the calls to @p{DoFHandler::distribute_dofs} and
- * @p{DoFHandler::renumber_dofs} should follow each other immediately. If
+ * and renumbering, i.e. the calls to @ref{DoFHandler}@p{::distribute_dofs} and
+ * @ref{DoFHandler}@p{::renumber_dofs} should follow each other immediately. If
* you try to create a sparsity pattern or anything else in between, these
* will be invalid afterwards.
*
*
* @sect2{Component-wise numbering}
*
- * For finite elements composed of several base elements using the @p{FESystem}
+ * For finite elements composed of several base elements using the @ref{FESystem}
* class, or for elements which provide several components themselves, it
* may be of interest to sort the DoF indices by component. This will then
* bring out the block matrix structure, since otherwise the degrees of freedom
* the conormal derivative $a\frac{du}{dn} = g$.
*
* The error estimator returns a vector of estimated errors per cell which
- * can be used to feed the @p{Triangulation<dim>::refine_*} functions. This
+ * can be used to feed the @ref{Triangulation}@p{<dim>::refine_*} functions. This
* vector contains elements of data type @p{float}, rather than @p{double},
* since accuracy is not so important here, and since this can save rather
* a lot of memory, when using many cells.
* is considered, but may lead to wrong results. You may scale the vector
* appropriately afterwards.
*
- * To perform the integration, use is made of the @p{FEFaceValues} and
- * @p{FESubfaceValues} classes. The integration is performed by looping
+ * To perform the integration, use is made of the @ref{FEFaceValues} and
+ * @ref{FESubfaceValues} classes. The integration is performed by looping
* over all cells and integrating over faces that are not yet treated.
* This way we avoid integration on faces twice, once for each time we
* visit one of the adjacent cells. In a second loop over all cells, we
* square of the jumps) of each cell and take the square root.
*
* The integration is done using a quadrature formula on the face.
- * For linear trial functions (@p{FELinear}), the @p{Gauss2} or even the
- * @p{Midpoint} rule will suffice. For higher order elements, it is
+ * For linear trial functions (@ref{FEQ1}), the @ref{QGauss2} or even the
+ * @ref{QMidpoint} rule will suffice. For higher order elements, it is
* necessary to utilize higher order quadrature formulae as well.
*
* We store the contribution of each face in a @p{map}, as provided by the
*
* The integration along faces with hanging nodes is quite tricky, since one
* of the elements has to be shifted one level up or down. See the
- * documentation for the @p{FESubfaceValues} class for more information about
+ * documentation for the @ref{FESubFaceValues} class for more information about
* technical issues regarding this topic.
*
* In praxi, since we integrate over each face only once, we do this when we
* components you want to
* evaluate, in case the finite
* element used by the
- * @p{DoFHandler} object is
+ * @ref{DoFHandler} object is
* vector-valued. You then have
* to set those entries to true
* in the bit-vector
*
* All functions take a sparse matrix object to hold the matrix to be
* created. The functions assume that the matrix is initialized with a
- * sparsity pattern (@p{SparsityPattern}) corresponding to the given degree
+ * sparsity pattern (@ref{SparsityPattern}) corresponding to the given degree
* of freedom handler, i.e. the sparsity structure is already as needed.
- * You can do this by calling the @p{DoFHandler<dim>::make_sparsity_pattern}
+ * You can do this by calling the @ref{DoFHandler}@p{<dim>::make_sparsity_pattern}
* function.
*
* Furthermore it is assumed that no relevant data is in the matrix. All
* @item @p{create_mass_matrix}: create the matrix with entries
* $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$. Here, the $\phi_i$
* are the basis functions of the finite element space given.
- * This function uses the @p{MassMatrix} class.
+ * This function uses the @ref{MassMatrix} class.
*
* Two ways to create this matrix are offered. The first one uses
- * numerical quadrature and the @p{MassMatrix} class. In this case,
+ * numerical quadrature and the @ref{MassMatrix} class. In this case,
* a coefficient may be given to evaluate
* $m_{ij} = \int_\Omega a(x) \phi_i(x) \phi_j(x) dx$ instead.
* This way of setting up the mass matrix is quite general, but has
- * some drawbacks, see the documentation of the @p{MassMatrix} class.
+ * some drawbacks, see the documentation of the @ref{MassMatrix} class.
*
* The other way uses exact integration, as offered by the finite
* element class used. This way you can avoid quadrature errors and
* composed of several subelements. In this case, using the
* quadrature free way (without coefficient) results in a matrix
* which does not couple the subelements, as described in the
- * @p{FESystem::get_local_mass_matrix} documentation, while the
+ * @ref{FESystem}@p{::get_local_mass_matrix} documentation, while the
* way using quadrature sets up the full matrix, i.e. with the
* cross coupling of shape functions belonging to different subelements.
*
* If the finite element for which the mass matrix is to be built
* has more than one component, the resulting matrix will not couple
* the different components. It will furthermore accept a single
- * coefficient through the @p{Function} parameter for all
+ * coefficient through the @ref{Function} parameter for all
* components. If you want different coefficients for the different
* parameters, you need to pass a function object representing the
* respective number of components.
*
* @item @p{create_laplace_matrix}: there are two versions of this; the
- * one which takes the @p{Function<dim>} object creates
+ * one which takes the @ref{Function} object creates
* $a_{ij} = \int_\Omega a(x) \nabla\phi_i(x) \nabla\phi_j(x) dx$,
* $a$ being the given function, while the other one assumes that
* $a=1$ which enables some optimizations. In fact the two versions
* are in one function, the coefficient being given as a defaulted
* argument, which is a pointer to a function and defaults to zero.
- * This function uses the @p{LaplaceMatrix} class.
+ * This function uses the @ref{LaplaceMatrix} class.
*
* If the finite element in use presently has more than only one
* component, this function may not be overly useful and presently
* several matrices and could then condense afterwards only once,
* instead of for every matrix. To actually do computations with these
* matrices, you have to condense the matrix using the
- * @p{ConstraintMatrix::condense} function; you also have to condense the
+ * @ref{ConstraintMatrix}@p{::condense} function; you also have to condense the
* right hand side accordingly and distribute the solution afterwards.
*
* In all cases, the elements of the matrix to be assembled are simply
* This function needs to get passed a matrix object to hold the resulting sparse
* matrix. This object is supposed to be initialized with a suitable sparsity
* pattern, which can be created using the
- * @p{DoFHandler<>::make_boundary_sparsity_pattern} function.
+ * @ref{DoFHandler}@p{::make_boundary_sparsity_pattern} function.
*
* The object describing the exact form of the boundary is obtained from the
* triangulation object.
* building the right hand side vector. (The @p{create_mass_matrix} function
* which does not use quadrature does not offer a version to evaluate a right
* hand side also, since this needs quadrature anyway. Take look at the
- * @p{VectorTools} class to find a function to set up a right hand side vector
+ * @ref{VectorTools} class to find a function to set up a right hand side vector
* only.)
*
* Creation of the right hand side
*
*
* All functions in this collection use the finite elemen given to the
- * @p{DoFHandler} object the last time that the degrees of freedom were
+ * @ref{DoFHandler} object the last time that the degrees of freedom were
* distributed on the triangulation.
*
* @author Wolfgang Bangerth, 1998
*
* The matrix is assumed to already be
* initialized with a suiting sparsity
- * pattern (the @p{DoFHandler} provides an
+ * pattern (the @ref{DoFHandler} provides an
* appropriate function).
*
* See the general doc of this class
* into a system of equations. To actually do this you have to specify
* a list of degree of freedom indices along with the values these degrees of
* freedom shall assume. To see how to get such a list, see the discussion
- * of the @p{VectorTools::interpolate_boundary_values} function.
+ * of the @ref{VectorTools}@p{::interpolate_boundary_values} function.
*
* The inclusion into the assemblage process is as follows: when the matrix and
* vectors are set up, a list of nodes subject to dirichlet bc is made and
/**
- * Equation class to be passed to the @p{Assembler} if you want to make up the
+ * Equation class to be passed to the @ref{Assembler} if you want to make up the
* mass matrix for your problem. The mass matrix is the matrix with
* $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$.
*
* You will usually want to use this object only if you have coefficients
* which vary over each cell. If you have coefficients which are constant
* on each cell or even on the whole domain, you can get the local mass
- * matrix easier by calling the @p{FiniteElement::get_local_mass_matrix} and
+ * matrix easier by calling the @ref{FiniteElement}@p{::get_local_mass_matrix} and
* then scaling this one on each cell. This has the additional benefit that
* the mass matrix is evaluated exactly, i.e. not using a quadrature formula
* and is normally much faster since it can be precomputed and needs only
* The useful use of this object is therefore probable one of the following
* cases:
* @begin{itemize}
- * @item Mass lumping: use an @p{Assembler} object and a special quadrature
+ * @item Mass lumping: use an @ref{Assembler} object and a special quadrature
* formula to voluntarily evaluate the mass matrix incorrect. For example
* by using the trapezoidal formula, the mass matrix will become a
* diagonal (at least if no hanging nodes are considered). However, there
* occurs in the discretization of the heat and the wave equation, amoung
* others), once could conceive an equation object in which the @p{assemble}
* functions do nothing but sum up the contributions delivered by the
- * @p{assemble} functions of the @p{MassMatrix} and @p{LaplaceMatrix} classes.
+ * @p{assemble} functions of the @ref{MassMatrix} and @ref{LaplaceMatrix} classes.
* Since numerical quadrature is necessary here anyway, this way is
* justifyable to quickly try something out. In the further process it
* may be useful to replace this behaviour by more sophisticated methods,
/**
- * Equation class to be passed to the @p{Assembler} if you want to make up the
+ * Equation class to be passed to the @ref{Assembler} if you want to make up the
* laplace matrix for your problem. The laplace matrix is the matrix with
* $a_{ij} = \int_\Omega \nabla\phi_i(x) \cdot \nabla\phi_j(x) dx$.
*
* solution vector on the current (original) grid.
* Each entry of this vector belongs to one of the
* DoFs of the discretisation. If we now refine the grid then the calling of
- * @p{DoFHandler::distribute_dofs(...)} will change at least some of the
+ * @ref{DoFHandler}@p{::distribute_dofs(...)} will change at least some of the
* DoF indices. Hence we need to store the DoF indices of all active cells
* before the refinement. The @p{user_pointer} of each active cell
* is used to point to the vector of these DoF indices of that cell, all other
* arbitrary many discrete functions (solution vectors) on the original grid.
*
* @item Solution transfer while coarsening and refinement. After
- * calling @p{Triangulation::prepare_coarsening_and_refinement} the
+ * calling @ref{Triangulation}@p{::prepare_coarsening_and_refinement} the
* coarsen flags of either all or none of the children of a
* (father-)cell are set. While coarsening
- * (@p{Triangulation::execute_coarsening_and_refinement})
- * the cells that are not needed any more will be deleted from the @p{Triangulation}.
+ * (@ref{Triangulation}@p{::execute_coarsening_and_refinement})
+ * the cells that are not needed any more will be deleted from the @ref{Triangulation}.
*
* For the interpolation from the (to be coarsenend) children to their father
* the children cells are needed. Hence this interpolation
public:
/**
- * Constructor, takes the current @p{DoFHandler}
+ * Constructor, takes the current @ref{DoFHandler}
* as argument.
*/
SolutionTransfer(const DoFHandler<dim> &dof);
*
* Calling this function is
* allowed only if first
- * @p{Triangulation::prepare_coarsening_and_refinement},
+ * @ref{Triangulation}@p{::prepare_coarsening_and_refinement},
* second
* @p{SolutionTransfer::prepare_for_coarsening_and_refinement},
* an then third
- * @p{Triangulation::execute_coarsening_and_refinement}
+ * @ref{Triangulation}@p{::execute_coarsening_and_refinement}
* are called before. Multiple
* calling of this function is
* NOT allowed. Interpolating
* timestep_manager.run_sweep (sweep);
* };
* @end{verbatim}
- * Here, @p{timestep_manager} is an object of type @p{TimeDependent_Wave}, which
- * is a class derived from @p{TimeDependent}. @p{start_sweep},
+ * Here, @p{timestep_manager} is an object of type @ref{TimeDependent_Wave}, which
+ * is a class derived from @ref{TimeDependent}. @p{start_sweep},
* @p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess} and @p{end_sweep}
* are functions inherited from this class. They all do a loop over all
* timesteps within this object and call the respective function on each of
* invoked (@p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess},
* @p{refine_grids} and @p{write_statistics} all have this form, where the
* latter two give functions of the derived timestep class, rather than
- * from the base class). The function @p{TimeStepBase::init_for_primal_problem}
+ * from the base class). The function @ref{TimeStepBase}@p{::init_for_primal_problem}
* and the respective ones for the other operations defined by that class
* are only used to store the type of operation which the loop presently
* performed will do.
* TimeDependent::TimeSteppingData (0,1),
* TimeDependent::forward);
* @end{verbatim}
- * @p{TimeStepBase_Wave<dim>::refine_grid} is a function taking an argument, unlike
+ * @ref{TimeStepBase_Wave}@p{::refine_grid} is a function taking an argument, unlike
* all the other functions used above within the loops. However, in this special
* case the parameter was the same for all timesteps and known before the loop
* was started, so we fixed it and made a function object which to the outside
*
* Note that by giving an object
* to this function, the
- * @p{TimeDependent} object assumes
+ * @ref{TimeDependent} object assumes
* ownership of the object; it will
* therefore also take care of
* deletion of the objects its manages.
* Solve the primal problem; uses the
* functions @p{init_for_primal_problem}
* and @p{solve_primal_problem} of the
- * @p{TimeStepBase} class through the
+ * @ref{TimeStepBase} class through the
* @p{do_loop} function of this class.
*
* Look ahead and look back are
* Solve the dual problem; uses the
* functions @p{init_for_dual_problem}
* and @p{solve_dual_problem} of the
- * @p{TimeStepBase} class through the
+ * @ref{TimeStepBase} class through the
* @p{do_loop} function of this class.
*
* Look ahead and look back are
* Do a postprocessing round; uses the
* functions @p{init_for_postprocessing}
* and @p{postprocess} of the
- * @p{TimeStepBase} class through the
+ * @ref{TimeStepBase} class through the
* @p{do_loop} function of this class.
*
* Look ahead and look back are
*
* Note also, that the given class from which
* the two functions are taken needs not
- * necessarily be @p{TimeStepBase}, but it
+ * necessarily be @ref{TimeStepBase}, but it
* could also be a derived class, that is
- * @p{static_cast}able from a @p{TimeStepBase}.
+ * @p{static_cast}able from a @ref{TimeStepBase}.
* The function may be a virtual function
* (even a pure one) of that class, which
* should help if the actual class where it
* is implemented is one which is derived
* through virtual base classes and thus
* unreachable by @p{static_cast} from the
- * @p{TimeStepBase} class.
+ * @ref{TimeStepBase} class.
*
* Instead of using the above form, you can
* equally well use
};
+
/**
- * Specialisation of @p{TimeStepBase} which addresses some aspects of grid handling.
+ * Specialisation of @ref{TimeStepBase} which addresses some aspects of grid handling.
* In particular, this class is thought to make handling of grids available that
* are adaptively refined on each time step separately or with a loose coupling
* between time steps. It also takes care of deleting and rebuilding grids when
};
+
/**
- * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should
+ * This structure is used to tell the @ref{TimeStepBase_Tria} class how grids should
* be handled. It has flags defining the moments where grids shall be
* re-made and when they may be deleted. Also, one variable states whether
* grids should be kept in memory or should be deleted between to uses to
};
+
/**
- * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should
+ * This structure is used to tell the @ref{TimeStepBase_Tria} class how grids should
* be refined. Before we explain all the different variables, fist some terminology:
* @begin{itemize}
* @item Correction: after having flagged some cells of the triangulation for
};
+
/**
* Structure given to the actual refinement function, telling it which
* thresholds to take for coarsening and refinement. The actual refinement
* given function onto the finite element space restricted to the boundary
* of the domain, then taking this information and using it to eliminate
* the boundary nodes from the mass matrix of the whole domain, using the
- * @p{MatrixTools::apply_boundary_values} function. The projection of the
+ * @ref{MatrixTools}@p{::apply_boundary_values} function. The projection of the
* trace of the function to the boundary is done with the
- * @p{VectorTools::project_boundary_values} (see below) function, which is
+ * @ref{VectorTools}@p{::project_boundary_values} (see below) function, which is
* called with a map of boundary functions in which all boundary indicators
- * from zero to 254 (255 is used for other purposes, see the @p{Triangulation}
+ * from zero to 254 (255 is used for other purposes, see the @ref{Triangulation}
* class documentation) point to the function to be projected. The projection
* to the boundary takes place using a second quadrature formula on the
* boundary given to the @p{project} function. The first quadrature formula is
* @item Creation of right hand side vectors:
* The @p{create_right_hand_side} function computes the vector
* $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the
- * @p{MatrixCreator::create_*} functions which take a right hand side do,
+ * @ref{MatrixCreator}@p{::create_*} functions which take a right hand side do,
* but without assembling a matrix.
*
* @item Interpolation of boundary values:
- * The @p{MatrixTools::apply_boundary_values} function takes a list
+ * The @ref{MatrixTools}@p{::apply_boundary_values} function takes a list
* of boundary nodes and their values. You can get such a list by interpolation
* of a boundary function using the @p{interpolate_boundary_values} function.
* To use it, you have to
* Within this function, boundary values are interpolated, i.e. a node is given
* the point value of the boundary function. In some cases, it may be necessary
* to use the L2-projection of the boundary function or any other method. For
- * this purpose to the @p{VectorTools::project_boundary_values}
+ * this purpose to the @ref{VectorTools}@p{::project_boundary_values}
* function below.
*
* You should be aware that the boundary function may be evaluated at nodes
* The projection takes place on all boundary parts with boundary indicators
* listed in the map of boundary functions. These boundary parts may or may
* not be contiguous. For these boundary parts, the mass matrix is assembled
- * using the @p{MatrixTools::create_boundary_mass_matrix} function, as well as
+ * using the @ref{MatrixTools}@p{::create_boundary_mass_matrix} function, as well as
* the appropriate right hand side. Then the resulting system of equations is
* solved using a simple CG method (without preconditioning), which is in most
* cases sufficient for the present purpose.
* is the same as a @p{cell_iterator} takes when started with @p{begin_active} and
* promoted with the @p{++} operator.
*
- * You can use the @p{distribute_cell_to_dof_vector} function of the @p{DoFHandler}
+ * You can use the @p{distribute_cell_to_dof_vector} function of the @ref{DoFHandler}
* class to convert cell based data to a data vector with values on the degrees
- * of freedom, which can then be attached to a @p{DataOut} object to be printed.
+ * of freedom, which can then be attached to a @ref{DataOut} object to be printed.
*
* Presently, there is the possibility to compute the following values from the
* difference, on each cell: @p{mean}, @p{L1_norm}, @p{L2_norm}, @p{Linfty_norm},
* The $H_1$ seminorm is the $L_2$ norm of the gradient of the difference. The
* full $H_1$ norm is the sum of the seminorm and the $L_2$ norm.
*
- * To get the @em{global} $L_1$ error, you have to sum up the entries in
- * @p{difference}, e.g. using @p{Vector<double>::l1_norm} function.
- * For the global $L_2$ difference, you have to sum up the squares of the
- * entries and take the root of the sum, e.g. using @p{Vector<double>::l2_norm}.
- * These two operations represent the
- * $l_1$ and $l_2$ norms of the vectors, but you need not take the absolute
- * value of each entry, since the cellwise norms are already positive.
+ * To get the @em{global} $L_1$ error, you have to sum up the
+ * entries in @p{difference}, e.g. using
+ * @ref{Vector}@p{<double>::l1_norm} function. For the global $L_2$
+ * difference, you have to sum up the squares of the entries and
+ * take the root of the sum, e.g. using
+ * @ref{Vector}@p{<double>::l2_norm}. These two operations
+ * represent the $l_1$ and $l_2$ norms of the vectors, but you need
+ * not take the absolute value of each entry, since the cellwise
+ * norms are already positive.
*
* To get the global mean difference, simply sum up the elements as above.
* To get the $L_\infty$ norm, take the maximum of the vector elements, e.g.
- * using the @p{Vector<double>::linfty_norm} function.
+ * using the @ref{Vector}@p{<double>::linfty_norm} function.
*
* For the global $H_1$ norm and seminorm, the same rule applies as for the
* $L_2$ norm: compute the $l_2$ norm of the cell error vector.
* @end{itemize}
*
- * All functions use the finite element given to the @p{DoFHandler} object the last
+ * All functions use the finite element given to the @ref{DoFHandler} object the last
* time that the degrees of freedom were distributed over the triangulation. Also,
* if access to an object describing the exact form of the boundary is needed, the
* pointer stored within the triangulation object is accessed.
* present grid. To this end, the mass
* matrix is assembled exactly using the
* @p{create_mass_matrix} function in the
- * @p{MatrixTools} collection. This function
+ * @ref{MatrixTools} collection. This function
* uses the @p{get_local_mass_matrix}
* function of the finite element; however,
* this function is not supported by all
projects / dealii.git / commitdiff