Work was done by codespell and the (newly fixed) double_word_typos.py script.
SKIP = ["//", "*", "}", "|", "};", ">", "\"", "|", "/",
"numbers::invalid_unsigned_int,", "std::string,", "int,"]
-with open(sys.argv[1], 'r') as handle:
+with open(sys.argv[1], 'r', encoding='utf-8') as handle:
previous_line = ""
for line_n, line in enumerate(handle):
line = line.strip()
continue
if words[0] in ["*", "//"]:
words = words[1:]
+ if len(words) == 0:
+ continue
# See if the last word on the previous line is equal to the first word
# on the current line.
if len(previous_words) != 0:
if words[0] not in SKIP and previous_words[-1] == words[0]:
- print(sys.argv[1] + ":{}: {}".format(line_n + 1, previous_line))
- print(sys.argv[1] + ":{}: {}".format(line_n + 2, line))
+ print(sys.argv[1] + ":{}: {}".format(line_n, previous_line))
+ print(sys.argv[1] + ":{}: {}".format(line_n + 1, line))
previous_line = line
for left_word, right_word in zip(words[:-1], words[1:]):
* 10);
* // again disable all manifolds for demonstration purposes
* triangulation.reset_all_manifolds();
- * // reenable the
+ * // reenable the manifold:
* triangulation.set_all_manifold_ids(0);
* triangulation.set_manifold (0, manifold);
* triangulation.refine_global (3);
* library uses SIMD vectorization and highly optimized kernels based on
* templates of the polynomial degree to achieve this goal. To give a
* perspective, a sparse matrix-vector product for quadratic elements FE_Q
- * used to be equally fast as the matrix-free implementation on procesors
+ * used to be equally fast as the matrix-free implementation on processors
* designed around 2005-2007 (e.g. Pentium 4 or AMD Opteron Barcelona
* with 2-4 cores per chip). By 2018, the matrix-free evaluation is around
* eight times as fast (measured on Intel Skylake Server, 14 cores).
* found. In this case, we also do not look for opportunities to find the same
* pattern on more than one cell, even though such cases might exist such as
* for extruded meshes. This search operation, which is based on inserting
- * data into an `std::map` using a custom floating point comparator
+ * data into a `std::map` using a custom floating point comparator
* `FPArrayComparator`, is efficient enough when a single data field per cell
* is used. However, it would be pretty expensive if done for all quadrature
* points of all cells (with many different cases).
* two components can be easily held apart. What makes the code a bit awkward
* to read is the fact that we need to batch several objects together from the
* original scalar evaluation done in an FEValues object, that we need to
- * identify data fields that are repetitive, and that we need to fine the
- * compression over several cells throught an `std::map` for the Cartesian and
+ * identify data fields that are repetitive, and that we need to define the
+ * compression over several cells with a `std::map` for the Cartesian and
* affine cases.
*
* The data computation part of MappingInfo is parallelized by tasks besides
for (unsigned int step=0; step<5; ++step)
{
// Next, we need to loop over the active cells of the triangulation. You
- // can think of a triangulation as a collection of cells. If it was an
- // an array, you would just get a pointer that you increment from one
+ // can think of a triangulation as a collection of cells. If it were an
+ // array, you would just get a pointer that you increment from one
// element to the next using the operator `++`. The cells of a
// triangulation aren't stored as a simple array, but the concept of an
// <i>iterator</i> generalizes how pointers work to arbitrary collections
different processors run through different blocks of code in their
copy of the executable. Programs internally also often communicate
in other ways than through collectives. But in practice, %parallel finite
-finite element codes almost always follow the scheme where every copy
+element codes almost always follow the scheme where every copy
of the program runs through the same blocks of code at the same time,
interspersed by phases where all processors communicate with each other.)
Since all this can only be demonstrated using actual code, let us go straight to the
code without much further ado.
-
\f}
<h3>Discretization of the equations in time</h3>
-Now, we can discretize the split formulation in time using the the
+Now, we can discretize the split formulation in time using the
$\theta$-method, which has a stencil of only two time steps. By
choosing a $\theta\in [0,1]$, the latter discretization allows us to
choose from a continuum of schemes. In particular, if we pick
}
// For completeness, we output the zeroth time step to a file just like
- // any other other time step.
+ // any other time step.
output_results (0);
// Now we perform the time stepping: at every time step we solve the
//
// In this function as well as many below, we measure how much time
// we spend here and collect that in a section called "Setup dof
- // systems" across function invokations. This is done using an
+ // systems" across function invocations. This is done using an
// TimerOutput::Scope object that gets a timer going in the section
// with above name of the `computing_timer` object upon construction
// of the local variable; the timer is stopped again when the
would have to be modified.
Similarly, if we wanted to improve on the linear or nonlinear solvers, or on
-the time stepping scheme (as hinted at
at the end of the <a
+the time stepping scheme (as hinted at the end of the <a
href="#Results">results section</a>), then this would not require changes in
the <code>EulerEquations</code> at all.
-
Notice that the evaluation of the above formula for $\mathbf{x} \in
\Omega$ should yield zero as a result, since the integration of the
-the Dirac delta $\delta(\mathbf{x})$ in the domain
+Dirac delta $\delta(\mathbf{x})$ in the domain
$\mathbb{R}^n\backslash\Omega$ is always zero by definition.
As a final test, let us verify that this velocity indeed satisfies the
Since the <code>verbose</code> parameter is set to <code>false</code>,
we do not get any kind of output besides the number of the time step
the program is currently working on.
-If we we were to set it to <code>true</code> we would get information on what the program is doing and
+If we were to set it to <code>true</code> we would get information on what the program is doing and
how many steps each iterative process had to make to converge, etc.
Let us plot the obtained results for $t=1,5,12,20,25$ (i.e. time steps
// is initialized using an IndexSet. IndexSet is used not only to resize the
// PETScWrappers::MPI::Vector but it also associates an index in the
// PETScWrappers::MPI::Vector with a degree of freedom (see step-40 for a
- // a more detailed explanation). The function complete_index_set() creates
+ // more detailed explanation). The function complete_index_set() creates
// an IndexSet where every valid index is part of the set. Note that this
// program can only be run sequentially and will throw an exception if used
// in parallel.
// element with a set of interpolation points derived from the same quadrature
// formula. The remainder of the function is relatively straightforward: we
// put the resulting matrix into the given argument; because we know the
- // matrix is diagonal, it is sufficient to have a loop over only $i$ not
+ // matrix is diagonal, it is sufficient to have a loop over only $i$ and
// not over $j$. Strictly speaking, we could even avoid multiplying the
// shape function's values at quadrature point <code>q_point</code> by itself
// because we know the shape value to be a vector with exactly one one which
// will have an inhomogeneity and will look like $x_0 = x_1/2 + \text{gap}/2$.
// So the corresponding entries in the
// ride-hang-side are non-zero with a
- // meaningless value. These values we have to
- // to set to zero.
+ // meaningless value. These values we have to set to zero.
// - Like in step-40, we need to shuffle between vectors that do and do
- // do not have ghost elements when solving or using the solution.
+ // not have ghost elements when solving or using the solution.
//
// The rest of the function is similar to step-40 and
// step-41 except that we use a BiCGStab solver
// deal.II). Alternatively, the neighbor could be on the same level
// and be further refined; then we have to find which of its children
// are next to the present cell and select these (note that if a child
- // of of neighbor of an active cell that is next to this active cell,
+ // of a neighbor of an active cell that is next to this active cell,
// needs necessarily be active itself, due to the one-refinement rule
// cited above).
//
public:
/**
* Constructor. Arguments are the center of the ball and its radius.
- * radius.
*
* If an argument <tt>select</tt> is given, the cut-off function will be
* non-zero for this component only.
public:
/**
* Constructor. Arguments are the center of the ball and its radius.
- * radius.
*
* If an argument <tt>select</tt> is given, the cut-off function will be
* non-zero for this component only.
* parameter; initially, the content of the file equals the default value of
* the parameter.
* - <code>default_value</code>: The content of this file is the default value
- * value of the parameter.
+ * of the parameter.
* - <code>pattern</code>: A textual representation of the pattern that
* describes the parameter's possible values.
* - <code>pattern_index</code>: A number that indexes the Patterns::PatternBase
"> of file <" << arg2 << ">: " << arg3);
/**
- * Exception for an an entry in a parameter file that does not match the
+ * Exception for an entry in a parameter file that does not match the
* provided pattern. The arguments are, in order, the line number, file
* name, entry value, entry name, and a description of the pattern.
*/
/**
* A struct that is used to sort arrays of pairs of eign=envalues and
- * eigenvectors. Sorting is performed in in descending order of eigenvalue.
+ * eigenvectors. Sorting is performed in descending order of eigenvalue.
*/
template <int dim, typename Number>
struct SortEigenValuesVectors
// described by an Ogden-type model (i.e. using an eigen-decomposition of the right
// Cauchy-Green tensor). Using this comparison between the well-understood result expected
// from the Neo-Hookean model and its Ogden equivalent, these parameters are a first
- // approximation to those required to collectively minimise error in the energy values,
+ // approximation to those required to collectively minimize error in the energy values,
// first and second derivatives. What's apparent is that all AD numbers and
// eigen-decomposition algorithms are not made equal!
double sf = 1.0;
* and any combination of that...
* @endcode
*
- * Optionally a matrix @p matrix along with an std::vector @p
+ * Optionally a matrix @p matrix along with a std::vector @p
* first_vector_components can be specified that describes how DoFs on @p
* face_1 should be modified prior to constraining to the DoFs of @p face_2.
* Here, two declarations are possible: If the std::vector @p
* Return whether this element implements its hanging node constraints in
* the new way, which has to be used to make elements "hp compatible".
*
- * This function returns @p true iff all its base elements return @p true
- * for this function.
+ * This function returns @p true if and only if all its base elements return
+ * @p true for this function.
*/
virtual bool hp_constraints_are_implemented () const;
* receive a different
* @ref GlossManifoldIndicator "manifold indicator",
* and the correct Manifold descriptor will be attached to
- * the Triangulation. Notice that if you later tranform the
+ * the Triangulation. Notice that if you later transform the
* triangulation, you have to make sure you attach the correct new Manifold
* to the triangulation.
*
const bool owns_pointers;
/**
- * The expresssion used to construct the push_forward function.
+ * The expression used to construct the push_forward function.
*/
const std::string push_forward_expression;
/**
- * The expresssion used to construct the pull_back function.
+ * The expression used to construct the pull_back function.
*/
const std::string pull_back_expression;
* correct function in the results section of step-49.
*
* @warning You should never set the boundary indicator of an interior face
- * (a face not at the boundary of the domain), or set set the boundary
+ * (a face not at the boundary of the domain), or set the boundary
* indicator of an exterior face to numbers::internal_face_boundary_id (this
* value is reserved for another purpose). Algorithms may not work or
* produce very confusing results if boundary cells have a boundary
/*
* Netlib and Atlas Lapack perform floating point tests (e.g. divide-by-zero) within the call to dsyevr
* causing floating point exceptions to be thrown (at least in debug mode). Therefore, we wrap the calls
- * to dsyevr into the following code to supress the exception.
+ * to dsyevr into the following code to suppress the exception.
*/
#ifdef DEAL_II_HAVE_FP_EXCEPTIONS
fenv_t fp_exceptions;
/*
* Netlib and Atlas Lapack perform floating point tests (e.g. divide-by-zero) within the call to ssyevr
* causing floating point exceptions to be thrown (at least in debug mode). Therefore, we wrap the calls
- * to ssyevr into the following code to supress the exception.
+ * to ssyevr into the following code to suppress the exception.
*/
#ifdef DEAL_II_HAVE_FP_EXCEPTIONS
fenv_t fp_exceptions;
/*
* Netlib ScaLAPACK performs floating point tests (e.g. divide-by-zero) within the call to pdsyevr
* causing floating point exceptions to be thrown (at least in debug mode). Therefore, we wrap the calls
- * to pdsyevr into the following code to supress the exception.
+ * to pdsyevr into the following code to suppress the exception.
*/
#ifdef DEAL_II_HAVE_FP_EXCEPTIONS
fenv_t fp_exceptions;
/*
* Netlib ScaLAPACK performs floating point tests (e.g. divide-by-zero) within the call to pssyevr
* causing floating point exceptions to be thrown (at least in debug mode). Therefore, we wrap the calls
- * to pssyevr into the following code to supress the exception.
+ * to pssyevr into the following code to suppress the exception.
*/
#ifdef DEAL_II_HAVE_FP_EXCEPTIONS
fenv_t fp_exceptions;
virtual Vector &operator+= (const VectorSpaceVector<double> &V) override;
/**
- * Substract the vector @p V from the present one.
+ * Subtract the vector @p V from the present one.
*/
virtual Vector &operator-= (const VectorSpaceVector<double> &V) override;
struct SelectEvaluator<dim, -1, n_q_points_1d, n_components, Number>
{
/**
- * Based on the the run time parameters stored in @p shape_info this function
+ * Based on the run time parameters stored in @p shape_info this function
* chooses an appropriate evaluation strategy for the integrate function, i.e.
* this calls internal::FEEvaluationImpl::evaluate(),
* internal::FEEvaluationImplCollocation::evaluate() or
const bool evaluate_hessians);
/**
- * Based on the the run time parameters stored in @p shape_info this function
+ * Based on the run time parameters stored in @p shape_info this function
* chooses an appropriate evaluation strategy for the integrate function, i.e.
* this calls internal::FEEvaluationImpl::integrate(),
* internal::FEEvaluationImplCollocation::integrate() or
/**
* Return a read-only pointer to the first field of the dof values. This is
* the data field the read_dof_values() functions write into. First come the
- * the dof values for the first component, then all values for the second
+ * dof values for the first component, then all values for the second
* component, and so on. This is related to the internal data structures
* used in this class. In general, it is safer to use the get_dof_value()
* function instead.
* A class that is used to compare floating point arrays (e.g. std::vectors,
* Tensor<1,dim>, etc.). The idea of this class is to consider two arrays as
* equal if they are the same within a given tolerance. We use this
- * comparator class within an std::map<> of the given arrays. Note that this
+ * comparator class within a std::map<> of the given arrays. Note that this
* comparison operator does not satisfy all the mathematical properties one
* usually wants to have (consider e.g. the numbers a=0, b=0.1, c=0.2 with
* tolerance 0.15; the operator gives a<c, but neither of a<b? or b<c? is
* <h4>Selective use of blocks in MatrixFree</h4>
*
* MatrixFree allows to use several DoFHandler/ConstraintMatrix combinations
- * by passing an std::vector with pointers to the respective objects into
+ * by passing a std::vector with pointers to the respective objects into
* the MatrixFree::reinit function. This class supports to select only some
* of the blocks in the underlying MatrixFree object by optional integer
* lists that specify the chosen blocks.
* vector of two pointers pointing to the same DoFHandler object and a
* vector of two pointers to the two ConstraintMatrix objects. If the first
* constraint matrix is the one including the zero Dirichlet constraints,
- * one would give an std::vector<unsigned int>(1, 0) to the initialize()
+ * one would give a std::vector<unsigned int>(1, 0) to the initialize()
* function, i.e., a vector of length 1 that selects exactly the first
* constraint matrix with index 0.
*
*
* @note This situation can only happen if you do coarsening. If all cells
* remain as they are or are refined, then SolutionTransfer::interpolate()
- * computes a new vector of nodel values, but the function represented is of
+ * computes a new vector of nodal values, but the function represented is of
* course exactly the same because the old finite element space is a subspace
* of the new one. Thus, if the old function was conforming (i.e., satisfied
* hanging node constraints), then so does the new one, and it is not
// from a practical viewpoint such
// problems should be much rarer. in
// particular, meshes have to be very
- // very fine for a vertex to land on
+ // fine for a vertex to land on
// this line if the original body had a
// vertex on the diagonal as well
switch (dim)
/**
* The fourth-order spatial deviatoric tensor. Also known as the deviatoric
* operator, this tensor projects a second-order symmetric tensor onto a
- * a deviatoric space (for which the hydrostatic component is removed).
+ * deviatoric space (for which the hydrostatic component is removed).
*
* This is defined as
* @f[
projects / dealii.git / commitdiff