<h3>Instantiation of templated functions/classes</h3>
-<p> Majority of classes and functions in deal.II are templated. This brings a
+<p>The majority of classes and functions in deal.II are templated. This brings a
question of how and where such objects are instantiated, if at all. Throughout
deal.II we adopt the following convention:</p>
* until we hit a certain fraction of the <i>norm of the initial
* residual</i>.
* - In the second approach, we get the same problem if the starting vector
- * in the iteration is zero, since then then the residual may be
+ * in the iteration is zero, since then the residual may be
* dominated by constrained degrees of freedom having values that do not
* match the values we want for them at the solution. We can again
* circumvent this problem by setting the corresponding elements of the
* <i>International Journal for Numerical Methods in Engineering</i>
* 20(11):2107-2112, 1985).
*
- * Here, $A$ is a given (unconstrained) system matrix for wich we only
+ * Here, $A$ is a given (unconstrained) system matrix for which we only
* assume that we can apply it to a vector but can not necessarily access
* individual matrix entries. $b$ is the corresponding right hand side of a
* system of linear equations $A\,x=b$. The matrix $C$ describes the
/**
* @defgroup febase Base classes
*
- * The members of this sub-module describe the implementational mechanics of
+ * The members of this sub-module describe the implementation mechanics of
* finite element classes, without actually implementing a concrete
* element. For example, the FiniteElement base class declares the virtual
* functions a derived class has to implement if it wants to describe a finite
* quadrature points -- these quadrature points are then simply the vertices
* of the cells (provided, for example, by QTrapez).
*
- * FEValues's role is to provide a user the values of shape functions, their
+ * FEValues' role is to provide a user the values of shape functions, their
* gradients, etc, at quadrature points. The same is true with some geometric
* information, e.g., the normal vectors at the quadrature points. To this end,
* it provides a large number of member functions in the FEValuesBase base
* then take the square root of the result. This is what the
* parallel::accumulate_from_subranges function does (note that you
* have to specify the result type as a template argument and that, as
- * usual, the minimumum number of elements of the outer loop that can
+ * usual, the minimum number of elements of the outer loop that can
* be scheduled on a single CPU core is given as the last argument):
* @code
double
* <li>FEValues::reinit() calls Mapping::fill_fe_values(), then FiniteElement::fill_fe_values()
* <li>FEFaceValues::reinit() calls Mapping::fill_fe_face_values(), then FiniteElement::fill_fe_face_values()
* <li>FESubfaceValues::reinit() calls Mapping::fill_fe_subface_values(),
- * thenFiniteElement::fill_fe_subface_values()
+ * then FiniteElement::fill_fe_subface_values()
* </ul>
*
* This is where the actual data fields for FEValues, stored in
* would represent the gradient of the scalar pressure component, which
* is of type <code>Tensor@<1,dim@></code>, whereas the gradient of the
* velocities components, <code>fe_values[velocities].gradient(i,q)</code>
- * is a <code>Tensor@<2,dim@></code>, i.e. a matrix $G_{ij}$ that consits
+ * is a <code>Tensor@<2,dim@></code>, i.e. a matrix $G_{ij}$ that consists
* of entries $G_{ij}=\frac{\partial\phi_i}{\partial x_j}$. Finally,
* both scalar and vector views can be asked for the second derivatives
* ("Hessians") and vector views can be asked for the symmetric gradient,
projects / dealii.git / commitdiff