@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
// 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
// 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"
</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.
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>
#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
// 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
#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
{
// 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
{
#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
//
// 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>
// $\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}