* From a usage point of view, ghosted vectors are typically used for
* data output, postprocessing, error estimation, input in
* integration. This is because in these operations, one typically
- * needs access not only to @ref GlossLocallyOwnedDofs "locally owned dofs"
- * but also to @ref GlossLocallyActiveDofs "locally active dofs"
- * and sometimes to @ref GlossLocallyRelevantDofs "locally relevant dofs",
+ * needs access not only to @ref GlossLocallyOwnedDof "locally owned dofs"
+ * but also to @ref GlossLocallyActiveDof "locally active dofs"
+ * and sometimes to @ref GlossLocallyRelevantDof "locally relevant dofs",
* and their values may not be stored in non-ghosted vectors on the
* processor that needs them. The operations listed above also only
* require read-only access to vectors, and ghosted vectors are therefore
* The value of this variable is written into the output file according to
* the instructions provided in
* http://www.visitusers.org/index.php?title=Time_and_Cycle_in_VTK_files
- * unless it is at its default value of std::numeric_limits<unsigned
- * int>::min().
+ * unless it is at its default value of
+ * std::numeric_limits<unsigned int>::min().
*/
unsigned int cycle;
/**
- * Similar to previous apply_transformation. It computes $T*DF^{t}$ @relates
- * DerivativeForm
+ * Similar to previous apply_transformation. It computes $T*DF^{t}$.
+ * @relates DerivativeForm
* @author Sebastian Pauletti, 2011
*/
//rank=2
#ifndef __deal2__exceptions_h
#define __deal2__exceptions_h
-/**
- * @file Here, the deal.II exception handling is located.
- */
-
#include <deal.II/base/config.h>
#include <exception>
* Constructor
* @param interval_endpoints The left and right end points of the
* (uniformly subdivided) intervals in each of the coordinate directions.
- * @param n_subdivisions The number of subintervals of the subintervals in
+ * @param n_subintervals The number of subintervals in
* each coordinate direction. A value of one for a coordinate means that
* the interval is considered as one subinterval consisting of the entire
* range. A value of two means that there are two subintervals each with
* template parameters: dim (the topological dimension of the object) and
* spacedim (the dimension of the embedding Euclidean space). Since in all
* deal.II classes, by default spacedim is equal to dimension, the above
- * string is usually contracted to <dim>, instead of <dim,spacedim>. This
+ * string is usually contracted to "<dim>", instead of "<dim,spacedim>". This
* function returns a string containing "dim" if dim is equal to spacedim,
* otherwhise it returns "dim,spacedim".
*/
/**
* A structure whose explicit specializations contain typedefs to the
* relevant p4est_* and p8est_* types. Using this structure, for example
- * by saying <code>types@<dim@>::connectivity</code> we can write code in
+ * by saying <tt>types<dim>::connectivity</tt> we can write code in
* a dimension independent way, either referring to p4est_connectivity_t
* or p8est_connectivity_t, depending on template argument.
*/
* ordering than with another one, then this means that the actual solver is
* actually several times faster.
*
- * <table> <tr> <td> @image html "reorder_sparsity_step_31_original.png" </td>
- * <td> @image html "reorder_sparsity_step_31_random.png" </td> <td> @image
- * html "reorder_sparsity_step_31_deal_cmk.png" </td> </tr> <tr> <td>
+ * <table> <tr>
+ * <td> @image html "reorder_sparsity_step_31_original.png" </td>
+ * <td> @image html "reorder_sparsity_step_31_random.png" </td>
+ * <td> @image html "reorder_sparsity_step_31_deal_cmk.png" </td>
+ * </tr> <tr> <td>
* Enumeration as produced by deal.II's DoFHandler::distribute_dofs function
* and no further reordering apart from the component-wise one.
*
* With this renumbering, we needed an average of 57.3 iterations for the
* testcase outlined above, and a runtime of 6min10s. </td> </td> </tr>
*
- * <tr> <td> @image html "reorder_sparsity_step_31_boost_cmk.png" </td> <td>
- * @image html "reorder_sparsity_step_31_boost_king.png" </td> <td> @image
- * html "reorder_sparsity_step_31_boost_md.png" </td> </tr> <tr> <td> Cuthill-
+ * <tr> <td> @image html "reorder_sparsity_step_31_boost_cmk.png" </td>
+ * <td> @image html "reorder_sparsity_step_31_boost_king.png" </td>
+ * <td> @image html "reorder_sparsity_step_31_boost_md.png" </td>
+ * </tr> <tr> <td> Cuthill-
* McKee enumeration as produced by calling the BOOST implementation of the
* algorithm provided by DoFRenumbering::boost::Cuthill_McKee after
* DoFHandler::distribute_dofs.
* C++, the compiler can not determine the type of <code>DH</code> from the
* function call. You need to specify it as an explicit template argument
* following the function name.
- * @param patch[in] A collection of cells within an object of type DH
+ * @param patch A collection of cells within an object of type DH
* @return The number of degrees of freedom associated with the cells of
* this patch.
*
* C++, the compiler can not determine the type of <code>DH</code> from the
* function call. You need to specify it as an explicit template argument
* following the function name.
- * @param patch[in] A collection of cells within an object of type DH
+ * @param patch A collection of cells within an object of type DH
* @return A list of those global degrees of freedom located on the patch,
* as defined above.
*
const bool colorize=false);
/**
- * A parallelogram. The first corner point is the origin. The <tt>dim</tt>
+ * A parallelogram. The first corner point is the origin. The @p dim
* adjacent points are the ones given in the second argument and the fourth
* point will be the sum of these two vectors. Colorizing is done in the
* same way as in hyper_rectangle().
const bool colorize=false) DEAL_II_DEPRECATED;
/**
- * A parallelepiped. The first corner point is the origin. The <tt>dim</tt>
+ * A parallelepiped. The first corner point is the origin. The @p dim
* adjacent points are vectors describing the edges of the parallelepiped
* with respect to the origin. Additional points are sums of these dim
* vectors. Colorizing is done according to hyper_rectangle().
/**
* A subdivided parallelepiped. The first corner point is the origin. The
- * <tt>dim</tt> adjacent points are vectors describing the edges of the
+ * @p dim adjacent points are vectors describing the edges of the
* parallelepiped with respect to the origin. Additional points are sums of
* these dim vectors. The variable @p n_subdivisions designates the number
- * of subdivisions in each of the <tt>dim</tt> directions. Colorizing is
+ * of subdivisions in each of the @p dim directions. Colorizing is
* done according to hyper_rectangle().
*
* @note The triangulation needs to be void upon calling this function.
/**
* A subdivided parallelepiped, ie. the same as above, but where the number
- * of subdivisions in each of the <tt>dim</tt> directions may vary.
+ * of subdivisions in each of the @p dim directions may vary.
* Colorizing is done according to hyper_rectangle().
*
* @note The triangulation needs to be void upon calling this function.
/**
* Initialize the given triangulation with a hyperball, i.e. a circle or a
- * ball around <tt>center</tt> with given <tt>radius</tt>.
+ * ball around @p center with given @p radius.
*
* In order to avoid degenerate cells at the boundaries, the circle is
* triangulated by five cells, the ball by seven cells. The diameter of the
const double radius = 1.);
/**
- * This class produces a half hyper-ball around <tt>center</tt>, which
+ * This class produces a half hyper-ball around @p center, which
* contains four elements in 2d and 6 in 3d. The cut plane is perpendicular
* to the <i>x</i>-axis.
*
* direction to form 6 cells), 12 for the rhombic dodecahedron, and 96 (see
* below). These give rise to the following meshes upon one refinement:
*
- * @image html hypershell3d-6.png @image html hypershell3d-12.png
+ * @image html hypershell3d-6.png
+ * @image html hypershell3d-12.png
*
* Neither of these meshes is particularly good since one ends up with
* poorly shaped cells at the inner edge upon refinement. For example, this
* that the doubled radial lines on the cross section are artifacts of the
* visualization):
*
- * @image html hyper_shell_12_cut.png @image html hyper_shell_96_cut.png
+ * @image html hyper_shell_12_cut.png
+ * @image html hyper_shell_96_cut.png
*
* A different way to approach the problem with distorted cells is to attach
* appropriate manifold descriptions to the geometry created by this
/**
* Given an input triangulation @p in_tria, this function makes a new flat
* triangulation @p out_tria which contains a single level with all active
- * cells of the input triangulation. If spacedim1 and spacedim2 are
+ * cells of the input triangulation. If @p spacedim1 and @p spacedim2 are
* different, only the smallest spacedim components of the vertices are
* copied over. This is useful to create a Triangulation<2,3> out of a
* Triangulation<2,2>, or to project a Triangulation<2,3> into a
* Triangulation<2,2>, by neglecting the z components of the vertices.
*
* No internal checks are performed on the vertices, which are assumed to
- * make sense topologically in the target #spacedim2 dimensional space. If
+ * make sense topologically in the target @p spacedim2 dimensional space. If
* this is not the case, you will encounter problems when using the
* triangulation later on.
*
/**
* Read grid data from an msh file, either version 1 or version 2 of that
- * file format. The GMSH formats are documented at http://www.geuz.org/gmsh/
- * .
+ * file format. The GMSH formats are documented at http://www.geuz.org/gmsh/ .
*
* @note The input function of deal.II does not distinguish between newline
* and other whitespace. Therefore, deal.II will be able to read files in a
*
* @tparam Container A type that satisfies the requirements of a mesh
* container (see @ref GlossMeshAsAContainer).
- * @param cell[in] An iterator pointing to a cell of the mesh container.
- * @param active_neighbors[out] A list of active descendants of the given
+ * @param[in] cell An iterator pointing to a cell of the mesh container.
+ * @param[out] active_neighbors A list of active descendants of the given
* cell
*/
template <class Container>
* determine the type of <code>Container</code> from the function call. You
* need to specify it as an explicit template argument following the
* function name.
- * @param cell[in] An iterator pointing to a cell of the mesh container.
+ * @param[in] cell An iterator pointing to a cell of the mesh container.
* @return A list of active cells that form the patch around the given cell
*
* @note Patches are often used in defining error estimators that require
* between its vertices can be achieved via an orthogonal equality relation.
*
* Hereby, two vertices <tt>v_1</tt> and <tt>v_2</tt> are considered equal,
- * if $M\cdot v_1 + offset - v_2</code> is parallel to the unit vector in
+ * if $M\cdot v_1 + offset - v_2$ is parallel to the unit vector in
* unit direction @p direction. If the parameter @p matrix is a reference to
* a spacedim x spacedim matrix, $M$ is set to @p matrix, otherwise $M$ is
* the identity matrix.
* \subset R^{\text{chartdim}} \f] (the pull_back() function).
*
* The get_new_point() function of the ChartManifold class is implemented by
- * calling the pull_back() method for all #surrounding_points, computing their
+ * calling the pull_back() method for all <tt>surrounding_points</tt>, computing their
* weighted average in the chartdim Euclidean space, and calling the
* push_forward() method with the resulting point, i.e., \f[ p^{\text{new}} =
* F(\sum_i w_i F^{-1}(p_i)). \f]
* pull_back() methods. All other functions required by mappings will then be
* provided by this class.
*
- * The dimension arguments #chartdim, #dim and #spacedim must satisfy the
+ * The dimension arguments @p chartdim, @p dim and @p spacedim must satisfy the
* following relationships:
* @code
* dim <= spacedim
* chartdim <= spacedim
* @endcode
- * However, there is no a priori relationship between #dim and #chartdim. For
+ * However, there is no a priori relationship between @p dim and @p chartdim. For
* example, if you want to describe a mapping for an edge (a 1d object) in a
* 2d triangulation embedded in 3d space, you could do so by parameterizing it
* via a line
* @f[
* F: [0,1] \rightarrow {\mathbb R}^3
* @f]
- * in which case #chartdim is 1. On the other hand, there is no reason why one
+ * in which case @p chartdim is 1. On the other hand, there is no reason why one
* can't describe this as a mapping
* @f[
* F: {\mathbb R}^3 \rightarrow {\mathbb R}^3
* @f]
* in such a way that the line $[0,1]\times \{0\}\times \{0\}$ happens to be
- * mapped onto the edge in question. Here, #chartdim is 3. This may seem
+ * mapped onto the edge in question. Here, @p chartdim is 3. This may seem
* cumbersome but satisfies the requirements of an invertible function $F$
* just fine as long as it is possible to get from the edge to the pull-back
* space and then back again. Finally, given that we are dealing with a 2d
* triangulation in 3d, one will often have a mapping from, say, the 2d unit
* square or unit disk to the domain in 3d space, and the edge in question may
* simply be the mapped edge of the unit domain in 2d space. In this case,
- * #chartdim is 2.
+ * @p chartdim is 2.
*
* @ingroup manifold
*
public:
/**
* Explicit functions constructor. Takes a push_forward function of spacedim
- * components, and a pull_back function of chartdim components. See the
+ * components, and a pull_back function of @p chartdim components. See the
* documentation of the base class ChartManifold for the meaning of the
- * optional #periodicity argument.
+ * optional @p periodicity argument.
*
* The tolerance argument is used in debug mode to actually check that the
* two functions are one the inverse of the other.
/**
* Expressions constructor. Takes the expressions of the push_forward
* function of spacedim components, and of the pull_back function of
- * chartdim components. See the documentation of the base class
- * ChartManifold for the meaning of the optional #periodicity argument.
+ * @p chartdim components. See the documentation of the base class
+ * ChartManifold for the meaning of the optional @p periodicity argument.
*
* The strings should be the readable by the default constructor of the
* FunctionParser classes. You can specify custom variable expressions with
~FunctionManifold();
/**
- * Given a point in the chartdim coordinate system, uses the
- * push_forward_function to compute the push_forward of points in #chardim
- * space dimensions to #spacedim space dimensions.
+ * Given a point in the @p chartdim coordinate system, uses the
+ * push_forward_function to compute the push_forward of points in @p chartdim
+ * space dimensions to @p spacedim space dimensions.
*/
virtual Point<spacedim>
push_forward(const Point<chartdim> &chart_point) const;
/**
* Given a point in the spacedim coordinate system, uses the
- * pull_back_function to compute the pull_back of points in #spacedim space
- * dimensions to #chartdim space dimensions.
+ * pull_back_function to compute the pull_back of points in @p spacedim space
+ * dimensions to @p chartdim space dimensions.
*/
virtual Point<chartdim>
pull_back(const Point<spacedim> &space_point) const;
/**
* Check ownership of the smart pointers. Indicates whether this class is
* the owner of the objects pointed to by the previous two member variables.
- * This value is set in the constructor of the class. If #true, then the
+ * This value is set in the constructor of the class. If @p true, then the
* destructor will delete the function objects pointed to be the two
* pointers.
*/
/**
* Same as above, but store the flags to a bitvector rather than to a file.
- * The output vector is resized if necessary. See also @ref GlossUserFlags
- * .
+ * The output vector is resized if necessary. See also @ref GlossUserFlags .
*/
void save_user_flags (std::vector<bool> &v) const;
/**
* Same as above, but store the flags to a bitvector rather than to a file.
- * The output vector is resized if necessary. See also @ref GlossUserFlags
- * .
+ * The output vector is resized if necessary. See also @ref GlossUserFlags .
*/
void save_user_flags_line (std::vector<bool> &v) const;
/**
* Same as above, but store the flags to a bitvector rather than to a file.
- * The output vector is resized if necessary. See also @ref GlossUserFlags
- * .
+ * The output vector is resized if necessary. See also @ref GlossUserFlags .
*/
void save_user_flags_quad (std::vector<bool> &v) const;
/**
* Same as above, but store the flags to a bitvector rather than to a file.
- * The output vector is resized if necessary. See also @ref GlossUserFlags
- * .
+ * The output vector is resized if necessary. See also @ref GlossUserFlags .
*/
void save_user_flags_hex (std::vector<bool> &v) const;
/**
* Returns a point belonging to the Manifold<dim,spacedim> where this object
- * lives, given its parametric coordinates on the reference #structdim cell.
+ * lives, given its parametric coordinates on the reference @p structdim cell.
* This function queries the underlying manifold object, and can be used to
* obtain the exact geometrical location of arbitrary points on this object.
*
* Notice that the argument @p coordinates are the coordinates on the
- * <emph>reference cell</emph>, given in reference coordinates. In other
+ * <em>reference cell</em>, given in reference coordinates. In other
* words, the argument provides a weighting between the different vertices.
* For example, for lines, calling this function with argument Point<1>(.5),
* is equivalent to asking the line for its center.
* This will produce the following meshes after the two refinements we
* perform, in 2d and 3d, respectively:
*
- * @image html cone_2d.png @image html cone_3d.png
+ * @image html cone_2d.png
+ * @image html cone_3d.png
*
* @author Markus Bürg, 2009
*/
* @endcode
* Using this, the slot will then generate files that when visualized look
* like this over the course of iterations zero to five: <table> <tr> <td>
- * @image html "cg-monitor-smoothing-0.png" </td> <td> @image html "cg-
- * monitor-smoothing-1.png" </td> <td> @image html "cg-monitor-
- * smoothing-2.png" </td> </tr> <tr> <td> @image html "cg-monitor-
- * smoothing-3.png" </td> <td> @image html "cg-monitor-smoothing-4.png" </td>
- * <td> @image html "cg-monitor-smoothing-5.png" </td> </tr> </table>
+ * @image html "cg-monitor-smoothing-0.png"
+ * </td> <td>
+ * @image html "cg-monitor-smoothing-1.png"
+ * </td> <td>
+ * @image html "cg-monitor-smoothing-2.png"
+ * </td> </tr> <tr> <td>
+ * @image html "cg-monitor-smoothing-3.png"
+ * </td> <td>
+ * @image html "cg-monitor-smoothing-4.png"
+ * </td>
+ * <td>
+ * @image html "cg-monitor-smoothing-5.png"
+ * </td> </tr> </table>
*
* @ingroup Solvers
* @author Wolfgang Bangerth, Guido Kanschat, Ralf Hartmann, 1997-2001, 2005,
/**
* Initialize with a SolverControl object. The result will emulate
- * SolverControl by setting #reduce to zero.
+ * SolverControl by setting @p reduce to zero.
*/
ReductionControl (const SolverControl &c);
/**
* Assign a SolverControl object to ReductionControl. The result of the
- * assignment will emulate SolverControl by setting #reduce to zero.
+ * assignment will emulate SolverControl by setting @p reduce to zero.
*/
ReductionControl &operator= (const SolverControl &c);
* application is also the use of a Krylov space method inside the
* preconditioner.
*
- * FGMRES needs two vectors in each iteration steps yielding a total of <tt>2
- * * SolverFGMRESAdditionalData::max_basis_size+1</tt> auxiliary vectors.
+ * FGMRES needs two vectors in each iteration steps yielding a total of
+ * <tt>2 * SolverFGMRESAdditionalData::max_basis_size+1</tt> auxiliary vectors.
*
* Caveat: documentation of this class is not up to date. There are also a few
* parameters of GMRES we would like to introduce here.
BOOST_SERIALIZATION_SPLIT_MEMBER()
/**
- * @addtogroup Exceptions @name Exceptions
+ * @addtogroup Exceptions
* @{
*/
/**
* range in @p cell_loop runs from zero to n_macro_cells() (exclusive), so
* this is the appropriate size if you want to store arrays of data for all
* cells to be worked on. This number is approximately
- * n_physical_cells()/VectorizedArray::n_array_elements (depending on how
+ * n_physical_cells()/VectorizedArray<number>::n_array_elements (depending on how
* many cell chunks that do not get filled up completely).
*/
unsigned int n_macro_cells () const;
* the ones where the global degree of freedom is locally owned and the
* level degree of freedom is not.
*
- * Organization of the data is like for #copy_indices_mine.
+ * Organization of the data is like for @p copy_indices_mine.
*/
std::vector<std::vector<std::pair<types::global_dof_index, unsigned int> > >
copy_indices_to_me;
* the ones where the level degree of freedom is locally owned and the
* global degree of freedom is not.
*
- * Organization of the data is like for #copy_indices_mine.
+ * Organization of the data is like for @p copy_indices_mine.
*/
std::vector<std::vector<std::pair<types::global_dof_index, unsigned int> > >
copy_indices_from_me;
* Return a @p Vector with the indices of selected points flagged with a 1.
* This method is mainly for testing and verifying that the class is working
* correctly. By passing this vector to a DataOut object, the user can
- * verify that the positions returned by @p PointValueHistory< dim
- * >::get_points agree with the positions that @p DataOut interprets from
+ * verify that the positions returned by @p get_points
+ * agree with the positions that @p DataOut interprets from
* the @p Vector returned. The code snippet below demonstrates how this
* could be done:
* @code
/**
- * Depreciated:
+ * @deprecated
*
* This function only exists for backward compatibility as this is the
* interface provided by previous versions of the library. The function
* mark_support_locations replaces it and reflects the fact that the
* locations marked are actually the support points.
- *
- * @deprecated
*/
Vector<double> mark_locations() DEAL_II_DEPRECATED;
void get_support_locations (std::vector <std::vector<Point <dim> > > &locations);
/**
- * Depreciated:
+ * @deprecated
*
* This function only exists for backward compatibility as this is the
* interface provided by previous versions of the library. The function
* on a circle and on a sphere to which the constraints computed by this
* function have been applied:
*
- * <p ALIGN="center"> @image html no_normal_flux_5.png @image html
- * no_normal_flux_6.png </p>
+ * <p ALIGN="center">
+ * @image html no_normal_flux_5.png
+ * @image html no_normal_flux_6.png
+ * </p>
*
* The vectors fields are not physically reasonable but the tangentiality
* constraint is clearly enforced. The fact that the vector fields are zero
projects / dealii.git / commitdiff