]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Fix examples
authorDaniel Arndt <arndtd@ornl.gov>
Sun, 12 Apr 2020 23:36:45 +0000 (19:36 -0400)
committerDaniel Arndt <arndtd@ornl.gov>
Fri, 17 Apr 2020 16:21:12 +0000 (12:21 -0400)
examples/step-18/doc/intro.dox
examples/step-18/step-18.cc
examples/step-20/step-20.cc
examples/step-3/doc/results.dox
examples/step-40/step-40.cc
examples/step-45/step-45.cc
examples/step-50/step-50.cc
examples/step-62/step-62.cc
examples/step-69/step-69.cc

index 9f07b357a0214bf688aff1089b24ff8d4aa597ce..784da5caf569271a345db801b26f81658d8292c3 100644 (file)
@@ -424,7 +424,7 @@ using the syntax
 @endcode
 This knowledge extends to the DoFHandler object built on such triangulations,
 which can then identify which degrees of freedom are locally owned
-(see @ref GlossLocallyOwnedDofs) via calls such as
+(see @ref GlossLocallyOwnedDof) via calls such as
 DoFHandler::compute_n_locally_owned_dofs_per_processor() and
 DoFTools::extract_locally_relevant_dofs(). Finally, the DataOut class
 also knows how to deal with such triangulations and will simply skip
index b792aaf2f90af8e2c73c634be99b3612b64a4335..fa9c3e28aff998c1d3ad4320a388824514549173 100644 (file)
@@ -1483,7 +1483,7 @@ namespace Step18
   // points, see @ref GlossSupport "support points"). For such a case, one
   // could construct a custom quadrature rule using
   // FiniteElement::get_unit_support_points(). The first
-  // <code>GeometryInfo@<dim@>::vertices_per_cell*fe.dofs_per_vertex</code>
+  // <code>GeometryInfo@<dim@>::%vertices_per_cell*fe.dofs_per_vertex</code>
   // quadrature points will then correspond to the vertices of the cell and
   // are ordered consistent with <code>cell-@>vertex(i)</code>, taking into
   // account that support points for vector elements will be duplicated
index 5735bc81b4ec9eaa1bd6a6e3604ab773cf29a727..da3d294e6aea8bfd90caa10578fa959072e77ca4 100644 (file)
@@ -755,7 +755,7 @@ namespace Step20
   // The last interesting function is the one in which we generate graphical
   // output. Note that all velocity components get the same solution name
   // "u". Together with using
-  // DataComponentInterpretation::::component_is_part_of_vector this will
+  // DataComponentInterpretation::component_is_part_of_vector this will
   // cause DataOut<dim>::write_vtu() to generate a vector representation of
   // the individual velocity components, see step-22 or the
   // @ref VVOutput "Generating graphical output"
index 082fa7f2e50b7f95ec7316d13c0d1df88b0ea8df..25c51055fc30bafd6456bdb3127b39e0ae9c38b1 100644 (file)
@@ -428,7 +428,6 @@ This is now going to look as follows:
    </td>
  </tr>
 </table>
-<li>
 
 For plotting the converge curves we need to re-run the C++ code multiple times with different values for <code>n_refinement_steps</code>
 starting from 1.
@@ -481,16 +480,13 @@ plt <- plt+scale_x_log10()+scale_y_log10()
 print(plt)
 
 dev.off()
-
+@endcode
 This results in the following plot that shows how the errors in the
 mean value and the solution value at the chosen point nicely converge
 to zero:
-@endcode
-</ul>
- <table style="width:50%" align="center">
+<table style="width:50%" align="center">
   <tr>
-     <td><img src="https://www.dealii.org/images/steps/developer/step-3.extensions.convergence_mean.png" alt=""></td>
-     <td><img src="https://www.dealii.org/images/steps/developer/step-3.extensions.convergence_point.png" alt=""></td>
+    <td><img src="https://www.dealii.org/images/steps/developer/step-3.extensions.convergence_mean.png" alt=""></td>
+    <td><img src="https://www.dealii.org/images/steps/developer/step-3.extensions.convergence_point.png" alt=""></td>
   </tr>
- </table>
-</ul>
+</table>
index 472c28e3136138c63a45dddd64972163c55368af..f9a5f897781728950ec3dc5d37e430d9a59f616d 100644 (file)
 
 #include <deal.II/lac/generic_linear_algebra.h>
 
-// uncomment the following #define if you have PETSc and Trilinos installed
+// uncomment the following \#define if you have PETSc and Trilinos installed
 // and you prefer using Trilinos in this example:
+// @code
 // #define FORCE_USE_OF_TRILINOS
+// @endcode
 
 // This will either import PETSc or TrilinosWrappers into the namespace
 // LA. Note that we are defining the macro USE_PETSC_LA so that we can detect
index 856949396ff3507a03349d3ab703c88658b02e33..dfb11ed1bbb3a5a282382451df522c4a14aabdfb 100644 (file)
@@ -428,7 +428,7 @@ namespace Step45
       // For setting up the constraints, we first store the periodicity
       // information in an auxiliary object of type
       // <code>std::vector@<GridTools::PeriodicFacePair<typename
-      // DoFHandler@<dim@>::cell_iterator@> </code>. The periodic boundaries
+      // DoFHandler@<dim@>::%cell_iterator@> </code>. The periodic boundaries
       // have the boundary indicators 2 (x=0) and 3 (y=0). All the other
       // parameters we have set up before. In this case the direction does not
       // matter. Due to $\text{vertices}_2=R\cdot \text{vertices}_1+b$ this is
index 4f379b177748e7d49f68804c3ed277ed3f24a8ba..664425f3fa023e69f3db71924027e7f7f5944124 100644 (file)
@@ -75,7 +75,7 @@
 
 #include <deal.II/lac/generic_linear_algebra.h>
 
-// #define USE_PETSC_LA PETSc is not quite supported yet
+// \#define USE_PETSC_LA PETSc is not quite supported yet
 
 namespace LA
 {
@@ -763,28 +763,22 @@ namespace Step50
 
     // With all this together, we can finally
     // get about solving the linear system in
-    // the usual way:
+    // the usual way (optionally comparing to Trilinos ML):
     SolverControl solver_control(500, 1e-8 * system_rhs.l2_norm(), false);
     SolverCG<VectorType> solver(solver_control);
 
     if (false)
       {
-        /*
-         // code to optionally compare to Trilinos ML
-         TrilinosWrappers::PreconditionAMG prec;
-
-         TrilinosWrappers::PreconditionAMG::AdditionalData Amg_data;
-         //    Amg_data.constant_modes = constant_modes;
-         Amg_data.elliptic = true;
-         Amg_data.higher_order_elements = true;
-         Amg_data.smoother_sweeps = 2;
-         Amg_data.aggregation_threshold = 0.02;
-         // Amg_data.symmetric = true;
-
-         prec.initialize (system_matrix,
-                          Amg_data);
-         solver.solve (system_matrix, solution, system_rhs, prec);
-        */
+        TrilinosWrappers::PreconditionAMG                 prec;
+        TrilinosWrappers::PreconditionAMG::AdditionalData Amg_data;
+        Amg_data.elliptic              = true;
+        Amg_data.higher_order_elements = true;
+        Amg_data.smoother_sweeps       = 2;
+        Amg_data.aggregation_threshold = 0.02;
+        Amg_data.symmetric             = true;
+
+        prec.initialize(system_matrix, Amg_data);
+        solver.solve(system_matrix, solution, system_rhs, prec);
       }
     else
       {
index 5d77dca09c33ff5b632f6369a5c8f071f1d02546..db4d17a25c6f4853618bcc115e2866d77ad265ad 100644 (file)
@@ -66,7 +66,7 @@
 #include <deal.II/numerics/vector_tools.h>
 
 // We need this header for the function GridTools::find_active_cell_around_point
-// that we use in the function `ElasticWave<dim>::store_frequency_step_data()`
+// that we use in the function `ElasticWave::store_frequency_step_data()`
 #include <deal.II/grid/grid_tools.h>
 
 namespace step62
index 2c596e1fbab6e78bb90f09dae71d44bf833d7186..2af0b92583199a35c1d8703d0b677b3ccb1417d3 100644 (file)
@@ -1250,8 +1250,8 @@ namespace Step69
     //
     // We have one more difficulty to overcome: In order to implement the
     // <code>on_subranges</code> lambda we need to name the iterator type
-    // of the object returned by <code>boost::irange<unsigned
-    // int>()</code>. This is unfortunately a very convoluted name exposing
+    // of the object returned by <code>boost::irange%<unsigned
+    // int%>()</code>. This is unfortunately a very convoluted name exposing
     // implementation details about <code>boost::irange</code>. For this
     // reason we resort to the <a
     // href="https://en.cppreference.com/w/cpp/language/decltype"><code>decltype</code></a>
@@ -1314,7 +1314,7 @@ namespace Step69
     // $\mathbf{m} \cdot \boldsymbol{\nu}_i =0$ on the entirety of the
     // boundary we should preserve the density and total (mechanical)
     // energy. This requires us to modify the $\mathbf{c}_{ij}$ vectors at
-    // the boundary as follows @cite GuermondEtAl2018:
+    // the boundary as follows @cite GuermondEtAl2018 :
     //
     // @f{align*}
     // \mathbf{c}_{ij} \, +\!\!= \int_{\partial \Omega}

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

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.