* certain boundary_id values used in a triangulation and to certain
* manifold_id values.
*
- * Befor version 8.2, the library allowed only boundary faces to
+ * Before version 8.2, the library allowed only boundary faces to
* follow a curved geometric description. Since version 8.2 this has
* been introduced also for interior faces and cells, and the
* boundary_id has been separated from the manifold_id.
* boundary) or the material_id (if the Triangulation is of
* codimension one and the object is a cell). If the previous queries
* resulted in a number different from numbers::invalid_manifold_id,
- * then the Triangulation looks wether a previous call to
+ * then the Triangulation looks whether a previous call to
* Triangulation::set_manifold() (or set_boundary()) was performed
* with the given id, and if yes, it uses the stored object to obtain
* new vertices, otherwise it uses a FlatManifold or StraightBoundary
* - Each machine keeps the entire mesh and DoF handler locally, but
* only a share of the global matrix, sparsity pattern, and solution
* vector is stored on each machine.
- * - The mesh and DoFhandler are also distributed, i.e. each processor
+ * - The mesh and DoF handler are also distributed, i.e. each processor
* stores only a share of the cells and degrees of freedom. No
* processor has knowledge of the entire mesh, matrix, or solution,
* and in fact problems solved in this mode are usually so large
* computations, there is also no way to merge the results of all
* these local computations on a single machine, i.e. each processor
* has to be self-sufficient. For example, each processor has to
- * generate its own parallel output files that have to be visualizated
+ * generate its own parallel output files that have to be visualized
* by a program that can deal with multiple input files rather than
* merging the results of calling DataOut to a single processor before
* generating a single output file. The latter can be achieved, for
* @defgroup feaccess Finite element access/FEValues classes
*
* The classes in this module are used when one wants to assemble matrices or
- * vectors. They link finite elements, quadrature objects, and mappins: the
+ * vectors. They link finite elements, quadrature objects, and mappings: the
* finite element classes describe a finite element space on a unit cell
* (i.e. the unit line segment, square, or cube <tt>[0,1]^d</tt>), the
* quadrature classes describe where quadrature points are located and what
* <dd> The term "degree of freedom" (often abbreviated as "DoF") is commonly
* used in the finite element community to indicate two slightly different,
* but related things. The first is that we'd like to represent the finite
- * element solution as a linear combination of shape function, in the form
+ * element solution as a linear combination of shape functions, in the form
* $u_h(\mathbf x) = \sum_{j=0}^{N-1} U_j \varphi_j(\mathbf x)$. Here, $U_j$
- * is a vector of expension coefficients. Because we don't know their values
+ * is a vector of expansion coefficients. Because we don't know their values
* yet (we will compute them as the solution of a linear or nonlinear system),
* they are called "unknowns" or "degrees of freedom". The second meaning of
* the term can be explained as follows: A mathematical description of finite
*
* <dd> Every object that makes up a Triangulation (cells, faces,
* edges, etc.), is associated with a unique number (of type
- * types::manifol_id) that is used to identify which manifold object
+ * types::manifold_id) that is used to identify which manifold object
* is responsible to generate new points when the mesh is refined.
*
* By default, all manifold indicators of a mesh are set to
* sufficient, but on another cell where a Q3 element is used, this would lead
* to underintegration and we should use a QGauss(4) formula instead. Just as
* above, there exists a class hp::QCollection that acts as a collection of
- * quadrature formulas
+ * quadrature formulas.
*
* Finally, one may want to use different orders for the boundary
* approximation for cells with different orders for the finite element. The
*
* This way, one can add elements of polynomial degree 1 through 4 to the
* collection. It is not necessary to retain the added object: the collection
- * makes a coyp of it, it does not only store a pointer to the given finite
+ * makes a copy of it, it does not only store a pointer to the given finite
* element object. This same observation also holds for the other collection
* classes.
*
@defgroup Iterators Iterators on mesh-like containers
@{
-deal.II has several classes which are understood conceptionally as
+deal.II has several classes which are understood conceptually as
meshes. Apart from the obvious Triangulation, these are, for example,
DoFHandler and hp::DoFHandler. All of those define a set
of iterators, allowing the user to traverse the whole mesh, i.e. the
emanating from the cells of the coarse mesh then constitutes the forest that
completely describes the triangulation, including all of its active and
inactive cells. In particular, the active cells are those terminal nodes in
-the tree that have no decendants, i.e. cells which are not further
+the tree that have no descendants, i.e. cells which are not further
refined. Correspondingly, inactive cells correspond to nodes in the tree with
-descendents, i.e. cells that are further refined.
+descendants, i.e. cells that are further refined.
A triangulation contains forests for lines (each of which may have 2
children), quads (each with possibly four children), and hexes (each with no
@endcode
Since dereferencing iterators yields accessor objects, these calls are to
-member functions <code>Accesor::vertex()</code>,
+member functions <code>Accessor::vertex()</code>,
<code>Accessor::child()</code> etc. These in turn figure out the relevant data
from the various data structures that store this data. How this is actually
done and what data structures are used is not really of concern to authors of
* finite element programs, but appear there as well. These classes
* are all listed in the Classes and Namespaces views reachable from
* the menu bar at the top of this page, and are also grouped into
- * modules of their own (see the <a href="modules.html">Modules linke</a>
+ * modules of their own (see the <a href="modules.html">Modules link</a>
* at the top of this page).
*
* We provide the Doxygen tag file for those of you who would like to directly link the
* mesh refinement. Several classes already exist to support the most common
* geometries, e.g., CylinderManifold, or PolarManifold, which represent
* respectively the geometry obtained when describing your space in
- * cylindrical coordintes or in polar coordinates.
+ * cylindrical coordinates or in polar coordinates.
*
* <li> Integration: When using higher order finite element methods, it is
* often necessary to compute cell terms (like cell contributions to the
*
* Here, even starting with an initial, inappropriately chosen mesh retains
* our ability to adequately refine the mesh into one that will serve us
- * well. This example may be manifactured here, but it is relevant, for example
+ * well. This example may be manufactured here, but it is relevant, for example
* in the context of what GridGenerator::hyper_shell() produces in 3d
* (see the documentation of this function). It is also germane to the
* cases discussed in the @ref GlossDistorted "glossary entry on distorted cells".
* <h4>Dynamic block sparsity patterns</h4>
*
* The class BlockDynamicSparsityPattern implements an array of dynamic
- * sparsity patterns for contructing block matrices. See the documentation and
+ * sparsity patterns for constructing block matrices. See the documentation and
* step-22 for more information.
*
* @ingroup Matrices
*
* @brief A module discussing the use of parallelism on shared memory
* machines. See the detailed documentation and
- * @ref MTToC "Table of Contents" below the lenghty list of members
+ * @ref MTToC "Table of Contents" below the lengthy list of members
* of this module.
*
* @dealiiVideoLecture{39,40}
* should be run on a separate task by simply prefixing the call with a
* keyword (such as <code>new_task</code> here, with a similar keyword
* <code>new_thread</code> for threads). Prefixing a call would return a
- * handle for the task that we can use to wait for the tasks's completion and
+ * handle for the task that we can use to wait for the task's completion and
* that we may use to query the return value of the function called (unless it
* is void, as it is here).
*
* from one mesh to another.
*
* The namespaces MatrixCreator, MatrixTools, and VectorTools provide an
- * assortment of services, such as creating a Laplac matrix, projecting or
+ * assortment of services, such as creating a Laplace matrix, projecting or
* interpolating a function onto the present finite element space, etc. The
* difference to the functions in the DoFTools and FETools functions is that
* they work on vectors (i.e. members of a finite element function space on a
projects / dealii.git / commitdiff