From: Timo Heister Date: Wed, 24 Dec 2014 14:24:05 +0000 (-0500) Subject: fix doxygen formatting X-Git-Tag: v8.2.0~3^2~11 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c613a01d9ee0eebb28bdfac1664062be653b74c9;p=dealii.git fix doxygen formatting reformat a couple of places in the doxygen comments manually (broken @image lines etc.). This is mostly to make wrapcomments.py happy. --- diff --git a/include/deal.II/base/parameter_handler.h b/include/deal.II/base/parameter_handler.h index c608d0ec92..250be624d2 100644 --- a/include/deal.II/base/parameter_handler.h +++ b/include/deal.II/base/parameter_handler.h @@ -1437,8 +1437,11 @@ namespace Patterns * * Given this explanation, the code above will lead to a hierarchical * representation of data that looks like this (the content of files is - * indicated at the right in a different font): @image html - * parameter_handler.png Once parameters have been read in, the contents of + * indicated at the right in a different font): + * + * @image html parameter_handler.png + * + * Once parameters have been read in, the contents of * the value "files" may be different while the other files * remain untouched. * diff --git a/include/deal.II/base/polynomial_space.h b/include/deal.II/base/polynomial_space.h index 73fb3185e7..852a209faa 100644 --- a/include/deal.II/base/polynomial_space.h +++ b/include/deal.II/base/polynomial_space.h @@ -54,24 +54,42 @@ DEAL_II_NAMESPACE_OPEN *
1D
x0, x1,...,xn *
2D:
x0y0, * x1y0,..., - * xny0,
+ * xny0, + *
* x0y1, x1y1,..., - * xn-1y1,
+ * xn-1y1, + *
* x0y2,... - * xn-2y2,
...
+ * xn-2y2, + *
+ * ... + *
* x0yn-1, - * x1yn-1,
+ * x1yn-1, + *
* x0yn
3D:
* x0y0z0,..., - * xny0z0,
+ * xny0z0, + *
* x0y1z0,..., - * xn-1y1z0,
...
- * x0ynz0,
+ * xn-1y1z0, + *
+ * ... + *
+ * x0ynz0, + *
* x0y0z1,... - * xn-1y0z1,
...
- * x0yn-1z1,
+ * xn-1y0z1, + *
+ * ... + *
+ * x0yn-1z1, + *
* x0y0z2,... - * xn-2y0z2,
...
+ * xn-2y0z2, + *
+ * ... + *
* x0y0zn
* * @ingroup Polynomials diff --git a/include/deal.II/dofs/dof_renumbering.h b/include/deal.II/dofs/dof_renumbering.h index e9287e25fe..908856f13d 100644 --- a/include/deal.II/dofs/dof_renumbering.h +++ b/include/deal.II/dofs/dof_renumbering.h @@ -247,9 +247,15 @@ DEAL_II_NAMESPACE_OPEN * actually several times faster. * * - * - * - * + * + * + * * * - * - * - * + * + * + * * * - *
@image html "reorder_sparsity_step_31_original.png" @image html "reorder_sparsity_step_31_random.png" @image html "reorder_sparsity_step_31_deal_cmk.png" + * @image html "reorder_sparsity_step_31_original.png" + * + * @image html "reorder_sparsity_step_31_random.png" + * + * @image html "reorder_sparsity_step_31_deal_cmk.png" + *
* Enumeration as produced by deal.II's DoFHandler::distribute_dofs function * and no further reordering apart from the component-wise one. @@ -274,9 +280,15 @@ DEAL_II_NAMESPACE_OPEN * With this renumbering, we needed an average of 57.3 iterations for the * testcase outlined above, and a runtime of 6min10s.
@image html "reorder_sparsity_step_31_boost_cmk.png" @image html "reorder_sparsity_step_31_boost_king.png" @image html "reorder_sparsity_step_31_boost_md.png"
+ * @image html "reorder_sparsity_step_31_boost_cmk.png" + * + * @image html "reorder_sparsity_step_31_boost_king.png" + * + * @image html "reorder_sparsity_step_31_boost_md.png" + *
Cuthill- * McKee enumeration as produced by calling the BOOST implementation of the * algorithm provided by DoFRenumbering::boost::Cuthill_McKee after @@ -310,7 +322,9 @@ DEAL_II_NAMESPACE_OPEN * With this renumbering, we needed an average of 58.9 iterations for the * testcase outlined above, and a runtime of 6min11s.
@image html "reorder_sparsity_step_31_downstream.png" + *
+ * @image html "reorder_sparsity_step_31_downstream.png" + * *
Downstream enumeration using * DoFRenumbering::downstream using a direction that points diagonally through * the domain. diff --git a/include/deal.II/fe/fe_base.h b/include/deal.II/fe/fe_base.h index 63bb97d29e..2bd0a73768 100644 --- a/include/deal.II/fe/fe_base.h +++ b/include/deal.II/fe/fe_base.h @@ -161,7 +161,8 @@ public: * Since discontinuous elements have no topological couplings between grid * cells and code may actually depend on this property, L2 * conformity is handled in a special way in the sense - * that it is not implied by any higher conformity. + * that it is not implied by any higher conformity. + * * * In order to test if a finite element conforms to a certain space, use * FiniteElementData::conforms(). diff --git a/include/deal.II/fe/fe_dgp.h b/include/deal.II/fe/fe_dgp.h index c66eda590b..8f6471da11 100644 --- a/include/deal.II/fe/fe_dgp.h +++ b/include/deal.II/fe/fe_dgp.h @@ -81,7 +81,8 @@ template class MappingQ; * elements of type FE_DGP(1) or FE_DGPMonomial(1). * * This can be understood by the following 2-d example: consider the cell with - * vertices at $(0,0),(1,0),(0,1),(s,s)$: @image html dgp_doesnt_contain_p.png + * vertices at $(0,0),(1,0),(0,1),(s,s)$: + * @image html dgp_doesnt_contain_p.png * * For this cell, a bilinear transformation $F$ produces the relations $x=\hat * x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference diff --git a/include/deal.II/fe/fe_dgp_monomial.h b/include/deal.II/fe/fe_dgp_monomial.h index 44a30b64fa..56aab7b939 100644 --- a/include/deal.II/fe/fe_dgp_monomial.h +++ b/include/deal.II/fe/fe_dgp_monomial.h @@ -60,7 +60,8 @@ template class MappingQ; * elements of type FE_DGP(1) or FE_DGPMonomial(1). * * This can be understood by the following 2-d example: consider the cell with - * vertices at $(0,0),(1,0),(0,1),(s,s)$: @image html dgp_doesnt_contain_p.png + * vertices at $(0,0),(1,0),(0,1),(s,s)$: + * @image html dgp_doesnt_contain_p.png * * For this cell, a bilinear transformation $F$ produces the relations $x=\hat * x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference diff --git a/include/deal.II/grid/tria.h b/include/deal.II/grid/tria.h index bcb4ff3281..c97b472a07 100644 --- a/include/deal.II/grid/tria.h +++ b/include/deal.II/grid/tria.h @@ -2840,7 +2840,9 @@ public: */ /** - * Exception @ingroup Exceptions + * Exception + * + * @ingroup Exceptions */ DeclException1 (ExcInvalidLevel, int, @@ -2874,7 +2876,9 @@ public: << "You tried to do something on level " << arg1 << ", but this level is empty."); /** - * Exception @ingroup Exceptions + * Exception + * + * @ingroup Exceptions */ DeclException0 (ExcNonOrientableTriangulation); diff --git a/include/deal.II/lac/sparse_decomposition.h b/include/deal.II/lac/sparse_decomposition.h index f5288d31cb..8e321220a7 100644 --- a/include/deal.II/lac/sparse_decomposition.h +++ b/include/deal.II/lac/sparse_decomposition.h @@ -314,8 +314,9 @@ protected: /** * In the decomposition phase, computes a strengthening factor for the * diagonal entry in row row with sum of absolute values of its - * elements rowsum.
Note: - * The default implementation in SparseLUDecomposition returns + * elements rowsum. + * + * @note The default implementation in SparseLUDecomposition returns * strengthen_diagonal's value. */ virtual number get_strengthen_diagonal(const number rowsum, const size_type row) const; diff --git a/include/deal.II/numerics/vector_tools.h b/include/deal.II/numerics/vector_tools.h index 4a80464fb8..87181b23fe 100644 --- a/include/deal.II/numerics/vector_tools.h +++ b/include/deal.II/numerics/vector_tools.h @@ -1233,7 +1233,9 @@ namespace VectorTools * revolves around the question what the normal vector is. Consider the * following situation: * - *

@image html no_normal_flux_1.png

+ *

+ * @image html no_normal_flux_1.png + *

* * Here, we have two cells that use a bilinear mapping (i.e. MappingQ1). * Consequently, for each of the cells, the normal vector is perpendicular @@ -1260,7 +1262,9 @@ namespace VectorTools * * Unfortunately, this is not quite enough. Consider the situation here: * - *

@image html no_normal_flux_2.png

+ *

+ * @image html no_normal_flux_2.png + *

* * If again the top and right edges approximate a curved boundary, and the * left boundary a separate boundary (for example straight) so that the @@ -1283,7 +1287,9 @@ namespace VectorTools * we have considered above, is discretized with the following mesh, then we * get into trouble: * - *

@image html no_normal_flux_3.png

+ *

+ * @image html no_normal_flux_3.png + *

* * Here, the algorithm assumes that the boundary does not have a corner at * the point where faces $F1$ and $F2$ join because at that point there are @@ -1307,7 +1313,9 @@ namespace VectorTools * The situation is more complicated in 3d. Consider the following case * where we want to compute the constraints at the marked vertex: * - *

@image html no_normal_flux_4.png

+ *

+ * @image html no_normal_flux_4.png + *

* * Here, we get four different normal vectors, one from each of the four * faces that meet at the vertex. Even though they may form a complete set