From: Daniel Arndt Date: Sun, 12 Apr 2020 23:36:45 +0000 (-0400) Subject: Fix examples X-Git-Tag: v9.2.0-rc1~207^2~19 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c5f6c54130e974c83c45a0c4a4d81935847ab239;p=dealii.git Fix examples --- diff --git a/examples/step-18/doc/intro.dox b/examples/step-18/doc/intro.dox index 9f07b357a0..784da5caf5 100644 --- a/examples/step-18/doc/intro.dox +++ b/examples/step-18/doc/intro.dox @@ -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 diff --git a/examples/step-18/step-18.cc b/examples/step-18/step-18.cc index b792aaf2f9..fa9c3e28af 100644 --- a/examples/step-18/step-18.cc +++ b/examples/step-18/step-18.cc @@ -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 - // GeometryInfo@::vertices_per_cell*fe.dofs_per_vertex + // GeometryInfo@::%vertices_per_cell*fe.dofs_per_vertex // quadrature points will then correspond to the vertices of the cell and // are ordered consistent with cell-@>vertex(i), taking into // account that support points for vector elements will be duplicated diff --git a/examples/step-20/step-20.cc b/examples/step-20/step-20.cc index 5735bc81b4..da3d294e6a 100644 --- a/examples/step-20/step-20.cc +++ b/examples/step-20/step-20.cc @@ -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::write_vtu() to generate a vector representation of // the individual velocity components, see step-22 or the // @ref VVOutput "Generating graphical output" diff --git a/examples/step-3/doc/results.dox b/examples/step-3/doc/results.dox index 082fa7f2e5..25c51055fc 100644 --- a/examples/step-3/doc/results.dox +++ b/examples/step-3/doc/results.dox @@ -428,7 +428,6 @@ This is now going to look as follows: -
  • For plotting the converge curves we need to re-run the C++ code multiple times with different values for n_refinement_steps 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 - - +
    - - + + -
    - + diff --git a/examples/step-40/step-40.cc b/examples/step-40/step-40.cc index 472c28e313..f9a5f89778 100644 --- a/examples/step-40/step-40.cc +++ b/examples/step-40/step-40.cc @@ -30,9 +30,11 @@ #include -// 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 diff --git a/examples/step-45/step-45.cc b/examples/step-45/step-45.cc index 856949396f..dfb11ed1bb 100644 --- a/examples/step-45/step-45.cc +++ b/examples/step-45/step-45.cc @@ -428,7 +428,7 @@ namespace Step45 // For setting up the constraints, we first store the periodicity // information in an auxiliary object of type // std::vector@::cell_iterator@> . The periodic boundaries + // DoFHandler@::%cell_iterator@> . 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 diff --git a/examples/step-50/step-50.cc b/examples/step-50/step-50.cc index 4f379b1777..664425f3fa 100644 --- a/examples/step-50/step-50.cc +++ b/examples/step-50/step-50.cc @@ -75,7 +75,7 @@ #include -// #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 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 { diff --git a/examples/step-62/step-62.cc b/examples/step-62/step-62.cc index 5d77dca09c..db4d17a25c 100644 --- a/examples/step-62/step-62.cc +++ b/examples/step-62/step-62.cc @@ -66,7 +66,7 @@ #include // We need this header for the function GridTools::find_active_cell_around_point -// that we use in the function `ElasticWave::store_frequency_step_data()` +// that we use in the function `ElasticWave::store_frequency_step_data()` #include namespace step62 diff --git a/examples/step-69/step-69.cc b/examples/step-69/step-69.cc index 2c596e1fba..2af0b92583 100644 --- a/examples/step-69/step-69.cc +++ b/examples/step-69/step-69.cc @@ -1250,8 +1250,8 @@ namespace Step69 // // We have one more difficulty to overcome: In order to implement the // on_subranges lambda we need to name the iterator type - // of the object returned by boost::irange(). This is unfortunately a very convoluted name exposing + // of the object returned by boost::irange%(). This is unfortunately a very convoluted name exposing // implementation details about boost::irange. For this // reason we resort to the decltype @@ -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}