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 c608d0ec929549ea531aeb17b71a68b4e0acf375..250be624d21a0953b3ce2f4bbdebe30dbc4cc6c1 100644 (file)
--- 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 <code>value</code> "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 73fb3185e7ab39b0c9d75d3948b507d2aa9ad227..852a209faa4c34833489f539cc218eca27436829 100644 (file)
--- a/include/deal.II/base/polynomial_space.h
+++ b/include/deal.II/base/polynomial_space.h
@@ -54,24 +54,42 @@ DEAL_II_NAMESPACE_OPEN
  * <dl> <dt> 1D <dd> <i> x<sup>0</sup>, x<sup>1</sup>,...,x<sup>n</sup></i>
  * <dt> 2D: <dd> <i> x<sup>0</sup>y<sup>0</sup>,
  * x<sup>1</sup>y<sup>0</sup>,...,
- * x<sup>n</sup>y<sup>0</sup>,<br>
+ * x<sup>n</sup>y<sup>0</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>1</sup>, x<sup>1</sup>y<sup>1</sup>,...,
- * x<sup>n-1</sup>y<sup>1</sup>,<br>
+ * x<sup>n-1</sup>y<sup>1</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>2</sup>,...
- * x<sup>n-2</sup>y<sup>2</sup>,<br>...<br>
+ * x<sup>n-2</sup>y<sup>2</sup>,
+ * <br>
+ * ...
+ * <br>
  * x<sup>0</sup>y<sup>n-1</sup>,
- * x<sup>1</sup>y<sup>n-1</sup>,<br>
+ * x<sup>1</sup>y<sup>n-1</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>n</sup> </i> <dt> 3D: <dd> <i>
  * x<sup>0</sup>y<sup>0</sup>z<sup>0</sup>,...,
- * x<sup>n</sup>y<sup>0</sup>z<sup>0</sup>,<br>
+ * x<sup>n</sup>y<sup>0</sup>z<sup>0</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>1</sup>z<sup>0</sup>,...,
- * x<sup>n-1</sup>y<sup>1</sup>z<sup>0</sup>,<br>...<br>
- * x<sup>0</sup>y<sup>n</sup>z<sup>0</sup>,<br>
+ * x<sup>n-1</sup>y<sup>1</sup>z<sup>0</sup>,
+ * <br>
+ * ...
+ * <br>
+ * x<sup>0</sup>y<sup>n</sup>z<sup>0</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>0</sup>z<sup>1</sup>,...
- * x<sup>n-1</sup>y<sup>0</sup>z<sup>1</sup>,<br>...<br>
- * x<sup>0</sup>y<sup>n-1</sup>z<sup>1</sup>,<br>
+ * x<sup>n-1</sup>y<sup>0</sup>z<sup>1</sup>,
+ * <br>
+ * ...
+ * <br>
+ * x<sup>0</sup>y<sup>n-1</sup>z<sup>1</sup>,
+ * <br>
  * x<sup>0</sup>y<sup>0</sup>z<sup>2</sup>,...
- * x<sup>n-2</sup>y<sup>0</sup>z<sup>2</sup>,<br>...<br>
+ * x<sup>n-2</sup>y<sup>0</sup>z<sup>2</sup>,
+ * <br>
+ * ...
+ * <br>
  * x<sup>0</sup>y<sup>0</sup>z<sup>n</sup> </i> </dl>
  *
  * @ingroup Polynomials

diff --git a/include/deal.II/dofs/dof_renumbering.h b/include/deal.II/dofs/dof_renumbering.h
index e9287e25fe603590ae4bf9edd73e5a1cacefb04d..908856f13d02a86ca2cd7dfaab1e25b3a9ff6553 100644 (file)
--- 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.
  *
  * <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>
+ * <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.
@@ -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. </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> <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
@@ -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. </td> </tr>
  *
- * <tr> <td> @image html "reorder_sparsity_step_31_downstream.png" </td> <td>
+ * <tr> <td>
+ * @image html "reorder_sparsity_step_31_downstream.png"
+ * </td> <td>
  * </td> <td> </td> </tr> <tr> <td> 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 63bb97d29ea9969f1f821915d24a1bb098ff2ddd..2bd0a73768534b4eae8bb8bc192a973036792a9b 100644 (file)
--- 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, <i>L<sup>2</sup></i>
    * conformity is handled in a special way in the sense
-   * that it is <b>not</b> implied by any higher conformity.  </ol>
+   * that it is <b>not</b> implied by any higher conformity.
+   * </ol>
    *
    * In order to test if a finite element conforms to a certain space, use
    * FiniteElementData<dim>::conforms().

diff --git a/include/deal.II/fe/fe_dgp.h b/include/deal.II/fe/fe_dgp.h
index c66eda590ba92485531d801ea74de2fa71adaa89..8f6471da11afa2325c0c67bb70863ec118410281 100644 (file)
--- a/include/deal.II/fe/fe_dgp.h
+++ b/include/deal.II/fe/fe_dgp.h
@@ -81,7 +81,8 @@ template <int dim, int spacedim> 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 44a30b64fa661cf5172dd5b0cea70e864d6e05be..56aab7b93922ab509c39296a0d5c12ea8c2ec8b3 100644 (file)
--- a/include/deal.II/fe/fe_dgp_monomial.h
+++ b/include/deal.II/fe/fe_dgp_monomial.h
@@ -60,7 +60,8 @@ template <int dim, int spacedim> 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 bcb4ff3281e2e0dd4fde12415e72636c78b11688..c97b472a0700f4fe97009275f68dc77415e35f20 100644 (file)
--- 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 f5288d31cb8b9fa9eb954e7e1e644bdcb5142aa1..8e321220a73ec800313b75472fa53841cb2f846b 100644 (file)
--- 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 <tt>row</tt> with sum of absolute values of its
-   * elements <tt>rowsum</tt>.<br> Note:
-   * The default implementation in SparseLUDecomposition returns
+   * elements <tt>rowsum</tt>.
+   *
+   * @note The default implementation in SparseLUDecomposition returns
    * <tt>strengthen_diagonal</tt>'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 4a80464fb829923d8d609f7eefc38ff770943ce7..87181b23fe49fe21d8287dbdaacb3fe30728c440 100644 (file)
--- 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:
    *
-   * <p ALIGN="center"> @image html no_normal_flux_1.png </p>
+   * <p ALIGN="center">
+   * @image html no_normal_flux_1.png
+   * </p>
    *
    * 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:
    *
-   * <p ALIGN="center"> @image html no_normal_flux_2.png </p>
+   * <p ALIGN="center">
+   * @image html no_normal_flux_2.png
+   * </p>
    *
    * 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:
    *
-   * <p ALIGN="center"> @image html no_normal_flux_3.png </p>
+   * <p ALIGN="center">
+   * @image html no_normal_flux_3.png
+   * </p>
    *
    * 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:
    *
-   * <p ALIGN="center"> @image html no_normal_flux_4.png </p>
+   * <p ALIGN="center">
+   * @image html no_normal_flux_4.png
+   * </p>
    *
    * 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