From: Wolfgang Bangerth Date: Fri, 10 Feb 2023 18:01:54 +0000 (-0700) Subject: Standardize 2D/3D -> 2d/3d in documentation comments. X-Git-Tag: v9.5.0-rc1~560^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=00fb870cf192573cdf780ff29c077716aaba2d6c;p=dealii.git Standardize 2D/3D -> 2d/3d in documentation comments. --- diff --git a/examples/doxygen/step_3_mixed.cc b/examples/doxygen/step_3_mixed.cc index 0c87661973..2c6ee38356 100644 --- a/examples/doxygen/step_3_mixed.cc +++ b/examples/doxygen/step_3_mixed.cc @@ -41,14 +41,14 @@ * * Mixed meshes try to combine the best of both worlds by partitioning the * geometry in parts that can be easily meshed by hypercube cells - * (quadrilaterals in 2D, hexahedrons in 3D) and in parts that can not be meshed - * easily, requiring simplices (triangles in 2D, tetrahedrons in 3D). Since one + * (quadrilaterals in 2d, hexahedrons in 3d) and in parts that can not be meshed + * easily, requiring simplices (triangles in 2d, tetrahedrons in 3d). Since one * assumes that the region requiring simplices is rather small compared to the * rest of the domain where more efficient and accurate methods can be applied, * one can expect that the overall efficiency is hardly impacted by such an * approach. * - * One should note that in 3D, one also needs a transition region between + * One should note that in 3d, one also needs a transition region between * hypercube and simplex regions. Here, one can use wedges/prisms and/or * pyramids. * @@ -56,13 +56,13 @@ *

Working with mixed meshes

* * - * In the following, we concentrate, for the sake of simplicity, on 2D meshes: + * In the following, we concentrate, for the sake of simplicity, on 2d meshes: * they can only contain triangles and quadrilaterals. However, as detailed in - * the outlook, an extension of the presented approach to the 3D case is + * the outlook, an extension of the presented approach to the 3d case is * straightforward. * * - * The complexity of working with mixed meshes in 2D results from the fact + * The complexity of working with mixed meshes in 2d results from the fact * that it contains of two * types of geometrical objects: quadrilaterals and triangles. How to deal with * quadrilaterals, we have discussed in step-3: we selected an appropriate @@ -74,7 +74,7 @@ * For mixed meshes, we need multiple finite elements, quadrature rules, and * mapping objects (one set for triangles and one set for quadrilaterals) in the * same program. To ease the work with the multitude of objects (in particular - * in 3D, we need at least four of each), you can collect the objects and group + * in 3d, we need at least four of each), you can collect the objects and group * them together in hp::FECollection, hp::QCollection, and * hp::MappingCollection. * @@ -427,7 +427,7 @@ int main() *

Possibilities for extensions

* * In this tutorial, we presented how to use the deal.II simplex infrastructure - * to solve a simple Poisson problem on a mixed mesh in 2D. In this scope, we + * to solve a simple Poisson problem on a mixed mesh in 2d. In this scope, we * could only present a small section of the capabilities. In the following, we * point out further capabilities briefly. * @@ -441,9 +441,9 @@ int main() * cases. * * - *

3D meshes

+ *

3d meshes

* - * In 3D, meshes might also consist of wedges/prisms and pyramids. Therefore, + * In 3d, meshes might also consist of wedges/prisms and pyramids. Therefore, * the above introduced collections might consist of four components. * * For wedge/prism and pyramid cell types, following finite-element and diff --git a/examples/doxygen/step_3_simplex.cc b/examples/doxygen/step_3_simplex.cc index c695fe654c..7659821126 100644 --- a/examples/doxygen/step_3_simplex.cc +++ b/examples/doxygen/step_3_simplex.cc @@ -29,11 +29,11 @@ *

Motivation

* * Many freely available mesh-generation tools produce meshes that consist of - * simplices (triangles in 2D; tetrahedra in 3D). The reason for this is that + * simplices (triangles in 2d; tetrahedra in 3d). The reason for this is that * generating such kind of meshes for complex geometries is simpler than the * generation of hex-only meshes. This tutorial shows how to work on such kind * of meshes with the experimental simplex features in deal.II. For this - * purpose, we solve the Poisson problem from step-3 in 2D with a mesh only + * purpose, we solve the Poisson problem from step-3 in 2d with a mesh only * consisting of triangles. * * @@ -347,18 +347,18 @@ int main() *

Possibilities for extensions

* * In this tutorial, we presented how to use the deal.II simplex infrastructure - * to solve a simple Poisson problem on a simplex mesh in 2D. In this scope, we + * to solve a simple Poisson problem on a simplex mesh in 2d. In this scope, we * could only present a small section of the capabilities. In the following, we * point out further capabilities briefly. * * - *

3D meshes and codim-1 meshes in 3D

+ *

3d meshes and codim-1 meshes in 3d

* - * An extension to 3D is quite straightforward. Both FE_SimplexP and + * An extension to 3d is quite straightforward. Both FE_SimplexP and * QGaussSimplex are implemented in a dimensional-independent way so that simply * replacing everywhere dim=2 with dim=3 should work out of the box. * - * Furthermore, embedding of a 2D mesh consisting of triangles in 3D space is + * Furthermore, embedding of a 2d mesh consisting of triangles in 3d space is * possible. * * @@ -367,7 +367,7 @@ int main() * In step-3, we considered meshes only consisting of quadrilaterals. In this * tutorial, we took a look at the case that the mesh only consists of * triangles. In the general case (also known as mixed mesh), the mesh consists - * of both cell types. In 3D, meshes might even consist of more cell types, like + * of both cell types. In 3d, meshes might even consist of more cell types, like * wedges/prisms and pyramids. We consider such meshes in the tutorial * step-3mixed. * diff --git a/include/deal.II/base/bounding_box.h b/include/deal.II/base/bounding_box.h index 9c2ba06c7a..74643162c5 100644 --- a/include/deal.II/base/bounding_box.h +++ b/include/deal.II/base/bounding_box.h @@ -81,15 +81,15 @@ enum class NeighborType * direction $k$. * * Geometrically, a bounding box is thus: - * - 1D: a segment (represented by its vertices in the proper order) - * - 2D: a rectangle (represented by the vertices V at bottom left, top right) + * - 1d: a segment (represented by its vertices in the proper order) + * - 2d: a rectangle (represented by the vertices V at bottom left, top right) * @code * .--------V * | | * V--------. * @endcode * - * - 3D: a cuboid (in which case the two vertices V follow the convention and + * - 3d: a cuboid (in which case the two vertices V follow the convention and * are not owned by the same face) * @code * .------V @@ -115,10 +115,10 @@ enum class NeighborType * * Taking the cross section of a BoundingBox orthogonal to a given * direction gives a box in one dimension lower: BoundingBox. - * In 3D, the 2 coordinates of the cross section of BoundingBox<3> can be + * In 3d, the 2 coordinates of the cross section of BoundingBox<3> can be * ordered in 2 different ways. That is, if we take the cross section orthogonal - * to the y direction we could either order a 3D-coordinate into a - * 2D-coordinate as $(x,z)$ or as $(z,x)$. This class uses the second + * to the y direction we could either order a 3d-coordinate into a + * 2d-coordinate as $(x,z)$ or as $(z,x)$. This class uses the second * convention, corresponding to the coordinates being ordered cyclicly * $x \rightarrow y \rightarrow z \rightarrow x \rightarrow ... $ * To be precise, if we take a cross section: @@ -287,7 +287,7 @@ public: * Returns the cross section of the box orthogonal to @p direction. * This is a box in one dimension lower. * - * @note Calling this method in 1D will result in an exception since + * @note Calling this method in 1d will result in an exception since * BoundingBox<0> is not implemented. */ BoundingBox @@ -375,16 +375,16 @@ namespace internal * * The convention is the following: Starting from the locked coordinate we * store the lower dimensional coordinates consecutively and wrap around - * when going over the dimension. This relationship is, in 2D, + * when going over the dimension. This relationship is, in 2d, * - * | locked in 2D | 1D coordinate | 2D coordinate | + * | locked in 2D | 1d coordinate | 2d coordinate | * |:------------:|:-------------:|:-------------:| * | x0 | (a) | (x0, a) | * | x1 | (a) | (a , x1) | * - * and, in 3D, + * and, in 3d, * - * | locked in 3D | 2D coordinates | 3D coordinates | + * | locked in 3D | 2d coordinates | 3d coordinates | * |:-------------|:--------------:|:--------------:| * | x0 | (a, b) | (x0, a, b) | * | x1 | (a, b) | ( b, x1, a) | diff --git a/include/deal.II/base/convergence_table.h b/include/deal.II/base/convergence_table.h index a6e2846565..77b3b0884a 100644 --- a/include/deal.II/base/convergence_table.h +++ b/include/deal.II/base/convergence_table.h @@ -100,8 +100,8 @@ public: * reference column vs. the value column is based upon, it needs to be * passed as last argument to this method. The default dimension for the * reference column is 2, which is appropriate for the number of cells - * in 2D. If you work in 3D, set the number to 3. If the reference column is - * $1/h$, remember to set the dimension to 1 also when working in 3D to get + * in 2d. If you work in 3d, set the number to 3. If the reference column is + * $1/h$, remember to set the dimension to 1 also when working in 3d to get * correct rates. * * The new rate column and the data column will be merged to a supercolumn. @@ -121,7 +121,7 @@ public: * * This is useful, for example, if we use as reference key the number of * degrees of freedom or better, the number of cells. Assuming that the - * error is proportional to $ C (1/\sqrt{k})^r $ in 2D, then this method + * error is proportional to $ C (1/\sqrt{k})^r $ in 2d, then this method * will produce the rate $r$ as a result. For general dimension, as * described by the last parameter of this function, the formula needs to be * $ C (1/\sqrt[dim]{k})^r $. diff --git a/include/deal.II/base/data_out_base.h b/include/deal.II/base/data_out_base.h index da5e5bb3af..7624876bec 100644 --- a/include/deal.II/base/data_out_base.h +++ b/include/deal.II/base/data_out_base.h @@ -85,7 +85,7 @@ class XDMFEntry; * * Inside each patch, the data is organized in the usual lexicographical * order, x running fastest, then y and z. Nodes are - * stored in this order and cells as well. Each cell in 3D is stored such that + * stored in this order and cells as well. Each cell in 3d is stored such that * the front face is in the xz-plane. In order to enhance * intelligibility of this concept, the following two sections are kept from a * previous version of this documentation. @@ -1514,7 +1514,7 @@ namespace DataOutBase private: /** - * Empty class to provide comparison function for Map3DPoint. + * Empty class to provide comparison function for Map3dPoint. */ struct Point3Comp { diff --git a/include/deal.II/base/flow_function.h b/include/deal.II/base/flow_function.h index 6de3c60247..ea1dedf4e6 100644 --- a/include/deal.II/base/flow_function.h +++ b/include/deal.II/base/flow_function.h @@ -183,7 +183,7 @@ namespace Functions * Artificial divergence free function with homogeneous boundary conditions * on the cube [-1,1]dim. * - * The function in 2D is + * The function in 2d is * @f[ * \left(\begin{array}{c}u\\v\\p\end{array}\right) * \left(\begin{array}{c}\cos^2x \sin y\cos y\\-\sin x\cos x\cos^2y\\ @@ -290,7 +290,7 @@ namespace Functions }; /** - * Flow solution in 2D by Kovasznay (1947). + * Flow solution in 2d by Kovasznay (1947). * * This function is valid on the half plane right of the line x=1/2. * diff --git a/include/deal.II/base/function_lib.h b/include/deal.II/base/function_lib.h index e2205ab576..e1f37ca815 100644 --- a/include/deal.II/base/function_lib.h +++ b/include/deal.II/base/function_lib.h @@ -383,7 +383,7 @@ namespace Functions /** * A function that solves the Laplace equation (with specific * boundary values but zero right hand side) and that has a - * singularity at the center of the L-shaped domain in 2D (i.e., + * singularity at the center of the L-shaped domain in 2d (i.e., * at the location of the re-entrant corner of this non-convex * domain). * @@ -449,7 +449,7 @@ namespace Functions /** - * Gradient of the harmonic singularity on the L-shaped domain in 2D. + * Gradient of the harmonic singularity on the L-shaped domain in 2d. * * The gradient of LSingularityFunction, which is a vector valued function * with vanishing curl and divergence. @@ -500,7 +500,7 @@ namespace Functions /** - * Singularity on the slit domain in 2D and 3D. + * Singularity on the slit domain in 2d and 3d. * * @ingroup functions */ @@ -546,7 +546,7 @@ namespace Functions /** - * Singularity on the slit domain with one Neumann boundary in 2D. + * Singularity on the slit domain with one Neumann boundary in 2d. * * @ingroup functions */ diff --git a/include/deal.II/base/function_restriction.h b/include/deal.II/base/function_restriction.h index 0714c83a1e..00242e48d3 100644 --- a/include/deal.II/base/function_restriction.h +++ b/include/deal.II/base/function_restriction.h @@ -42,7 +42,7 @@ namespace Functions * * The `dim`-dimensional coordinates on the restriction are ordered starting * from the restricted (`dim + 1`)-coordinate. In particular, this means that - * if the $y$-coordinate is locked to $Y$ in 3D, the coordinates are ordered + * if the $y$-coordinate is locked to $Y$ in 3d, the coordinates are ordered * as $(z, x)$ on the restriction: * $g = g(z, x) = f(x, Y, z)$. * This is the same convention as in BoundingBox::cross_section. diff --git a/include/deal.II/base/function_signed_distance.h b/include/deal.II/base/function_signed_distance.h index 45daae96d4..06274083e9 100644 --- a/include/deal.II/base/function_signed_distance.h +++ b/include/deal.II/base/function_signed_distance.h @@ -202,7 +202,7 @@ namespace Functions compute_analyical_normal_vector_on_ellipse(const Point &point) const; /** - * Compute the signed distance to a 2D ellipsoid i.e. ellipse. + * Compute the signed distance to a 2d ellipsoid i.e. ellipse. */ double compute_signed_distance_ellipse(const Point &point) const; diff --git a/include/deal.II/base/geometric_utilities.h b/include/deal.II/base/geometric_utilities.h index 5dcc763d07..606c233415 100644 --- a/include/deal.II/base/geometric_utilities.h +++ b/include/deal.II/base/geometric_utilities.h @@ -43,9 +43,9 @@ namespace GeometricUtilities /** * Return spherical coordinates of a Cartesian point @p point. * The returned array is filled with radius, azimuth angle $\in [0,2 \pi)$ - * and polar/inclination angle $ \in [0,\pi]$ (omitted in 2D). + * and polar/inclination angle $ \in [0,\pi]$ (omitted in 2d). * - * In 3D the transformation is given by + * In 3d the transformation is given by * @f{align*}{ * r &= \sqrt{x^2+y^2+z^2} \\ * \theta &= {\rm atan}(y/x) \\ @@ -62,9 +62,9 @@ namespace GeometricUtilities * Return the Cartesian coordinates of a spherical point defined by @p scoord * which is filled with radius $r \in [0,\infty)$, azimuth angle * $\theta \in [0,2 \pi)$ and polar/inclination angle $\phi \in [0,\pi]$ - * (omitted in 2D). + * (omitted in 2d). * - * In 3D the transformation is given by + * In 3d the transformation is given by * @f{align*}{ * x &= r\, \cos(\theta) \, \sin(\phi) \\ * y &= r\, \sin(\theta) \, \sin(\phi) \\ diff --git a/include/deal.II/base/geometry_info.h b/include/deal.II/base/geometry_info.h index 71c57223f9..9f8832b8d4 100644 --- a/include/deal.II/base/geometry_info.h +++ b/include/deal.II/base/geometry_info.h @@ -2121,7 +2121,7 @@ struct GeometryInfo /** * This field stores for each vertex to which faces it belongs. In any given * dimension, the number of faces is equal to the dimension. The first index - * in this 2D-array runs over all vertices, the second index over @p dim + * in this 2d-array runs over all vertices, the second index over @p dim * faces to which the vertex belongs. * * The order of the faces for each vertex is such that the first listed face @@ -2203,7 +2203,7 @@ struct GeometryInfo * This field stores which child cells are adjacent to a certain face of the * mother cell. * - * For example, in 2D the layout of a cell is as follows: + * For example, in 2d the layout of a cell is as follows: * @verbatim * . 3 * . 2-->--3 @@ -2323,7 +2323,7 @@ struct GeometryInfo * false and false, respectively. this combination * describes a face in standard orientation. * - * This function is only implemented in 3D. + * This function is only implemented in 3d. */ static unsigned int standard_to_real_face_vertex(const unsigned int vertex, @@ -2338,7 +2338,7 @@ struct GeometryInfo * false and false, respectively. this combination * describes a face in standard orientation. * - * This function is only implemented in 3D. + * This function is only implemented in 3d. */ static unsigned int real_to_standard_face_vertex(const unsigned int vertex, @@ -2353,7 +2353,7 @@ struct GeometryInfo * false and false, respectively. this combination * describes a face in standard orientation. * - * This function is only implemented in 3D. + * This function is only implemented in 3d. */ static unsigned int standard_to_real_face_line(const unsigned int line, @@ -2407,7 +2407,7 @@ struct GeometryInfo * false, respectively. this combination describes a face in * standard orientation. * - * This function is only implemented in 3D. + * This function is only implemented in 3d. */ static unsigned int real_to_standard_face_line(const unsigned int line, diff --git a/include/deal.II/base/polynomial.h b/include/deal.II/base/polynomial.h index 997719d3ae..26caf22d99 100644 --- a/include/deal.II/base/polynomial.h +++ b/include/deal.II/base/polynomial.h @@ -43,7 +43,7 @@ DEAL_II_NAMESPACE_OPEN namespace Polynomials { /** - * Base class for all 1D polynomials. A polynomial is represented in this + * Base class for all 1d polynomials. A polynomial is represented in this * class by its coefficients, which are set through the constructor or by * derived classes. * diff --git a/include/deal.II/base/polynomial_space.h b/include/deal.II/base/polynomial_space.h index e11ddcf9c2..11795a9494 100644 --- a/include/deal.II/base/polynomial_space.h +++ b/include/deal.II/base/polynomial_space.h @@ -54,8 +54,8 @@ DEAL_II_NAMESPACE_OPEN * x0, x1, x2,..., xn, we * get * - *
1D
x0, x1,...,xn - *
2D:
x0y0, + *
1d
x0, x1,...,xn + *
2d:
x0y0, * x1y0,..., xny0, *
* x0y1, x1y1,..., @@ -67,7 +67,7 @@ DEAL_II_NAMESPACE_OPEN *
* x0yn-1, x1yn-1, *
- * x0yn
3D:
+ * x0yn
3d:
* x0y0z0,..., * xny0z0, *
diff --git a/include/deal.II/base/polynomials_abf.h b/include/deal.II/base/polynomials_abf.h index 8a55c0215a..fe609e5705 100644 --- a/include/deal.II/base/polynomials_abf.h +++ b/include/deal.II/base/polynomials_abf.h @@ -45,7 +45,7 @@ DEAL_II_NAMESPACE_OPEN * polynomial order of each component must be two orders higher in the * corresponding direction, yielding the polynomial spaces * (Qk+2,k, Qk,k+2) and (Qk+2,k,k, - * Qk,k+2,k, Qk,k,k+2) in 2D and 3D, resp. + * Qk,k+2,k, Qk,k,k+2) in 2d and 3d, resp. * * @ingroup Polynomials */ diff --git a/include/deal.II/base/polynomials_adini.h b/include/deal.II/base/polynomials_adini.h index 7d2fd0318f..c64672ceb1 100644 --- a/include/deal.II/base/polynomials_adini.h +++ b/include/deal.II/base/polynomials_adini.h @@ -35,7 +35,7 @@ DEAL_II_NAMESPACE_OPEN * The basis of the space is chosen to match the node functionals of the Adini * element. * - * @todo This polynomial space is implemented in 2D only and does not compute + * @todo This polynomial space is implemented in 2d only and does not compute * derivatives of order 3 or higher. * * @ingroup Polynomials diff --git a/include/deal.II/base/polynomials_barycentric.h b/include/deal.II/base/polynomials_barycentric.h index 780e4261c4..82eaf0d9cb 100644 --- a/include/deal.II/base/polynomials_barycentric.h +++ b/include/deal.II/base/polynomials_barycentric.h @@ -40,22 +40,22 @@ DEAL_II_NAMESPACE_OPEN * @f] * * where each value $c_i$ is the relative weight of each vertex (so the - * centroid is, in 2D, where each $c_i = 1/3$). Since we only consider convex + * centroid is, in 2d, where each $c_i = 1/3$). Since we only consider convex * combinations we can rewrite this equation as * * @f[ * (x, y) = (1 - c_1 - c_2) (x_0, y_0) + c_1 (x_1, y_1) + c_2 (x_2, y_2). * @f] * - * This results in three polynomials that are equivalent to $P^1$ in 2D. More + * This results in three polynomials that are equivalent to $P^1$ in 2d. More * exactly, this class implements a polynomial space defined with the basis, - * in 2D, of + * in 2d, of * @f{align*}{ * t_0(x, y) &= 1 - x - y \\ * t_1(x, y) &= x \\ * t_2(x, y) &= y * @f} - * and, in 3D, + * and, in 3d, * @f{align*}{ * t_0(x, y) &= 1 - x - y - z \\ * t_1(x, y) &= x \\ diff --git a/include/deal.II/base/polynomials_bdm.h b/include/deal.II/base/polynomials_bdm.h index 8e6e296d2f..deca6ec19f 100644 --- a/include/deal.II/base/polynomials_bdm.h +++ b/include/deal.II/base/polynomials_bdm.h @@ -46,7 +46,7 @@ DEAL_II_NAMESPACE_OPEN * More details * of two and three dimensional $BDM_{k}$ elements are given below. *
- *
In 2D: + *
In 2d: *
$ BDM_{k} = \{\mathbf{q} | \mathbf{q} = p_{k} (x,y) + * r \; \text{curl} (x^{k+1}y) + s \; * \text{curl} (xy^{k+1}), p_{k} \in (P_{k})^{2} \}$. @@ -70,7 +70,7 @@ DEAL_II_NAMESPACE_OPEN * $(k+1)(k+2)+2$, with $k+1$ unknowns per * edge and $k(k-1)$ interior unknowns. * - *
In 3D: + *
In 3d: *
$ BDM_{k} = * \{\mathbf{q} | \mathbf{q} = p_{k} (x,y,z) * + \sum_{i=0}^{k} ( @@ -82,7 +82,7 @@ DEAL_II_NAMESPACE_OPEN * \begin{pmatrix}0\\zx^{i+1}y^{k-i}\\0\end{pmatrix}) * , p_{k} \in (P_{k})^{3} \}$. * - * Note: the 3D description of $BDM_{k}$ is not unique. See Mixed and + * Note: the 3d description of $BDM_{k}$ is not unique. See Mixed and * Hybrid Finite Element Methods page 122 for an alternative definition. * * The dimension of the $BDM_{k}$ space is @@ -157,8 +157,8 @@ private: const PolynomialSpace polynomial_space; /** - * Storage for monomials. In 2D, this is just the polynomial of order - * k. In 3D, we need all polynomials from degree zero to k. + * Storage for monomials. In 2d, this is just the polynomial of order + * k. In 3d, we need all polynomials from degree zero to k. */ std::vector> monomials; diff --git a/include/deal.II/base/polynomials_bernardi_raugel.h b/include/deal.II/base/polynomials_bernardi_raugel.h index d753fec84c..dec6bc62d6 100644 --- a/include/deal.II/base/polynomials_bernardi_raugel.h +++ b/include/deal.II/base/polynomials_bernardi_raugel.h @@ -51,7 +51,7 @@ DEAL_II_NAMESPACE_OPEN * the positive axis direction and not necessarily normal to the element for * consistent orientation across edges. *
- *
2D bubble functions (in order) + *
2d bubble functions (in order) *
$x=0$ edge: $\mathbf{p}_1 = \mathbf{n}_1 (1-x)(y)(1-y)$ * * $x=1$ edge: $\mathbf{p}_2 = \mathbf{n}_2 (x)(y)(1-y)$ @@ -60,7 +60,7 @@ DEAL_II_NAMESPACE_OPEN * * $y=1$ edge: $\mathbf{p}_4 = \mathbf{n}_4 (x)(1-x)(y)$ * - *
3D bubble functions (in order) + *
3d bubble functions (in order) *
$x=0$ edge: $\mathbf{p}_1 = \mathbf{n}_1 (1-x)(y)(1-y)(z)(1-z)$ * * $x=1$ edge: $\mathbf{p}_2 = \mathbf{n}_2 (x)(y)(1-y)(z)(1-z)$ diff --git a/include/deal.II/base/polynomials_nedelec.h b/include/deal.II/base/polynomials_nedelec.h index 4ee436f49a..180293ccf7 100644 --- a/include/deal.II/base/polynomials_nedelec.h +++ b/include/deal.II/base/polynomials_nedelec.h @@ -43,7 +43,7 @@ DEAL_II_NAMESPACE_OPEN * corresponding two directions, yielding the polynomial spaces * (Qk,k+1, Qk+1,k) and * (Qk,k+1,k+1, Qk+1,k,k+1, - * Qk+1,k+1,k) in 2D and 3D, resp. + * Qk+1,k+1,k) in 2d and 3d, resp. * * @ingroup Polynomials */ diff --git a/include/deal.II/base/polynomials_piecewise.h b/include/deal.II/base/polynomials_piecewise.h index 819979c78d..85fa76ea3e 100644 --- a/include/deal.II/base/polynomials_piecewise.h +++ b/include/deal.II/base/polynomials_piecewise.h @@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN namespace Polynomials { /** - * Definition of piecewise 1D polynomials for the unit interval. This space + * Definition of piecewise 1d polynomials for the unit interval. This space * allows the description of interpolating polynomials on parts of the unit * interval, similarly to the definition of finite element basis functions * on subdivided elements. The primary purpose of this class is to diff --git a/include/deal.II/base/polynomials_raviart_thomas.h b/include/deal.II/base/polynomials_raviart_thomas.h index 77aed7aca3..2c4da5311b 100644 --- a/include/deal.II/base/polynomials_raviart_thomas.h +++ b/include/deal.II/base/polynomials_raviart_thomas.h @@ -42,7 +42,7 @@ DEAL_II_NAMESPACE_OPEN * polynomial order of each component must be one order higher in the * corresponding direction, yielding the polynomial spaces * (Qk+1,k, Qk,k+1) and (Qk+1,k,k, - * Qk,k+1,k, Qk,k,k+1) in 2D and 3D, resp. + * Qk,k+1,k, Qk,k,k+1) in 2d and 3d, resp. * * @ingroup Polynomials */ diff --git a/include/deal.II/base/polynomials_rt_bubbles.h b/include/deal.II/base/polynomials_rt_bubbles.h index c41113a4af..f1f64dc55b 100644 --- a/include/deal.II/base/polynomials_rt_bubbles.h +++ b/include/deal.II/base/polynomials_rt_bubbles.h @@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN * This space is of the form Vk = RTk-1 + * Bk, where Bk is defined as follows: *
- *
In 2D:
+ *
In 2d:
*
* @f{align*}{ * B_k^1(E) = \text{span}\left\{x^{a_1-1} y^{a_2}\begin{pmatrix} (a_2+1) x \\ @@ -51,7 +51,7 @@ DEAL_II_NAMESPACE_OPEN * @f} *
* - *
In 3D:
+ *
In 3d:
*
* @f{align*}{ * B_k^1(E) = \text{span}\left\{x^{a_1-1} y^{a_2} z^{a_3}\begin{pmatrix} @@ -82,7 +82,7 @@ DEAL_II_NAMESPACE_OPEN * * * Left - $2d,\,k=3$, - * right - $3D,\,k=2$. + * right - $3d,\,k=2$. * * @ingroup Polynomials */ diff --git a/include/deal.II/base/process_grid.h b/include/deal.II/base/process_grid.h index 1c1c07f890..62af8f341d 100644 --- a/include/deal.II/base/process_grid.h +++ b/include/deal.II/base/process_grid.h @@ -84,7 +84,7 @@ namespace Utilities * The maximum number of MPI cores one can utilize is * $\min\{\frac{M}{MB}\frac{N}{NB}, Np\}$, where $M,N$ are the matrix * dimension and $MB,NB$ are the block sizes and $Np$ is the number of - * processes in the @p mpi_communicator. This function then creates a 2D processor grid + * processes in the @p mpi_communicator. This function then creates a 2d processor grid * assuming the ratio between number of process row $p$ and columns $q$ to * be equal the ratio between matrix dimensions $M$ and $N$. * @@ -206,7 +206,7 @@ namespace Utilities int this_process_column; /** - * A flag which is true for processes within the 2D process grid. + * A flag which is true for processes within the 2d process grid. */ bool mpi_process_is_active; }; diff --git a/include/deal.II/base/qprojector.h b/include/deal.II/base/qprojector.h index 80d125d7cc..381f8aa0fa 100644 --- a/include/deal.II/base/qprojector.h +++ b/include/deal.II/base/qprojector.h @@ -113,7 +113,7 @@ public: * Compute the quadrature points on the cell if the given quadrature formula * is used on face face_no, subface number subface_no * corresponding to RefineCase::Type ref_case. The last argument is - * only used in 3D. + * only used in 3d. * * @note Only the points are transformed. The quadrature weights are the * same as those of the original rule. @@ -131,13 +131,13 @@ public: * Compute the cell quadrature formula corresponding to using * quadrature on subface subface_no of face * face_no with RefinementCase ref_case. The last - * argument is only used in 3D. + * argument is only used in 3d. * * @note Only the points are transformed. The quadrature weights are the * same as those of the original rule. * * @note This function is deprecated since it makes an implicit assumption - * that the cell is a line (1D), a quad (2D), or a hex (3D). Use the other + * that the cell is a line (1D), a quad (2d), or a hex (3d). Use the other * version of this function that takes the reference cell type instead. */ static Quadrature @@ -161,7 +161,7 @@ public: * to a single face and use it as a quadrature on this face, as is done in * FEFaceValues. * - * @note In 3D, this function produces eight sets of quadrature points for + * @note In 3d, this function produces eight sets of quadrature points for * each face, in order to cope possibly different orientations of the mesh. */ static Quadrature diff --git a/include/deal.II/base/quadrature_lib.h b/include/deal.II/base/quadrature_lib.h index 0cfe1fa4ee..ea4d6bffea 100644 --- a/include/deal.II/base/quadrature_lib.h +++ b/include/deal.II/base/quadrature_lib.h @@ -812,16 +812,16 @@ public: /** * Integration rule for simplex entities. * - * Users specify a number `n_points_1D` as an indication of what polynomial + * Users specify a number `n_points_1d` as an indication of what polynomial * degree to be integrated exactly, similarly to the number of points in a * QGauss quadrature object, even though the present quadrature formula is not - * a tensor product. The given value is translated for n_points_1D=1,2,3,4 to - * following number of quadrature points for 2D and 3D: - * - 2D: 1, 4, 7, 15 - * - 3D: 1, 6, 14, 35 + * a tensor product. The given value is translated for n_points_1d=1,2,3,4 to + * following number of quadrature points for 2d and 3d: + * - 2d: 1, 4, 7, 15 + * - 3d: 1, 6, 14, 35 * - * For 1D, the quadrature rule degenerates to a - * `dealii::QGauss<1>(n_points_1D)`. + * For 1d, the quadrature rule degenerates to a + * `dealii::QGauss<1>(n_points_1d)`. * * @note The quadrature rules implemented by this class come from a variety of * sources, but all of them have positive quadrature weights. @@ -838,8 +838,8 @@ class QGaussSimplex : public QSimplex { public: /** - * Constructor taking the number of quadrature points in 1D direction - * @p n_points_1D. + * Constructor taking the number of quadrature points in 1d direction + * @p n_points_1d. */ explicit QGaussSimplex(const unsigned int n_points_1D); }; @@ -847,29 +847,29 @@ public: /** * Witherden-Vincent rules for simplex entities. * - * Like QGauss, users should specify a number `n_points_1D` as an indication + * Like QGauss, users should specify a number `n_points_1d` as an indication * of what polynomial degree to be integrated exactly (e.g., for $n$ points, * the rule can integrate polynomials of degree $2 n - 1$ exactly). * Additionally, since these rules were derived for simplices, there are * also even-ordered rules (i.e., they integrate polynomials of degree $2 n$) - * available which do not have analogous 1D rules. + * available which do not have analogous 1d rules. * - * The given value for n_points_1D = 1, 2, 3, 4, 5, 6, 7 (where the last two are - * only implemented in 2D) results in the following number of quadrature points - * in 2D and 3D: - * - 2D: odd (default): 1, 6, 7, 15, 19, 28, 37 - * - 2D: even: 3, 6, 12, 16, 25, 33, 42 - * - 3D: odd (default): 1, 8, 14, 35, 59 - * - 3D: even: 4, 14, 24, 46, 81 + * The given value for n_points_1d = 1, 2, 3, 4, 5, 6, 7 (where the last two are + * only implemented in 2d) results in the following number of quadrature points + * in 2d and 3d: + * - 2d: odd (default): 1, 6, 7, 15, 19, 28, 37 + * - 2d: even: 3, 6, 12, 16, 25, 33, 42 + * - 3d: odd (default): 1, 8, 14, 35, 59 + * - 3d: even: 4, 14, 24, 46, 81 * - * For 1D, the quadrature rule degenerates to a - * `dealii::QGauss<1>(n_points_1D)` and @p use_odd_order is ignored. + * For 1d, the quadrature rule degenerates to a + * `dealii::QGauss<1>(n_points_1d)` and @p use_odd_order is ignored. * * These rules match the ones listed for Witherden-Vincent in the quadpy * @cite quadpy library and were first described in * @cite witherden2015identification. * - * @note Some rules (2D 2 odd and 3D 2 even) do not yet exist and instead a + * @note Some rules (2d 2 odd and 3d 2 even) do not yet exist and instead a * higher-order rule is used in their place. * * @relates simplex @@ -879,8 +879,8 @@ class QWitherdenVincentSimplex : public QSimplex { public: /** - * Constructor taking the equivalent number of quadrature points in 1D - * @p n_points_1D and boolean indicating whether the rule should be order + * Constructor taking the equivalent number of quadrature points in 1d + * @p n_points_1d and boolean indicating whether the rule should be order * $2 n - 1$ or $2 n$: see the general documentation of this class for more * information. */ @@ -911,7 +911,7 @@ class QGaussWedge : public Quadrature { public: /** - * Users specify a number `n_points_1D` as an indication of what polynomial + * Users specify a number `n_points_1d` as an indication of what polynomial * degree to be integrated exactly. For details, see the comments of * QGaussSimplex. */ @@ -926,7 +926,7 @@ class QGaussPyramid : public Quadrature { public: /** - * Users specify a number `n_points_1D` as an indication of what polynomial + * Users specify a number `n_points_1d` as an indication of what polynomial * degree to be integrated exactly. For details, see the comments of * QGaussSimplex. */ diff --git a/include/deal.II/cgal/additional_data.h b/include/deal.II/cgal/additional_data.h index 721c21ae68..cd33f931bf 100644 --- a/include/deal.II/cgal/additional_data.h +++ b/include/deal.II/cgal/additional_data.h @@ -157,7 +157,7 @@ namespace CGALWrappers /** * Specialization of the above struct when the object to be constructed is a - * 2D triangulation embedded in the 3D space, i.e. a Triangulation<2,3>. + * 2d triangulation embedded in the 3d space, i.e. a Triangulation<2,3>. * Only three parameters are accepted: * - `angular_bound` is a lower bound in degrees for the angles of mesh * facets. diff --git a/include/deal.II/cgal/surface_mesh.h b/include/deal.II/cgal/surface_mesh.h index e2042f2669..76ed1c713c 100644 --- a/include/deal.II/cgal/surface_mesh.h +++ b/include/deal.II/cgal/surface_mesh.h @@ -73,11 +73,11 @@ namespace CGALWrappers * Convert a deal.II triangulation to a CGAL::Surface_mesh. The output depends * on the intrinsic dimension of the input deal.II triangulation. * - * In 2D, i.e. with a + * In 2d, i.e. with a * Triangulation<2> or a Triangulation<2,3>, the output is the * CGAL::Surface_mesh describing the whole triangulation. * - * In 3D, the boundary the of the deal.II Triangulation is converted to + * In 3d, the boundary the of the deal.II Triangulation is converted to * a CGAL::Surface_mesh by looping over all the boundary faces. * * @param[in] triangulation The input deal.II triangulation. diff --git a/include/deal.II/cgal/utilities.h b/include/deal.II/cgal/utilities.h index ecacba1e5d..e8698c3172 100644 --- a/include/deal.II/cgal/utilities.h +++ b/include/deal.II/cgal/utilities.h @@ -149,7 +149,7 @@ namespace CGALWrappers * (https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#title14): * * > Given a closed triangulated surface mesh, each connected component splits - * > the 3D space into two subspaces. The vertex sequence of each face of a + * > the 3d space into two subspaces. The vertex sequence of each face of a * > component is seen either clockwise or counterclockwise from these two * > subspaces. The subspace that sees the sequence clockwise (resp. * > counterclockwise) is on the negative (resp. positive) side of the diff --git a/include/deal.II/distributed/fully_distributed_tria.h b/include/deal.II/distributed/fully_distributed_tria.h index 20f7de6238..7339de6b52 100644 --- a/include/deal.II/distributed/fully_distributed_tria.h +++ b/include/deal.II/distributed/fully_distributed_tria.h @@ -94,7 +94,7 @@ namespace parallel * been constructed, the triangulation `tria` can be created by calling * `tria.create_triangulation(construction_data);`. * - * @note This triangulation supports: 1D/2D/3D, hanging nodes, + * @note This triangulation supports: 1D/2d/3d, hanging nodes, * geometric multigrid, and periodicity. * * @note You can create a triangulation with hanging nodes and multigrid diff --git a/include/deal.II/dofs/dof_accessor.h b/include/deal.II/dofs/dof_accessor.h index 3df68c0adb..1f68bccfec 100644 --- a/include/deal.II/dofs/dof_accessor.h +++ b/include/deal.II/dofs/dof_accessor.h @@ -1512,7 +1512,7 @@ public: * Return an iterator to the @p ith face of this cell. * * This function returns a DoFAccessor with structdim == 0 in - * 1D, a DoFAccessor::line in 2D, and a DoFAccessor::quad in 3d. + * 1d, a DoFAccessor::line in 2d, and a DoFAccessor::quad in 3d. */ face_iterator face(const unsigned int i) const; diff --git a/include/deal.II/dofs/dof_accessor.templates.h b/include/deal.II/dofs/dof_accessor.templates.h index 10931b3ad1..51ac5fd2fb 100644 --- a/include/deal.II/dofs/dof_accessor.templates.h +++ b/include/deal.II/dofs/dof_accessor.templates.h @@ -254,7 +254,7 @@ namespace internal * extract some indices without having to allocate memory. We do this by * setting a boost small_vector with 27 elements on the stack, and only * allocate when we exceed 27. The number 27 is heuristic and allows up - * to quadratic shape functions on scalar problems in 3D, or linear + * to quadratic shape functions on scalar problems in 3d, or linear * shape functions on systems (elasticity). */ using dof_index_vector_type = diff --git a/include/deal.II/dofs/dof_faces.h b/include/deal.II/dofs/dof_faces.h index 3fd7646af0..62031a7795 100644 --- a/include/deal.II/dofs/dof_faces.h +++ b/include/deal.II/dofs/dof_faces.h @@ -44,9 +44,9 @@ namespace internal * These classes are similar to the DoFLevel classes. We here store * information that is associated with faces, rather than cells, as this * information is independent of the hierarchical structure of cells, - * which are organized in levels. In 2D we store information on degrees of - * freedom located on lines whereas in 3D we store information on degrees - * of freedom located on quads and lines. In 1D we do nothing, as the + * which are organized in levels. In 2d we store information on degrees of + * freedom located on lines whereas in 3d we store information on degrees + * of freedom located on quads and lines. In 1d we do nothing, as the * faces of lines are vertices which are treated separately. * * Apart from the DoFObjects object containing the data to store (degree @@ -76,7 +76,7 @@ namespace internal }; /** - * Store the indices of degrees of freedom on faces in 1D. As these would + * Store the indices of degrees of freedom on faces in 1d. As these would * be vertices, which are treated separately, don't do anything. */ template <> @@ -102,7 +102,7 @@ namespace internal }; /** - * Store the indices of degrees of freedom on faces in 2D, which are + * Store the indices of degrees of freedom on faces in 2d, which are * lines. */ template <> @@ -132,7 +132,7 @@ namespace internal }; /** - * Store the indices of degrees of freedom on faces in 3D, which are + * Store the indices of degrees of freedom on faces in 3d, which are * quads, additionally also on lines. */ template <> diff --git a/include/deal.II/dofs/dof_handler.h b/include/deal.II/dofs/dof_handler.h index 404d277dca..d7ef70ebac 100644 --- a/include/deal.II/dofs/dof_handler.h +++ b/include/deal.II/dofs/dof_handler.h @@ -1538,7 +1538,7 @@ private: mg_number_cache; /** - * Indices of degree of freedom of each d+1 geometric object (3D: vertex, + * Indices of degree of freedom of each d+1 geometric object (3d: vertex, * line, quad, hex) for all relevant active finite elements. Identification * of the appropriate position is done via object_dof_ptr (CRS scheme). */ diff --git a/include/deal.II/dofs/dof_levels.h b/include/deal.II/dofs/dof_levels.h index e179c73c95..706661b80a 100644 --- a/include/deal.II/dofs/dof_levels.h +++ b/include/deal.II/dofs/dof_levels.h @@ -44,7 +44,7 @@ namespace internal * variables of the dealii::DoFHandler class. * * The indices of degrees of freedom located on lower dimensional objects, - * i.e. on lines for 2D and on quads and lines for 3D are treated + * i.e. on lines for 2d and on quads and lines for 3d are treated * similarly than that on cells. However, these geometrical objects, which * are called faces as a generalization, are not organised in a * hierarchical structure of levels. Therefore, the degrees of freedom diff --git a/include/deal.II/dofs/dof_renumbering.h b/include/deal.II/dofs/dof_renumbering.h index 78ac0600a8..0ae8e20e70 100644 --- a/include/deal.II/dofs/dof_renumbering.h +++ b/include/deal.II/dofs/dof_renumbering.h @@ -1240,7 +1240,7 @@ namespace DoFRenumbering * The primary use of this ordering is that it enables one to interpret a * vector of FE coefficients as a vector of tensors. For example, suppose `X` * is a vector containing coordinates (i.e., the sort of vector one would use - * with MappingFEField) and `U` is a vector containing velocities in 2D. Then + * with MappingFEField) and `U` is a vector containing velocities in 2d. Then * the `k`th support point is mapped to `{X[2*k], X[2*k + 1]}` and the * velocity there is `{U[2*k], U[2*k + 1]}`. Hence, with this reordering, one * can read solution data at each support point without additional indexing. diff --git a/include/deal.II/fe/fe.h b/include/deal.II/fe/fe.h index dcbc1e6a07..dc4f144881 100644 --- a/include/deal.II/fe/fe.h +++ b/include/deal.II/fe/fe.h @@ -314,7 +314,7 @@ class FESystem; * *

Interpolation matrices in two dimensions

* - * In addition to the fields discussed above for 1D, a constraint matrix + * In addition to the fields discussed above for 1d, a constraint matrix * is needed to describe hanging node constraints if the finite element has * degrees of freedom located on edges or vertices. These constraints are * represented by an $m\times n$-matrix #interface_constraints, where m @@ -1458,11 +1458,11 @@ public: const unsigned int face_no = 0) const; /** - * For faces with non-standard face_orientation in 3D, the dofs on faces + * For faces with non-standard face_orientation in 3d, the dofs on faces * (quads) have to be permuted in order to be combined with the correct * shape functions. Given a local dof @p index on a quad, return the local * index, if the face has non-standard face_orientation, face_flip or - * face_rotation. In 2D and 1D there is no need for permutation and + * face_rotation. In 2d and 1d there is no need for permutation and * consequently an exception is thrown. */ unsigned int @@ -1534,10 +1534,10 @@ public: const bool face_rotation = false) const; /** - * For lines with non-standard line_orientation in 3D, the dofs on lines + * For lines with non-standard line_orientation in 3d, the dofs on lines * have to be permuted in order to be combined with the correct shape * functions. Given a local dof @p index on a line, return the local index, - * if the line has non-standard line_orientation. In 2D and 1D there is no + * if the line has non-standard line_orientation. In 2d and 1d there is no * need for permutation, so the given index is simply returned. */ unsigned int @@ -2459,12 +2459,12 @@ protected: std::vector>> generalized_face_support_points; /** - * For faces with non-standard face_orientation in 3D, the dofs on faces + * For faces with non-standard face_orientation in 3d, the dofs on faces * (quads) have to be permuted in order to be combined with the correct * shape functions. Given a local dof @p index on a quad, return the shift * in the local index, if the face has non-standard face_orientation, i.e. - * old_index + shift = new_index. In 2D and 1D there is no need - * for permutation so the vector is empty. In 3D it has the size of + * old_index + shift = new_index. In 2d and 1d there is no need + * for permutation so the vector is empty. In 3d it has the size of * #dofs_per_quad * 8 , where 8 is the number of orientations, a face * can be in (all combinations of the three bool flags face_orientation, * face_flip and face_rotation). @@ -2476,12 +2476,12 @@ protected: std::vector> adjust_quad_dof_index_for_face_orientation_table; /** - * For lines with non-standard line_orientation in 3D, the dofs on lines + * For lines with non-standard line_orientation in 3d, the dofs on lines * have to be permuted in order to be combined with the correct shape * functions. Given a local dof @p index on a line, return the shift in the * local index, if the line has non-standard line_orientation, i.e. - * old_index + shift = new_index. In 2D and 1D there is no need - * for permutation so the vector is empty. In 3D it has the size of + * old_index + shift = new_index. In 2d and 1d there is no need + * for permutation so the vector is empty. In 3d it has the size of * #dofs_per_line. * * The constructor of this class fills this table with zeros, i.e., diff --git a/include/deal.II/fe/fe_abf.h b/include/deal.II/fe/fe_abf.h index 5332dde9d5..4d7444f97a 100644 --- a/include/deal.II/fe/fe_abf.h +++ b/include/deal.II/fe/fe_abf.h @@ -57,7 +57,7 @@ DEAL_II_NAMESPACE_OPEN * * @todo Even if this element is implemented for two and three space * dimensions, the definition of the node values relies on consistently - * oriented faces in 3D. Therefore, care should be taken on complicated + * oriented faces in 3d. Therefore, care should be taken on complicated * meshes. * *

Interpolation

@@ -118,7 +118,7 @@ public: * This function returns @p true, if the shape function @p shape_index has * non-zero function values somewhere on the face @p face_index. * - * Right now, this is only implemented for RT0 in 1D. Otherwise, returns + * Right now, this is only implemented for RT0 in 1d. Otherwise, returns * always @p true. */ virtual bool diff --git a/include/deal.II/fe/fe_bdm.h b/include/deal.II/fe/fe_bdm.h index 13489db016..ce52ec6be7 100644 --- a/include/deal.II/fe/fe_bdm.h +++ b/include/deal.II/fe/fe_bdm.h @@ -35,7 +35,7 @@ DEAL_II_NAMESPACE_OPEN * *

Degrees of freedom

* - * @todo The 3D version exhibits some numerical instabilities, in particular + * @todo The 3d version exhibits some numerical instabilities, in particular * for higher order * * @todo Restriction matrices are missing. diff --git a/include/deal.II/fe/fe_data.h b/include/deal.II/fe/fe_data.h index 21bf469922..a7bf0907c8 100644 --- a/include/deal.II/fe/fe_data.h +++ b/include/deal.II/fe/fe_data.h @@ -518,7 +518,7 @@ public: /** * The same as above but instead of passing a vector containing the degrees * of freedoms per object a struct of type GenericDoFsPerObject. This allows - * that 2D objects might have different number of degrees of freedoms, which + * that 2d objects might have different number of degrees of freedoms, which * is particular useful for cells with triangles and quadrilaterals as faces. */ FiniteElementData(const internal::GenericDoFsPerObject &data, diff --git a/include/deal.II/fe/fe_dgq.h b/include/deal.II/fe/fe_dgq.h index 0cffacef27..012c82643b 100644 --- a/include/deal.II/fe/fe_dgq.h +++ b/include/deal.II/fe/fe_dgq.h @@ -104,7 +104,7 @@ class Quadrature; * equidistant points at degree 10 has condition number 2.6e6, whereas the * condition number for Gauss-Lobatto points is around 400. * - * The Gauss-Lobatto points in 1D include the end points 0 and +1 of the unit + * The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit * interval. The interior points are shifted towards the end points, which * gives a denser point distribution close to the element boundary. */ diff --git a/include/deal.II/fe/fe_face.h b/include/deal.II/fe/fe_face.h index d8e072f0ba..365874e86c 100644 --- a/include/deal.II/fe/fe_face.h +++ b/include/deal.II/fe/fe_face.h @@ -204,12 +204,12 @@ private: /** - * Specialization of FE_FaceQ for 1D. In that case, the finite element only + * Specialization of FE_FaceQ for 1d. In that case, the finite element only * consists of one degree of freedom in each of the two faces (= vertices) of * a cell, irrespective of the degree. However, this element still accepts a * degree in its constructor and also returns that degree. This way, * dimension-independent programming with trace elements is also possible in - * 1D (even though there is no computational benefit at all from it in 1D). + * 1d (even though there is no computational benefit at all from it in 1d). * * @ingroup fe */ @@ -565,7 +565,7 @@ private: /** - * FE_FaceP in 1D, i.e., with degrees of freedom on the element vertices. + * FE_FaceP in 1d, i.e., with degrees of freedom on the element vertices. * See the documentation of the general template for more information. */ template diff --git a/include/deal.II/fe/fe_nedelec.h b/include/deal.II/fe/fe_nedelec.h index 7b7ac333e2..1b1d97bc0b 100644 --- a/include/deal.II/fe/fe_nedelec.h +++ b/include/deal.II/fe/fe_nedelec.h @@ -108,7 +108,7 @@ DEAL_II_NAMESPACE_OPEN * * @todo Even if this element is implemented for two and three space * dimensions, the definition of the node values relies on consistently - * oriented faces in 3D. Therefore, care should be taken on complicated + * oriented faces in 3d. Therefore, care should be taken on complicated * meshes. * * @@ -156,7 +156,7 @@ DEAL_II_NAMESPACE_OPEN * function associated with each edge (i.e., the tangential component of each * shape function is non-zero on only one edge). * - * In 2D, these shape functions look as follows: @@ -185,7 +185,7 @@ DEAL_II_NAMESPACE_OPEN * For higher order Nédélec cells, we have shape functions * associated with the edges, faces, and the volume. * - * In 2D, for example, with FE_Nedelec(1), we have 2 shape functions associated + * In 2d, for example, with FE_Nedelec(1), we have 2 shape functions associated * with each edge, and 4 shape functions associated with the cell, which * correspond to the shape functions with no non-zero tangential components on * the boundary of the cell. @@ -261,7 +261,7 @@ DEAL_II_NAMESPACE_OPEN * For higher order Nédélec cells, we have shape functions * associated with the edges, faces, and the volume. * - * In 2D, with FE_Nedelec(2), we have 3 shape functions associated with each + * In 2d, with FE_Nedelec(2), we have 3 shape functions associated with each * edge, and 12 shape functions associated with the cell. * * These shape functions look @@ -407,7 +407,7 @@ public: * the total polynomial degree may be higher). If `order = 0`, the element is * linear and has degrees of freedom only on the edges. If `order >=1` the * element has degrees of freedom on the edges, faces and volume. For example - * the 3D version of FE_Nedelec has 12 degrees of freedom for `order = 0` + * the 3d version of FE_Nedelec has 12 degrees of freedom for `order = 0` * and 54 for `degree = 1`. It is important to have enough quadrature points * in order to perform the quadrature with sufficient accuracy. * For example diff --git a/include/deal.II/fe/fe_nedelec_sz.h b/include/deal.II/fe/fe_nedelec_sz.h index 7574541b25..de96bc3f03 100644 --- a/include/deal.II/fe/fe_nedelec_sz.h +++ b/include/deal.II/fe/fe_nedelec_sz.h @@ -84,7 +84,7 @@ public: * the total polynomial degree may be higher). If `order = 0`, the element is * linear and has degrees of freedom only on the edges. If `order >= 1` the * element has degrees of freedom on the edges, faces and volume. For example - * the 3D version of FE_NedelecSZ has 12 degrees of freedom for `order = 0` + * the 3d version of FE_NedelecSZ has 12 degrees of freedom for `order = 0` * and 54 for `degree = 1`. It is important to have enough quadrature points * in order to perform the quadrature with sufficient accuracy. * For example @@ -347,7 +347,7 @@ protected: std::vector> edge_lambda_values; /** - * Storage for gradients of edge extension parameters in 2D. In this case + * Storage for gradients of edge extension parameters in 2d. In this case * they are constant. These are stored for the 12 edges such that the global * vertex numbering* would follow the order defined by the "standard" * deal.II cell. @@ -358,7 +358,7 @@ protected: std::vector> edge_lambda_grads_2d; /** - * Storage for gradients of edge extension parameters in 3D. In this case + * Storage for gradients of edge extension parameters in 3d. In this case * they are non-constant. These are stored for the 12 edges such that the * global vertex numbering* would follow the order defined by the * "standard" deal.II cell. @@ -369,7 +369,7 @@ protected: std::vector>> edge_lambda_grads_3d; /** - * Storage for 2nd derivatives of edge extension parameters in 3D, which are + * Storage for 2nd derivatives of edge extension parameters in 3d, which are * constant across the cell. These are stored for the 12 edges such that the * global vertex numbering* would follow the order defined by the * "standard" deal.II cell. @@ -415,7 +415,7 @@ private: * where the components of the returned vector refer to: * 0 = vertex * 1 = edge - * 2 = face (which is a cell in 2D) + * 2 = face (which is a cell in 2d) * 3 = cell */ static std::vector diff --git a/include/deal.II/fe/fe_p1nc.h b/include/deal.II/fe/fe_p1nc.h index 83b1362062..0260833283 100644 --- a/include/deal.II/fe/fe_p1nc.h +++ b/include/deal.II/fe/fe_p1nc.h @@ -34,8 +34,8 @@ DEAL_II_NAMESPACE_OPEN /** * Implementation of the scalar version of the P1 nonconforming finite - * element, a piecewise linear element on quadrilaterals in 2D. - * This implementation is only for 2D cells in a 2D space (i.e., codimension 0). + * element, a piecewise linear element on quadrilaterals in 2d. + * This implementation is only for 2d cells in a 2d space (i.e., codimension 0). * * Unlike the usual continuous, $H^1$ conforming finite elements, * the P1 nonconforming element does not enforce continuity across edges. @@ -67,7 +67,7 @@ DEAL_II_NAMESPACE_OPEN * freedom (DoFs) on a quadrilateral is by using midpoint values of a function. * * However, these 4 functionals are not linearly independent - * because a linear function on 2D is uniquely determined by only 3 independent + * because a linear function on 2d is uniquely determined by only 3 independent * values. A simple observation reads that any linear function on a * quadrilateral should satisfy the 'dice rule': the sum of two function values * at the midpoints of the edge pair on opposite sides of a cell is equal to the @@ -88,7 +88,7 @@ DEAL_II_NAMESPACE_OPEN * the last value at the last midpoint. * It means that the number of independent local functionals on a cell is 3, * and this is also the dimension of the linear polynomial space on a cell in - * 2D. + * 2d. * *

Shape functions

* Before introducing the degrees of freedom, we present 4 local shape functions @@ -261,7 +261,7 @@ class FE_P1NC : public FiniteElement<2, 2> public: /** * Constructor for the P1 nonconforming element. - * It is only for 2D and codimension = 0. + * It is only for 2d and codimension = 0. */ FE_P1NC(); diff --git a/include/deal.II/fe/fe_poly_tensor.h b/include/deal.II/fe/fe_poly_tensor.h index 197d6dc7d4..9da973af82 100644 --- a/include/deal.II/fe/fe_poly_tensor.h +++ b/include/deal.II/fe/fe_poly_tensor.h @@ -225,12 +225,12 @@ protected: single_mapping_kind() const; /** - * For faces with non-standard face_orientation in 3D, the dofs on faces + * For faces with non-standard face_orientation in 3d, the dofs on faces * (quads) have to be permuted in order to be combined with the correct * shape functions and additionally can change the sign. Given a local * dof @p index on a quad, return the * sign of the permuted shape function, if the face has non-standard - * face_orientation, face_flip or face_rotation. In 2D and 1D there is no need + * face_orientation, face_flip or face_rotation. In 2d and 1d there is no need * for permutation and consequently it does nothing in this case. * * The permutation itself is returned by @@ -245,7 +245,7 @@ protected: const bool face_rotation) const; /** - * For faces with non-standard face_orientation in 3D, the dofs on faces + * For faces with non-standard face_orientation in 3d, the dofs on faces * (quads) need not only to be permuted in order to be combined with the * correct shape functions. Additionally they may change their sign. * diff --git a/include/deal.II/fe/fe_pyramid_p.h b/include/deal.II/fe/fe_pyramid_p.h index 456267c695..28981855f7 100644 --- a/include/deal.II/fe/fe_pyramid_p.h +++ b/include/deal.II/fe/fe_pyramid_p.h @@ -27,7 +27,7 @@ DEAL_II_NAMESPACE_OPEN /** * Base class of FE_PyramidP and FE_PyramidDGP. * - * @note Only implemented for 3D. + * @note Only implemented for 3d. * * @relates simplex */ diff --git a/include/deal.II/fe/fe_q.h b/include/deal.II/fe/fe_q.h index a799b9466c..db89e4d674 100644 --- a/include/deal.II/fe/fe_q.h +++ b/include/deal.II/fe/fe_q.h @@ -34,7 +34,7 @@ DEAL_II_NAMESPACE_OPEN * Implementation of a scalar Lagrange finite element @p Qp that yields the * finite element space of continuous, piecewise polynomials of degree @p p in * each coordinate direction. This class is realized using tensor product - * polynomials based on 1D Lagrange polynomials with equidistant (degree up to + * polynomials based on 1d Lagrange polynomials with equidistant (degree up to * 2), Gauss-Lobatto (starting from degree 3), or given support points. * * The standard constructor of this class takes the degree @p p of this finite @@ -79,7 +79,7 @@ DEAL_II_NAMESPACE_OPEN * equidistant points at degree 10 has condition number 2.6e6, whereas the * condition number for Gauss-Lobatto points is around 400. * - * The Gauss-Lobatto points in 1D include the end points 0 and +1 of the unit + * The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit * interval. The interior points are shifted towards the end points, which * gives a denser point distribution close to the element boundary. * @@ -100,12 +100,12 @@ DEAL_II_NAMESPACE_OPEN * *

Q1 elements

*
    - *
  • 1D case: + *
  • 1d case: * @verbatim * 0-------1 * @endverbatim * - *
  • 2D case: + *
  • 2d case: * @verbatim * 2-------3 * | | @@ -114,7 +114,7 @@ DEAL_II_NAMESPACE_OPEN * 0-------1 * @endverbatim * - *
  • 3D case: + *
  • 3d case: * @verbatim * 6-------7 6-------7 * /| | / /| @@ -166,12 +166,12 @@ DEAL_II_NAMESPACE_OPEN * *

    Q2 elements

    *
      - *
    • 1D case: + *
    • 1d case: * @verbatim * 0---2---1 * @endverbatim * - *
    • 2D case: + *
    • 2d case: * @verbatim * 2---7---3 * | | @@ -180,7 +180,7 @@ DEAL_II_NAMESPACE_OPEN * 0---6---1 * @endverbatim * - *
    • 3D case: + *
    • 3d case: * @verbatim * 6--15---7 6--15---7 * /| | / /| @@ -294,12 +294,12 @@ DEAL_II_NAMESPACE_OPEN * *

      Q3 elements

      *
        - *
      • 1D case: + *
      • 1d case: * @verbatim * 0--2--3--1 * @endverbatim * - *
      • 2D case: + *
      • 2d case: * @verbatim * 2--10-11-3 * | | @@ -396,12 +396,12 @@ DEAL_II_NAMESPACE_OPEN * *

        Q4 elements

        *
          - *
        • 1D case: + *
        • 1d case: * @verbatim * 0--2--3--4--1 * @endverbatim * - *
        • 2D case: + *
        • 2d case: * @verbatim * 2--13-14-15-3 * | | diff --git a/include/deal.II/fe/fe_q_base.h b/include/deal.II/fe/fe_q_base.h index 86e3511c6e..cb24c4cfc2 100644 --- a/include/deal.II/fe/fe_q_base.h +++ b/include/deal.II/fe/fe_q_base.h @@ -286,7 +286,7 @@ protected: get_dpo_vector(const unsigned int degree); /** - * Perform the initialization of the element based on 1D support points, + * Perform the initialization of the element based on 1d support points, * i.e., sets renumbering, initializes unit support points, initializes * constraints as well as restriction and prolongation matrices. */ diff --git a/include/deal.II/fe/fe_q_dg0.h b/include/deal.II/fe/fe_q_dg0.h index 7f45c328dc..e5af34cad0 100644 --- a/include/deal.II/fe/fe_q_dg0.h +++ b/include/deal.II/fe/fe_q_dg0.h @@ -74,12 +74,12 @@ DEAL_II_NAMESPACE_OPEN * *

          Q1 elements

          *
            - *
          • 1D case: + *
          • 1d case: * @verbatim * 0---2---1 * @endverbatim * - *
          • 2D case: + *
          • 2d case: * @verbatim * 2-------3 * | | @@ -88,7 +88,7 @@ DEAL_II_NAMESPACE_OPEN * 0-------1 * @endverbatim * - *
          • 3D case: + *
          • 3d case: * @verbatim * 6-------7 6-------7 * /| | / /| @@ -118,13 +118,13 @@ DEAL_II_NAMESPACE_OPEN *
          *

          Q2 elements

          *
            - *
          • 1D case: + *
          • 1d case: * @verbatim * 0---2---1 * @endverbatim * Index 3 has the same coordinates as index 2 * - *
          • 2D case: + *
          • 2d case: * @verbatim * 2---7---3 * | | @@ -134,7 +134,7 @@ DEAL_II_NAMESPACE_OPEN * @endverbatim * Index 9 has the same coordinates as index 2 * - *
          • 3D case: + *
          • 3d case: * @verbatim * 6--15---7 6--15---7 * /| | / /| @@ -195,12 +195,12 @@ DEAL_II_NAMESPACE_OPEN *
          *

          Q3 elements

          *
            - *
          • 1D case: + *
          • 1d case: * @verbatim * 0--2-4-3--1 * @endverbatim * - *
          • 2D case: + *
          • 2d case: * @verbatim * 2--10-11-3 * | | @@ -213,13 +213,13 @@ DEAL_II_NAMESPACE_OPEN *
          *

          Q4 elements

          *
            - *
          • 1D case: + *
          • 1d case: * @verbatim * 0--2--3--4--1 * @endverbatim * Index 5 has the same coordinates as index 3 * - *
          • 2D case: + *
          • 2d case: * @verbatim * 2--13-14-15-3 * | | diff --git a/include/deal.II/fe/fe_q_hierarchical.h b/include/deal.II/fe/fe_q_hierarchical.h index adc9482078..4615d7dab3 100644 --- a/include/deal.II/fe/fe_q_hierarchical.h +++ b/include/deal.II/fe/fe_q_hierarchical.h @@ -65,12 +65,12 @@ DEAL_II_NAMESPACE_OPEN * shape function are defined in the exact same way: * *
              - *
            • 1D case: + *
            • 1d case: * @verbatim * 0-------1 * @endverbatim * - *
            • 2D case: + *
            • 2d case: * @verbatim * 2-------3 * | | @@ -79,7 +79,7 @@ DEAL_II_NAMESPACE_OPEN * 0-------1 * @endverbatim * - *
            • 3D case: + *
            • 3d case: * @verbatim * 6-------7 6-------7 * /| | / /| @@ -133,12 +133,12 @@ DEAL_II_NAMESPACE_OPEN * *

              Q2 elements

              *
                - *
              • 1D case: + *
              • 1d case: * @verbatim * 0---2---1 * @endverbatim * - *
              • 2D case: + *
              • 2d case: * @verbatim * 2---7---3 * | | @@ -147,7 +147,7 @@ DEAL_II_NAMESPACE_OPEN * 0---6---1 * @endverbatim * - *
              • 3D case: + *
              • 3d case: * @verbatim * 6--15---7 6--15---7 * /| | / /| @@ -265,12 +265,12 @@ DEAL_II_NAMESPACE_OPEN * *

                Q3 elements

                *
                  - *
                • 1D case: + *
                • 1d case: * @verbatim * 0--2--3--1 * @endverbatim * - *
                • 2D case: + *
                • 2d case: * @verbatim * 2--10-11-3 * | | @@ -375,12 +375,12 @@ DEAL_II_NAMESPACE_OPEN * *

                  Q4 elements

                  *
                    - *
                  • 1D case: + *
                  • 1d case: * @verbatim * 0--2--3--4--1 * @endverbatim * - *
                  • 2D case: + *
                  • 2d case: * @verbatim * 2--13-14-15-3 * | | diff --git a/include/deal.II/fe/fe_rannacher_turek.h b/include/deal.II/fe/fe_rannacher_turek.h index bf8632abda..fd717db6ce 100644 --- a/include/deal.II/fe/fe_rannacher_turek.h +++ b/include/deal.II/fe/fe_rannacher_turek.h @@ -87,7 +87,7 @@ public: * n_face_support_points quadrature points on each face for interpolation. * Notice that the element of order 0 contains polynomials of degree 2. * - * The element is currently only implemented for order 0 in 2D. + * The element is currently only implemented for order 0 in 2d. */ FE_RannacherTurek(const unsigned int order = 0, const unsigned int n_face_support_points = 2); diff --git a/include/deal.II/fe/fe_raviart_thomas.h b/include/deal.II/fe/fe_raviart_thomas.h index 0550fae6dd..56fa491839 100644 --- a/include/deal.II/fe/fe_raviart_thomas.h +++ b/include/deal.II/fe/fe_raviart_thomas.h @@ -149,7 +149,7 @@ public: * This function returns @p true, if the shape function @p shape_index has * non-zero function values somewhere on the face @p face_index. * - * Right now, this is only implemented for RT0 in 1D. Otherwise, returns + * Right now, this is only implemented for RT0 in 1d. Otherwise, returns * always @p true. */ virtual bool @@ -311,7 +311,7 @@ private: * For this Raviart-Thomas element, the node values are not cell and face * moments with respect to certain polynomials, but the values at quadrature * points. Following the general scheme for numbering degrees of freedom, the - * node values on faces (edges in 2D, quads in 3D) are first, face by face, + * node values on faces (edges in 2d, quads in 3d) are first, face by face, * according to the natural ordering of the faces of a cell. The interior * degrees of freedom are last. * diff --git a/include/deal.II/fe/fe_rt_bubbles.h b/include/deal.II/fe/fe_rt_bubbles.h index 090a71fa64..566fcdb609 100644 --- a/include/deal.II/fe/fe_rt_bubbles.h +++ b/include/deal.II/fe/fe_rt_bubbles.h @@ -57,7 +57,7 @@ DEAL_II_NAMESPACE_OPEN * For this enhanced Raviart-Thomas element, the node values are not cell * and face moments with respect to certain polynomials, but the values in * Gauss-Lobatto quadrature points. The nodal values on edges (faces in - * 3D) are evaluated first, according to the natural ordering of the + * 3d) are evaluated first, according to the natural ordering of the * edges (faces) of a cell. The interior degrees of freedom are evaluated last. * * For an RT-Bubbles element of degree k, we choose @@ -71,16 +71,16 @@ DEAL_II_NAMESPACE_OPEN * mixed finite element methods on quadrilaterals and hexahedra" for * more details. * - * The elements of degree $k=3$ in 2D and $k=2$ in 3D are shown in + * The elements of degree $k=3$ in 2d and $k=2$ in 3d are shown in * the figures below (filled arrows indicate DoFs for which continuity across - * the edges (faces in 3D) is required). + * the edges (faces in 3d) is required). * *
* @image html fe_nedelec_shape_function_0_00.png *
* *
* @image html rtbubbles.png *
Left - $2d,\,k=3$, - * right - $3D,\,k=2$.
+ * right - $3d,\,k=2$. * * @todo Implement restriction matrices */ diff --git a/include/deal.II/fe/fe_series.h b/include/deal.II/fe/fe_series.h index 7e10c33f3e..57fab41fec 100644 --- a/include/deal.II/fe/fe_series.h +++ b/include/deal.II/fe/fe_series.h @@ -62,7 +62,7 @@ namespace FESeries * The exponential form of the Fourier series is based on completeness * and Hermitian orthogonality of the set of exponential * functions $ \phi_{\bf k}({\bf x}) = \exp(2 \pi i\, {\bf k} \cdot {\bf x})$. - * For example in 1D the L2-orthogonality condition reads + * For example in 1d the L2-orthogonality condition reads * @f[ * \int_0^1 \phi_k(x) \phi_l^\ast(x) dx=\delta_{kl}. * @f] diff --git a/include/deal.II/fe/fe_simplex_p.h b/include/deal.II/fe/fe_simplex_p.h index 5f53aacf44..38ac36cca2 100644 --- a/include/deal.II/fe/fe_simplex_p.h +++ b/include/deal.II/fe/fe_simplex_p.h @@ -28,7 +28,7 @@ DEAL_II_NAMESPACE_OPEN /** * Base class of FE_SimplexP, FE_SimplexDGP, and FE_SimplexP_Bubbles. * - * @note Only implemented for 2D and 3D. + * @note Only implemented for 2d and 3d. * * @relates simplex */ diff --git a/include/deal.II/fe/fe_simplex_p_bubbles.h b/include/deal.II/fe/fe_simplex_p_bubbles.h index 8a19ed11af..b3a05e813d 100644 --- a/include/deal.II/fe/fe_simplex_p_bubbles.h +++ b/include/deal.II/fe/fe_simplex_p_bubbles.h @@ -50,7 +50,7 @@ DEAL_II_NAMESPACE_OPEN * added corresponding to interpolation at the centroid (and all other basis * functions are updated to preserve the partition of unity property). This * results in shape functions with positive means (i.e., a valid nodal - * quadrature formula). Similarly, in 3D, the polynomial space of + * quadrature formula). Similarly, in 3d, the polynomial space of * FE_SimplexP<3>(2) is enriched with five additional degrees of freedom (where * four have support points at face centroids and one has a support point at the * centroid) to enable construction of valid nodal quadrature rule. @@ -59,12 +59,12 @@ DEAL_II_NAMESPACE_OPEN * nonzero only on element interiors), the polynomial degrees of the component * basis functions are higher than the actual approximation degree of the * element. For example, with a constructor argument degree = 2 - * in 3D, the polynomials are in fact cubic (degree 3) but the order of the + * in 3d, the polynomials are in fact cubic (degree 3) but the order of the * approximation is the same as if we were using quadratic (degree 2) finite * elements. * - * The 2D quadratic element was first described in @cite fried1975finite. The - * 3D quadratic element implemented here was first described in + * The 2d quadratic element was first described in @cite fried1975finite. The + * 3d quadratic element implemented here was first described in * @cite Geevers_2018. Higher degree elements amendable to lumping exist but * are not yet implemented in this class. */ diff --git a/include/deal.II/fe/fe_trace.h b/include/deal.II/fe/fe_trace.h index a63c74f022..4add7e3c05 100644 --- a/include/deal.II/fe/fe_trace.h +++ b/include/deal.II/fe/fe_trace.h @@ -30,7 +30,7 @@ DEAL_II_NAMESPACE_OPEN * A finite element, which is the trace of FE_Q elements, that is a tensor * product of polynomials on the faces, undefined in the interior of the cells * and continuous. The basis functions on the faces are formed by a tensor - * product of 1D Lagrange polynomials with equidistant points up to degree 2 + * product of 1d Lagrange polynomials with equidistant points up to degree 2 * and Gauss-Lobatto points starting from degree 3. * * This finite element is the trace space of FE_Q on the faces. @@ -150,7 +150,7 @@ private: /** - * FE_TraceQ in 1D, i.e., with degrees of freedom on the element vertices. + * FE_TraceQ in 1d, i.e., with degrees of freedom on the element vertices. */ template class FE_TraceQ<1, spacedim> : public FE_FaceQ<1, spacedim> diff --git a/include/deal.II/fe/fe_wedge_p.h b/include/deal.II/fe/fe_wedge_p.h index b9b90d6a27..772c713dbd 100644 --- a/include/deal.II/fe/fe_wedge_p.h +++ b/include/deal.II/fe/fe_wedge_p.h @@ -27,7 +27,7 @@ DEAL_II_NAMESPACE_OPEN /** * Base class of FE_WedgeP and FE_WedgeDGP. * - * @note Only implemented for 3D. + * @note Only implemented for 3d. * * @relates simplex */ diff --git a/include/deal.II/fe/mapping_q.h b/include/deal.II/fe/mapping_q.h index b4eb85e9f7..98366d47d4 100644 --- a/include/deal.II/fe/mapping_q.h +++ b/include/deal.II/fe/mapping_q.h @@ -478,12 +478,12 @@ public: * vectors that are as wide as possible to minimize the number of * arithmetic operations. However, we do not want to choose it wider than * necessary, e.g., we avoid something like 8-wide AVX-512 when we only - * compute 3 components of a 3D computation. This is because the + * compute 3 components of a 3d computation. This is because the * additional lanes would not do useful work, but a few operations on very * wide vectors can already lead to a lower clock frequency of processors * over long time spans (thousands of clock cycles). Hence, we choose - * 2-wide SIMD for 1D and 2D and 4-wide SIMD for 3D. Note that we do not - * immediately fall back to no SIMD for 1D because all architectures that + * 2-wide SIMD for 1D and 2d and 4-wide SIMD for 3d. Note that we do not + * immediately fall back to no SIMD for 1d because all architectures that * support SIMD also support 128-bit vectors (and none is reported to * reduce clock frequency for 128-bit SIMD). */ @@ -693,8 +693,8 @@ protected: * same manifold is attached to all sub-entities of a cell. This way, we can * avoid some of the overhead in transforming data for mappings. * - * The table has as many rows as there are vertices to the cell (2 in 1D, 4 - * in 2D, 8 in 3D), and as many rows as there are additional support points + * The table has as many rows as there are vertices to the cell (2 in 1d, 4 + * in 2d, 8 in 3d), and as many rows as there are additional support points * in the mapping, i.e., (degree+1)^dim - 2^dim. */ const Table<2, double> support_point_weights_cell; diff --git a/include/deal.II/fe/mapping_q1.h b/include/deal.II/fe/mapping_q1.h index 4d75d7404e..9db649fa67 100644 --- a/include/deal.II/fe/mapping_q1.h +++ b/include/deal.II/fe/mapping_q1.h @@ -36,7 +36,7 @@ DEAL_II_NAMESPACE_OPEN * * The mapping implemented by this class maps the reference (unit) cell to a * general grid cell with straight lines in $d$ dimensions. (Note, however, - * that in 3D the faces of a general, trilinearly mapped cell may be + * that in 3d the faces of a general, trilinearly mapped cell may be * curved, even if the edges are not). This is the standard mapping used for * polyhedral domains. It is also the mapping used throughout deal.II for many * functions that come in two variants, one that allows to pass a mapping diff --git a/include/deal.II/fe/mapping_q_internal.h b/include/deal.II/fe/mapping_q_internal.h index c67d52c296..ddd4c145b2 100644 --- a/include/deal.II/fe/mapping_q_internal.h +++ b/include/deal.II/fe/mapping_q_internal.h @@ -51,7 +51,7 @@ namespace internal /** * Internal namespace to implement methods specific to MappingQ1, in * particular an explicit formula for the transformation from the real to - * the unit cell in 2D. + * the unit cell in 2d. */ namespace MappingQ1 { diff --git a/include/deal.II/grid/cell_id.h b/include/deal.II/grid/cell_id.h index a98d9aa6b2..67d9058b96 100644 --- a/include/deal.II/grid/cell_id.h +++ b/include/deal.II/grid/cell_id.h @@ -73,7 +73,7 @@ public: /** * A type that is used to encode the CellId data in a compact and fast way * (e.g. for MPI transfer to other processes). Note that it limits the - * number of children that can be transferred to 20 in 3D and 30 in 2D + * number of children that can be transferred to 20 in 3d and 30 in 2d * (using 2 times 32 bit for storage), a limitation that is identical to * the one used by p4est. */ diff --git a/include/deal.II/grid/connectivity.h b/include/deal.II/grid/connectivity.h index 36ef3bd966..2fe4c7424c 100644 --- a/include/deal.II/grid/connectivity.h +++ b/include/deal.II/grid/connectivity.h @@ -801,15 +801,15 @@ namespace internal * - dim-dimensional neighbors of dim-dimensional entities (connected via * faces) * - d-dimensional entity to it's (d-1)-dimension bounding entities - * - quad (2 - 3D), line (1 - 2D/3D) to vertices (0) to be able to process + * - quad (2 - 3D), line (1 - 2d/3d) to vertices (0) to be able to process * the user provided SubCellData during * Triangulation::create_triangulation(). * We call a table, which computes the corresponding entries of a full * connectivity table a reduced table. * - * The entries of the reduced table are as follows for 1D-3D: + * The entries of the reduced table are as follows for 1d-3d: * - * 1D : | 0 1 2D: | 0 1 2 3D: | 0 1 2 3 + * 1D : | 0 1 2d: | 0 1 2 3d: | 0 1 2 3 * ---+----- ---+------- ---+-------- * 0 | 0 | 0 | * 1 | x n 1 | x 1 | x diff --git a/include/deal.II/grid/grid_generator.h b/include/deal.II/grid/grid_generator.h index 83ec72dcf7..9747f51a85 100644 --- a/include/deal.II/grid/grid_generator.h +++ b/include/deal.II/grid/grid_generator.h @@ -69,8 +69,8 @@ namespace GridGenerator //** @{ */ /** - * Initialize the given triangulation with a hypercube (line in 1D, square - * in 2D, etc) consisting of exactly one cell. The hypercube volume is the + * Initialize the given triangulation with a hypercube (line in 1d, square + * in 2d, etc) consisting of exactly one cell. The hypercube volume is the * tensor product interval $[left,right]^{\text{dim}}$ in the present number * of dimensions, where the limits are given as arguments. They default to * zero and unity, then producing the unit hypercube. @@ -357,8 +357,8 @@ namespace GridGenerator * The first is a square region with length @p outer_radius and a hole of radius @p inner_radius . * Cells in this region will have TransfiniteInterpolationManifold with * manifold id @p tfi_manifold_id attached to them. Additionally, the boundary - * faces of the hole will be associated with a PolarManifold (in 2D) or - * CylindricalManifold (in 3D). The center of this + * faces of the hole will be associated with a PolarManifold (in 2d) or + * CylindricalManifold (in 3d). The center of this * region can be prescribed via @p center , namely the axis of the hole will * be located at @p center . * The second region describes the remainder of the bulk material. It is @@ -370,7 +370,7 @@ namespace GridGenerator * 2*outer_radius + padding_bottom. * * Here is the non-symmetric grid (after one global refinement, colored - * according to manifold id) in 2D and 3D, respectively: + * according to manifold id) in 2d and 3d, respectively: * * \htmlonly \endhtmlonly @@ -379,7 +379,7 @@ namespace GridGenerator * img[src="plate_with_a_hole_3D.png"]{width:25%;} \endhtmlonly * @image html plate_with_a_hole_3D.png * - * In 3D, triangulation will be extruded in the z-direction by the total + * In 3d, triangulation will be extruded in the z-direction by the total * height of @p L using @p n_slices slices (minimum is 2). * * If the @p colorize flag is true, the boundary_ids of the @@ -412,7 +412,7 @@ namespace GridGenerator * Generate a grid consisting of a channel with a cylinder. This is a common * benchmark for Navier-Stokes solvers. The geometry consists of a channel * of size $[0, 2.2] \times [0, 0.41] \times [0, 0.41] $ (where the $z$ - * dimension is omitted in 2D) with a cylinder, parallel to the $z$ axis + * dimension is omitted in 2d) with a cylinder, parallel to the $z$ axis * with diameter $0.1$, centered at $(0.2, 0.2, 0)$. The channel has three * distinct regions: *
    @@ -424,16 +424,16 @@ namespace GridGenerator *
* Since the cylinder is slightly offset from the center of the channel, * this geometry results in vortex shedding at moderate Reynolds - * numbers. Here is the grid (without additional global refinement) in 2D: + * numbers. Here is the grid (without additional global refinement) in 2d: * * @image html channel_with_cylinder_2d.png * - * and in 3D: + * and in 3d: * * @image html channel_with_cylinder_3d.png * - * The resulting Triangulation uses three manifolds: a PolarManifold (in 2D) - * or CylindricalManifold (in 3D) with manifold id $0$, a + * The resulting Triangulation uses three manifolds: a PolarManifold (in 2d) + * or CylindricalManifold (in 3d) with manifold id $0$, a * TransfiniteInterpolationManifold with manifold id $1$, and a FlatManifold * everywhere else. For more information on this topic see * @ref GlossManifoldIndicator "the glossary entry on manifold indicators". @@ -448,7 +448,7 @@ namespace GridGenerator * numbers::flat_manifold_id are rectangular prisms aligned with the * coordinate axes. * - * The picture below shows part of the 2D grid (using all default arguments + * The picture below shows part of the 2d grid (using all default arguments * to this function) after two global refinements. The cells with manifold * id $0$ are orange (the polar manifold id), cells with manifold id $1$ are * yellow (the transfinite interpolation manifold id), and the ones with @@ -753,7 +753,7 @@ namespace GridGenerator * based on the cells used by GridGenerator::quarter_hyper_ball() with * appropriate copies and rotations to fill the whole ball. * - * The following pictures show the resulting mesh in 2D (left) and 3D: + * The following pictures show the resulting mesh in 2d (left) and 3d: * * *
@@ -785,7 +785,7 @@ namespace GridGenerator const double radius = 1.); /** - * Generate a 2D mesh consisting of five squares arranged in a plus-shape. + * Generate a 2d mesh consisting of five squares arranged in a plus-shape. * Depending on the number n_rotate_middle_square passed the * middle square is rotated by a degree of * n_rotate_middle_square$\pi/2$. This way one can generate a @@ -807,7 +807,7 @@ namespace GridGenerator const unsigned int n_rotate_middle_square); /** - * Generate a 3D mesh consisting of the unit cube joined with a copy shifted + * Generate a 3d mesh consisting of the unit cube joined with a copy shifted * by $s = (1,0,0)$. Depending on the flags passed either the right or the * left cube (when looking at the positively oriented (x,z)-plane) contains a * face that is either not in standard orientation and/or is rotated by either @@ -878,7 +878,7 @@ namespace GridGenerator * boundary and 1 for the cut plane. The manifold id for the curved boundary * is set to zero, and a SphericalManifold is attached to it. * - * The resulting grid in 2D and 3D looks as follows: + * The resulting grid in 2d and 3d looks as follows: * * *
@@ -1016,7 +1016,7 @@ namespace GridGenerator * In three dimensions, the manifold id of the hull is set to zero, and a * CylindricalManifold is attached to it. * - * Here are the grids in 2D and 3D after two mesh refinements: + * Here are the grids in 2d and 3d after two mesh refinements: * * @image html truncated_cone_2d.png * @image html truncated_cone_3d.png @@ -1236,7 +1236,7 @@ namespace GridGenerator const bool colorize = false); /** - * Initialize the given triangulation in 2D or 3D with a generalized + * Initialize the given triangulation in 2d or 3d with a generalized * subdivided hyper-L. * * This function produces a subdivided hyper rectangle with dimensions given @@ -1255,16 +1255,16 @@ namespace GridGenerator * * This function may be used to generate a mesh for a backward * facing step, a useful domain for benchmark problems in fluid dynamics. - * The first image is a backward facing step in 3D, generated by + * The first image is a backward facing step in 3d, generated by * removing all cells in the z-direction, and 2 cells in the * positive x- and y-directions: * @image html subdivided_hyper_L_3d.png - * And in 2D, we can cut away 1 cell in the negative x-direction, and 2 cells + * And in 2d, we can cut away 1 cell in the negative x-direction, and 2 cells * in the negative y-direction: * @image html subdivided_hyper_L_2d.png * * @note This function is declared to exist for triangulations of all space - * dimensions, but throws an error if called in 1D. + * dimensions, but throws an error if called in 1d. */ template void @@ -1492,7 +1492,7 @@ namespace GridGenerator * have the least aspect ratio. The same holds for @p n_axial_cells. * * @note Although this function is declared as a template, it does not make - * sense in 1D and 2D. Also keep in mind that this object is rotated + * sense in 1d and 2d. Also keep in mind that this object is rotated * and positioned differently than the one created by cylinder(). * * All manifold ids are set to zero, and a CylindricalManifold is attached @@ -1947,7 +1947,7 @@ namespace GridGenerator * This function creates a new Triangulation equal to a * dim-dimensional array of copies of @p input. Copies of @p input * are created by translating @p input along the coordinate axes. Boundary - * ids of faces (but not lines in 3D) and all manifold ids are copied but + * ids of faces (but not lines in 3d) and all manifold ids are copied but * Manifold objects are not since most Manifold objects do not work * correctly when a Triangulation has been translated. * @@ -1962,7 +1962,7 @@ namespace GridGenerator * * @image html replicated_tria_2d.png * - * And, similarly, in 3D: + * And, similarly, in 3d: * @code * Triangulation<3> input; * GridGenerator::hyper_cross(1, 1, 1, 2, 1, 2); @@ -2276,7 +2276,7 @@ namespace GridGenerator Triangulation &out_tria); /** - * Specialization of the above function for 1D: simply copy triangulation. + * Specialization of the above function for 1d: simply copy triangulation. */ template void @@ -2429,7 +2429,7 @@ namespace GridGenerator * vertices in the final mesh are moved by this function to the * right position. * - * @note This function is currently only implemented for 2D but the mesh + * @note This function is currently only implemented for 2d but the mesh * can of course be extruded into the third dimension using * GridGenerator::extrude(). * @@ -2455,7 +2455,7 @@ namespace GridGenerator * The same as above but periodic boundary conditions on the * upper and lower faces of the far field are applied. * - * @note This function is currently only implemented for 2D. + * @note This function is currently only implemented for 2d. * * @param[out] tria The triangulation to be created. It needs to be empty * upon calling this function. @@ -2496,8 +2496,8 @@ namespace GridGenerator const bool colorize = false); /** - * Initialize the given triangulation with a hypercube (square in 2D and - * cube in 3D) consisting of @p repetitions cells in each direction. + * Initialize the given triangulation with a hypercube (square in 2d and + * cube in 3d) consisting of @p repetitions cells in each direction. * The hypercube volume is the tensor product interval * $[left,right]^{\text{dim}}$ in the present number of dimensions, where * the limits are given as arguments. They default to zero and unity, then diff --git a/include/deal.II/grid/grid_in.h b/include/deal.II/grid/grid_in.h index 7e74bdc2cd..03254f44bd 100644 --- a/include/deal.II/grid/grid_in.h +++ b/include/deal.II/grid/grid_in.h @@ -174,7 +174,7 @@ struct CellData; * A Wikipedia page dedicated to Universal File Format is available here: * https://en.wikipedia.org/wiki/Universal_File_Format * - * Note that Salome, let's say in 2D, can only make a quad mesh on an object + * Note that Salome, let's say in 2d, can only make a quad mesh on an object * that has exactly 4 edges (or 4 pieces of the boundary). That means, that if * you have a more complicated object and would like to mesh it with quads, * you will need to decompose the object into >= 2 separate objects. Then 1) @@ -192,7 +192,7 @@ struct CellData; * *
  • VTK format: VTK Unstructured Grid Legacy file reader * generator. The reader can handle only Unstructured Grid format of data at - * present for 2D & 3D geometries. The documentation for the general legacy + * present for 2d & 3d geometries. The documentation for the general legacy * vtk file, including Unstructured Grid format can be found here: * http://www.cacr.caltech.edu/~slombey/asci/vtk/vtk_formats.simple.html * @@ -634,7 +634,7 @@ public: * * This function can only be used to read two-dimensional meshes (possibly * embedded in three dimensions). This is the standard for graphical software - * such as blender, or 3D studio max, and that is what the original Assimp + * such as blender, or 3d studio max, and that is what the original Assimp * library was built for. We "bend" it to deal.II to support complex * co-dimension one meshes and complex two-dimensional meshes. * diff --git a/include/deal.II/grid/grid_tools.h b/include/deal.II/grid/grid_tools.h index b7ca5394bc..bca83de22a 100644 --- a/include/deal.II/grid/grid_tools.h +++ b/include/deal.II/grid/grid_tools.h @@ -281,7 +281,7 @@ namespace GridTools * transformation by a bi-/trilinear or higher order mapping might be * singular. The result is exact in case the transformation from the unit to * the real cell is indeed affine, such as in one dimension or for Cartesian - * and affine (parallelogram) meshes in 2D/3D. + * and affine (parallelogram) meshes in 2d/3d. * * This approximation is underlying the function * TriaAccessor::real_to_unit_cell_affine_approximation() function. @@ -432,7 +432,7 @@ namespace GridTools * This function is called by some GridIn::read_* functions. Only * the vertices with indices in @p considered_vertices are tested for * equality. This speeds up the algorithm, which is, for worst-case hyper - * cube geometries $O(N^{3/2})$ in 2D and $O(N^{5/3})$ in 3D: quite slow. + * cube geometries $O(N^{3/2})$ in 2d and $O(N^{5/3})$ in 3d: quite slow. * However, if you wish to consider all vertices, simply pass an empty * vector. In that case, the function fills @p considered_vertices with all * vertices. @@ -2807,7 +2807,7 @@ namespace GridTools * orientation[2] -> face_rotation * @endcode * - * In 2D face_orientation is always true, + * In 2d face_orientation is always true, * face_rotation is always false, and face_flip has the * meaning of line_flip. More precisely in 3d: * @@ -3422,7 +3422,7 @@ namespace GridTools /** - * An implementation of the marching-square (2D) and marching-cube algorithm + * An implementation of the marching-square (2d) and marching-cube algorithm * for creating data structures (vectors of Point and CellData) to * create a linear/bilinear surface mesh on the iso line/contour of a * scalar field. @@ -3432,7 +3432,7 @@ namespace GridTools * algorithm is not run on a cell but on subcells with vertex values having * been interpolated from the cell values. * - * @note The resulting mesh will contain lines in 2D and triangles in 3D. + * @note The resulting mesh will contain lines in 2d and triangles in 3d. * * @note The resulting mesh will not be of high quality, since it might * contain cells with very small diameters if the mesh is cut close to a @@ -3531,7 +3531,7 @@ namespace GridTools const bool write_back_cell_data = true) const; /** - * Dummy function for 1D processing a sub-cell. + * Dummy function for 1d processing a sub-cell. */ void process_sub_cell(const std::vector &, @@ -3546,7 +3546,7 @@ namespace GridTools } /** - * Process a sub-cell (2D). + * Process a sub-cell (2d). * * @note Subcells with saddle points are ignored. Please increase the number * of subdivisions in this case. @@ -3561,7 +3561,7 @@ namespace GridTools const bool write_back_cell_data) const; /** - * Process a sub-cell (3D). + * Process a sub-cell (3d). */ void process_sub_cell(const std::vector & ls_values, @@ -3897,7 +3897,7 @@ namespace GridTools /** * Standard second-order approximation to the first derivative with a - * two-point centered scheme. This is used below in a 1D Newton method. + * two-point centered scheme. This is used below in a 1d Newton method. */ template inline auto @@ -3912,7 +3912,7 @@ namespace GridTools /** * Standard second-order approximation to the second derivative with a - * three-point centered scheme. This is used below in a 1D Newton method. + * three-point centered scheme. This is used below in a 1d Newton method. */ template inline auto diff --git a/include/deal.II/grid/manifold.h b/include/deal.II/grid/manifold.h index 0326dea60c..5d3560f54a 100644 --- a/include/deal.II/grid/manifold.h +++ b/include/deal.II/grid/manifold.h @@ -412,7 +412,7 @@ public: /** * Backward compatibility interface. Return the point which shall become - * the new middle vertex of the two children of a regular line. In 2D, this + * the new middle vertex of the two children of a regular line. In 2d, this * line is a line at the boundary, while in 3d, it is bounding a face at the * boundary (the lines therefore is also on the boundary). * diff --git a/include/deal.II/grid/manifold_lib.h b/include/deal.II/grid/manifold_lib.h index 631d4be2de..eaa7d698f7 100644 --- a/include/deal.II/grid/manifold_lib.h +++ b/include/deal.II/grid/manifold_lib.h @@ -368,7 +368,7 @@ private: ArrayView> new_points) const; /** - * A manifold description to be used for get_new_point in 2D. + * A manifold description to be used for get_new_point in 2d. */ const PolarManifold polar_manifold; }; @@ -835,7 +835,7 @@ private: * interpolation. * The use of this class is discussed extensively in step-65. * - * The formula for extending such a description in 2D is, for example, + * The formula for extending such a description in 2d is, for example, * described on * * Wikipedia. Given a point $(u,v)$ on the chart, the image of this point @@ -851,7 +851,7 @@ private: * four curves describing the lines of the cell. If a curved manifold is * attached to any of these lines, the evaluation is done according to * Manifold::get_new_point() with the two end points of the line and - * appropriate weight. In 3D, the generalization of this formula is + * appropriate weight. In 3d, the generalization of this formula is * implemented, creating a weighted sum of the vertices (positive * contribution), the lines (negative), and the faces (positive contribution). * @@ -1050,7 +1050,7 @@ private: * do the search inside the relevant cells. The cells are sorted by the * distance of a Q1 approximation of the inverse mapping to the unit cell of * the surrounding points. We expect at most 20 cells (it should be up to 8 - * candidates on a 3D structured mesh and a bit more on unstructured ones, + * candidates on a 3d structured mesh and a bit more on unstructured ones, * typically we only get two or three), so get an array with 20 entries of a * the indices cell->index(). */ diff --git a/include/deal.II/grid/reference_cell.h b/include/deal.II/grid/reference_cell.h index c65f7ae2bd..f56cc81963 100644 --- a/include/deal.II/grid/reference_cell.h +++ b/include/deal.II/grid/reference_cell.h @@ -201,13 +201,13 @@ public: * Return a Gauss-type quadrature matching the given reference cell (QGauss, * QGaussSimplex, QGaussPyramid, QGaussWedge). * - * @param[in] n_points_1D The number of quadrature points in each direction + * @param[in] n_points_1d The number of quadrature points in each direction * (QGauss) or an indication of what polynomial degree needs to be * integrated exactly for the other types. */ template Quadrature - get_gauss_type_quadrature(const unsigned n_points_1D) const; + get_gauss_type_quadrature(const unsigned n_points_1d) const; /** * Return a quadrature object that has a single quadrature point at the @@ -351,7 +351,7 @@ public: /** * Return the default combined face orientation flag (i.e., the default set of - * orientations, defined by orientation, rotate, and flip for a face in 3D). + * orientations, defined by orientation, rotate, and flip for a face in 3d). */ static constexpr unsigned char default_combined_face_orientation(); @@ -373,7 +373,7 @@ public: * Return which child cells are adjacent to a certain face of the * mother cell. * - * For example, in 2D the layout of a quadrilateral cell is as follows: + * For example, in 2d the layout of a quadrilateral cell is as follows: * @verbatim * 3 * 2-->--3 diff --git a/include/deal.II/grid/tria.h b/include/deal.II/grid/tria.h index 3f792c8e6a..a26caed12e 100644 --- a/include/deal.II/grid/tria.h +++ b/include/deal.II/grid/tria.h @@ -347,7 +347,7 @@ namespace internal * and handle the usual one-dimensional triangulation used in the finite * element method (so, segments on a straight line). On the other hand, * objects such as @p Triangulation<1,2> or @p Triangulation<2,3> (that are - * associated with curves in 2D or surfaces in 3D) are the ones one wants to + * associated with curves in 2d or surfaces in 3d) are the ones one wants to * use in the boundary element method. * * The name of the class is mostly hierarchical and is not meant to imply that @@ -409,7 +409,7 @@ namespace internal * By using the cell iterators, you can write code independent of the spatial * dimension. The same applies for substructure iterators, where a * substructure is defined as a face of a cell. The face of a cell is a vertex - * in 1D and a line in 2D; however, vertices are handled in a different way + * in 1d and a line in 2d; however, vertices are handled in a different way * and therefore lines have no faces. * * The Triangulation class offers functions like begin_active() which gives @@ -528,7 +528,7 @@ namespace internal * * Creating the hierarchical information needed for this library from cells * storing only vertex information can be quite a complex task. For example - * in 2D, we have to create lines between vertices (but only once, though + * in 2d, we have to create lines between vertices (but only once, though * there are two cells which link these two vertices) and we have to create * neighborhood information. Grids being read in should therefore not be too * large, reading refined grids would be inefficient (although there is @@ -543,7 +543,7 @@ namespace internal * guarantee this, in the input vector keeping the cell list, the vertex * indices for each cell have to be in a defined order, see the documentation * of GeometryInfo. In one dimension, the first vertex index must refer - * to that vertex with the lower coordinate value. In 2D and 3D, the + * to that vertex with the lower coordinate value. In 2d and 3d, the * corresponding conditions are not easy to verify and no full attempt to do * so is made. If you violate this condition, you may end up with matrix * entries having the wrong sign (clockwise vertex numbering, which results in @@ -707,7 +707,7 @@ namespace internal * Boundary indicators may be in the range from zero to * numbers::internal_face_boundary_id-1. The value * numbers::internal_face_boundary_id is reserved to denote interior lines (in - * 2D) and interior lines and quads (in 3D), which do not have a boundary + * 2d) and interior lines and quads (in 3d), which do not have a boundary * indicator. This way, a program can easily determine, whether such an object * is at the boundary or not. Material indicators may be in the range from * zero to numbers::invalid_material_id-1. @@ -715,7 +715,7 @@ namespace internal * Lines in two dimensions and quads in three dimensions inherit their * boundary indicator to their children upon refinement. You should therefore * make sure that if you have different boundary parts, the different parts - * are separated by a vertex (in 2D) or a line (in 3D) such that each boundary + * are separated by a vertex (in 2d) or a line (in 3d) such that each boundary * line or quad has a unique boundary indicator. * * By default (unless otherwise specified during creation of a triangulation), @@ -880,7 +880,7 @@ namespace internal * must make sure that a new boundary vertex does not lie too much inside the * cell which is to be refined. The reason is that the center vertex is placed * at the point which is a weighted average of the vertices of the original - * cell, new face midpoints, and (in 3D) new line midpoints. Therefore if your + * cell, new face midpoints, and (in 3d) new line midpoints. Therefore if your * new boundary vertex is too near the center of the old quadrilateral or * hexahedron, the distance to the midpoint vertex will become too small, thus * generating distorted cells. This issue is discussed extensively in @@ -1210,7 +1210,7 @@ public: * unrefined cells are flagged for refinement. Cells which are not yet * refined but flagged for that are accounted for the number of refined * neighbors. Cells on the boundary are not accounted for at all. An - * unrefined island is, by this definition also a cell which (in 2D) is + * unrefined island is, by this definition also a cell which (in 2d) is * surrounded by three refined cells and one unrefined one, or one * surrounded by two refined cells, one unrefined one and is at the * boundary on one side. It is thus not a true island, as the name of the @@ -1288,7 +1288,7 @@ public: * for refinement. This definition is unlike that for * #eliminate_unrefined_islands, which would mean that an island is * defined as a cell which is refined but more of its neighbors are not - * refined than are refined. For example, in 2D, a cell's refinement would + * refined than are refined. For example, in 2d, a cell's refinement would * be reverted if at most one of its neighbors is also refined (or refined * but flagged for coarsening). * @@ -3152,8 +3152,8 @@ public: * In the following, most functions are provided in two versions, with and * without an argument describing the level. The versions with this argument * are only applicable for objects describing the cells of the present - * triangulation. For example: in 2D n_lines(level) cannot be - * called, only n_lines(), as lines are faces in 2D and therefore + * triangulation. For example: in 2d n_lines(level) cannot be + * called, only n_lines(), as lines are faces in 2d and therefore * have no level. */ @@ -3278,16 +3278,16 @@ public: n_global_coarse_cells() const; /** - * Return the total number of used faces, active or not. In 2D, the result - * equals n_lines(), in 3D it equals n_quads(), while in 1D it equals + * Return the total number of used faces, active or not. In 2d, the result + * equals n_lines(), in 3d it equals n_quads(), while in 1d it equals * the number of used vertices. */ unsigned int n_faces() const; /** - * Return the total number of active faces. In 2D, the result equals - * n_active_lines(), in 3D it equals n_active_quads(), while in 1D it equals + * Return the total number of active faces. In 2d, the result equals + * n_active_lines(), in 3d it equals n_active_quads(), while in 1d it equals * the number of used vertices. */ unsigned int @@ -3501,7 +3501,7 @@ public: /** * Return the total number of faces, used or not. In 2d, the result equals - * n_raw_lines(), in 3d it equals n_raw_quads(), while in 1D it equals + * n_raw_lines(), in 3d it equals n_raw_quads(), while in 1d it equals * the number of vertices. * * @note This function really exports internal information about the @@ -4183,7 +4183,7 @@ private: /** * Pointer to the faces of the triangulation. In 1d this contains nothing, - * in 2D it contains data concerning lines and in 3D quads and lines. All + * in 2d it contains data concerning lines and in 3d quads and lines. All * of these have no level and are therefore treated separately. */ std::unique_ptr diff --git a/include/deal.II/grid/tria_accessor.h b/include/deal.II/grid/tria_accessor.h index 0e54c2594a..05f389e2c3 100644 --- a/include/deal.II/grid/tria_accessor.h +++ b/include/deal.II/grid/tria_accessor.h @@ -1565,7 +1565,7 @@ public: * from the vertex points, this function also ignores the attached manifold * descriptions. The result is only exact in case the transformation from * the unit to the real cell is indeed affine, such as in one dimension or - * for Cartesian and affine (parallelogram) meshes in 2D/3D. + * for Cartesian and affine (parallelogram) meshes in 2d/3d. * * For exact transformations to the unit cell, use * Mapping::transform_real_to_unit_cell(). @@ -1597,12 +1597,12 @@ public: * setting to true the second additional parameter @p * interpolate_from_surrounding. This computes the location of the center by * a so-called transfinite interpolation from the center of all the bounding - * objects. For a 2D object, it puts a weight of 1/2 on each of + * objects. For a 2d object, it puts a weight of 1/2 on each of * the four surrounding lines and a weight -1/4 on the four * vertices. This corresponds to a linear interpolation between the * descriptions of the four faces, subtracting the contribution of the * vertices that is added twice when coming through both lines adjacent to - * the vertex. In 3D, the weights for faces are 1/2, the + * the vertex. In 3d, the weights for faces are 1/2, the * weights for lines are -1/4, and the weights for vertices are * 1/8. For further information, also confer to the * TransfiniteInterpolationManifold class that is able to not only apply @@ -3021,8 +3021,8 @@ protected: * * The following refers to any dimension: * - * This class allows access to a cell, which is a line in 1D and a - * quad in 2D. Cells have more functionality than lines or quads by + * This class allows access to a cell, which is a line in 1d and a + * quad in 2d. Cells have more functionality than lines or quads by * themselves, for example they can be flagged for refinement, they have * neighbors, they have the possibility to check whether they are at the * boundary etc. This class offers access to all this data. @@ -3335,7 +3335,7 @@ public: * for the case of a coarser neighbor. It returns a pair of numbers, face_no * and subface_no, with the following property, if the neighbor is not * refined: cell->neighbor(neighbor)->neighbor_child_on_subface(face_no, - * subface_no)==cell. In 3D, a coarser neighbor can still be refined. + * subface_no)==cell. In 3d, a coarser neighbor can still be refined. * In that case subface_no denotes the child index of the neighbors face * that relates to our face: * cell->neighbor(neighbor)->face(face_no)->child(subface_no)==cell->face(neighbor). diff --git a/include/deal.II/grid/tria_accessor.templates.h b/include/deal.II/grid/tria_accessor.templates.h index 48570e23ed..d3d54f3c12 100644 --- a/include/deal.II/grid/tria_accessor.templates.h +++ b/include/deal.II/grid/tria_accessor.templates.h @@ -995,7 +995,7 @@ namespace internal /** * A helper function to provide faster access to cell->line_index() in - * 3D + * 3d */ template static std::array @@ -1082,7 +1082,7 @@ namespace internal /** * A helper function to provide faster access to - * cell->line_orientation(), 1D specialization + * cell->line_orientation(), 1d specialization */ template static std::array @@ -1096,7 +1096,7 @@ namespace internal /** * A helper function to provide faster access to - * cell->line_orientation(), 2D specialization + * cell->line_orientation(), 2d specialization */ template static std::array @@ -1114,7 +1114,7 @@ namespace internal /** * A helper function to provide faster access to - * cell->line_orientation(), 3D specialization + * cell->line_orientation(), 3d specialization */ template static std::array diff --git a/include/deal.II/grid/tria_description.h b/include/deal.II/grid/tria_description.h index 9214fcf449..c1c4d344a0 100644 --- a/include/deal.II/grid/tria_description.h +++ b/include/deal.II/grid/tria_description.h @@ -363,7 +363,7 @@ namespace TriangulationDescription /** * Manifold id of all lines of the cell. * - * @note Only used for 2D and 3D. + * @note Only used for 2d and 3d. */ std::array::lines_per_cell> manifold_line_ids; @@ -371,7 +371,7 @@ namespace TriangulationDescription /** * Manifold id of all face quads of the cell. * - * @note Only used for 3D. + * @note Only used for 3d. */ std::array::quads_per_cell> diff --git a/include/deal.II/grid/tria_faces.h b/include/deal.II/grid/tria_faces.h index be7e6a2215..7dad91d07b 100644 --- a/include/deal.II/grid/tria_faces.h +++ b/include/deal.II/grid/tria_faces.h @@ -33,8 +33,8 @@ namespace internal * triangulation. These classes are similar to the TriaLevel classes. As * cells are organized in a hierarchical structure of levels, each * triangulation consists of several such TriaLevels. However the faces of - * a triangulation, lower dimensional objects like lines in 2D or lines - * and quads in 3D, do not have to be based on such a hierarchical + * a triangulation, lower dimensional objects like lines in 2d or lines + * and quads in 3d, do not have to be based on such a hierarchical * structure. In fact we have to organise them in only one object if we * want to enable anisotropic refinement. Therefore the TriaFaces classes * store the information belonging to the faces of a triangulation diff --git a/include/deal.II/grid/tria_iterator_selector.h b/include/deal.II/grid/tria_iterator_selector.h index 9b1a08e246..f89bad3331 100644 --- a/include/deal.II/grid/tria_iterator_selector.h +++ b/include/deal.II/grid/tria_iterator_selector.h @@ -48,7 +48,7 @@ namespace internal /** * This class implements some types which differ between the dimensions. - * These are the declarations for the 1D case only. See the + * These are the declarations for the 1d case only. See the * @ref Iterators * module for more information. * @@ -102,7 +102,7 @@ namespace internal /** * This class implements some types which differ between the dimensions. - * These are the declarations for the 2D case only. See the + * These are the declarations for the 2d case only. See the * @ref Iterators * module for more information. * @@ -110,7 +110,7 @@ namespace internal * lines member variable of a Triangulation<2> object. An @p * active_line_iterator only operates on the active lines. @p * raw_line_iterator objects operate on all lines, used or not. Using @p - * active_line_iterators may not be particularly in 2D useful since it + * active_line_iterators may not be particularly in 2d useful since it * only operates on unrefined lines. However, also refined lines may bound * unrefined cells if the neighboring cell is refined once more than the * present one. @@ -160,7 +160,7 @@ namespace internal /** * This class implements some types which differ between the dimensions. - * These are the declarations for the 3D case only. See the + * These are the declarations for the 3d case only. See the * @ref Iterators * module for more information. * diff --git a/include/deal.II/grid/tria_levels.h b/include/deal.II/grid/tria_levels.h index aba0df879c..820501b2ec 100644 --- a/include/deal.II/grid/tria_levels.h +++ b/include/deal.II/grid/tria_levels.h @@ -129,7 +129,7 @@ namespace internal * level=index=-1 is set. * * Conventions: The @p ith neighbor of a cell is the one which - * shares the @p ith face (@p Line in 2D, @p Quad in 3D) of this cell. + * shares the @p ith face (@p Line in 2d, @p Quad in 3d) of this cell. * * The neighbor of a cell has at most the same level as this cell, i.e. * it may or may not be refined. diff --git a/include/deal.II/grid/tria_objects.h b/include/deal.II/grid/tria_objects.h index 0cebb2a953..dd49eead8d 100644 --- a/include/deal.II/grid/tria_objects.h +++ b/include/deal.II/grid/tria_objects.h @@ -187,9 +187,9 @@ namespace internal /** * Return an iterator to the next free slot for a single object. This * function is only used by Triangulation::execute_refinement() - * in 3D. + * in 3d. * - * @warning Interestingly, this function is not used for 1D or 2D + * @warning Interestingly, this function is not used for 1d or 2d * triangulations, where it seems the authors of the refinement function * insist on reimplementing its contents. * @@ -202,9 +202,9 @@ namespace internal /** * Return an iterator to the next free slot for a pair of objects. This * function is only used by Triangulation::execute_refinement() - * in 3D. + * in 3d. * - * @warning Interestingly, this function is not used for 1D or 2D + * @warning Interestingly, this function is not used for 1d or 2d * triangulations, where it seems the authors of the refinement function * insist on reimplementing its contents. * diff --git a/include/deal.II/integrators/maxwell.h b/include/deal.II/integrators/maxwell.h index 593c9b0f47..2babb1e10e 100644 --- a/include/deal.II/integrators/maxwell.h +++ b/include/deal.II/integrators/maxwell.h @@ -207,7 +207,7 @@ namespace LocalIntegrators * \int_Z \nabla \times u \cdot v \,dx. * @f] * - * This is the standard curl operator in 3D and the scalar curl in 2D. The + * This is the standard curl operator in 3d and the scalar curl in 2d. The * vector curl operator can be obtained by exchanging test and trial * functions. */ diff --git a/include/deal.II/lac/scalapack.h b/include/deal.II/lac/scalapack.h index 0bbcb9623a..d2de9857e7 100644 --- a/include/deal.II/lac/scalapack.h +++ b/include/deal.II/lac/scalapack.h @@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN * ScaLAPACK assumes that matrices are distributed according to the * block-cyclic decomposition scheme. An $M$ by $N$ matrix is first decomposed * into $\lceil M / MB \rceil$ by $\lceil N / NB \rceil$ blocks which are then - * uniformly distributed across the 2D process grid with $p q \le Np$ processes, + * uniformly distributed across the 2d process grid with $p q \le Np$ processes, * where $p,q$ are grid dimensions and $Np$ is the total number of processes. * The parameters MB and NB are referred to as row and column block size and * determine the granularity of the block-cyclic distribution. diff --git a/include/deal.II/lac/tensor_product_matrix.h b/include/deal.II/lac/tensor_product_matrix.h index c8758dff41..7a4da66e0c 100644 --- a/include/deal.II/lac/tensor_product_matrix.h +++ b/include/deal.II/lac/tensor_product_matrix.h @@ -40,19 +40,19 @@ class FullMatrix; /** * This is a special matrix class defined as the tensor product (or Kronecker - * product) of 1D matrices of the type + * product) of 1d matrices of the type * @f{align*}{ * L &= A_1 \otimes M_0 + M_1 \otimes A_0 * @f} - * in 2D and + * in 2d and * @f{align*}{ * L &= A_2 \otimes M_1 \otimes M_0 + M_2 \otimes A_1 \otimes M_0 + M_2 \otimes * M_1 \otimes A_0 * @f} - * in 3D. The typical application setting is a discretization of the Laplacian + * in 3d. The typical application setting is a discretization of the Laplacian * $L$ on a Cartesian (axis-aligned) geometry, where it can be exactly - * represented by the Kronecker or tensor product of a 1D mass matrix $M$ and - * a 1D Laplace matrix $A$ in each tensor direction (due to symmetry $M$ and $A$ + * represented by the Kronecker or tensor product of a 1d mass matrix $M$ and + * a 1d Laplace matrix $A$ in each tensor direction (due to symmetry $M$ and $A$ * are the same in each dimension). The dimension of the resulting class is the * product of the one-dimensional matrices. * @@ -95,7 +95,7 @@ class FullMatrix; * @note This class can work with scalar types (float, double) and * VectorizedArray types. * - * @tparam dim Dimension of the problem. Currently, 1D, 2D, and 3D codes are + * @tparam dim Dimension of the problem. Currently, 1D, 2d, and 3d codes are * implemented. * * @tparam Number Arithmetic type of the underlying array elements. Note that the @@ -106,7 +106,7 @@ class FullMatrix; * to perform LAPACK calculations for each vectorization lane, i.e. for the * supported float and double numbers. * - * @tparam n_rows_1d Compile-time number of rows of 1D matrices (only + * @tparam n_rows_1d Compile-time number of rows of 1d matrices (only * valid if the number of rows and columns coincide for each * dimension). By default at -1, which means that the number of rows * is determined at run-time by means of the matrices passed to the @@ -123,7 +123,7 @@ public: using value_type = Number; /** - * The static number of rows of the 1D matrices. For more details, + * The static number of rows of the 1d matrices. For more details, * see the description of the template parameter n_rows_1d. */ static constexpr int n_rows_1d_static = n_rows_1d; @@ -142,8 +142,8 @@ public: const T &derivative_matrix); /** - * Initializes the tensor product matrix by copying the arrays of 1D mass - * matrices @p mass_matrix and 1D derivative matrices @p derivative_matrix into its + * Initializes the tensor product matrix by copying the arrays of 1d mass + * matrices @p mass_matrix and 1d derivative matrices @p derivative_matrix into its * base class counterparts, respectively, and by assembling the regarding * generalized eigenvalues and eigenvectors in eigenvalues * and eigenvectors, respectively. @@ -155,7 +155,7 @@ public: * @warning This class accepts the following types: * "std::array, dim>", "std::array, dim>", * and "Table<2, Number>". In the latter case, we consider the same 1d - * mass matrix @p mass_matrix and the same 1D derivative matrix + * mass matrix @p mass_matrix and the same 1d derivative matrix * @p derivative_matrix for each tensor direction. */ template @@ -164,7 +164,7 @@ public: /** * Return the number of rows of the tensor product matrix - * resulting from the Kronecker product of 1D matrices, which is described + * resulting from the Kronecker product of 1d matrices, which is described * in the main documentation of TensorProductMatrixSymmetricSum. */ unsigned int @@ -172,7 +172,7 @@ public: /** * Return the number of columns of the tensor product matrix - * resulting from the Kronecker product of 1D matrices, which is described + * resulting from the Kronecker product of 1d matrices, which is described * in the main documentation of TensorProductMatrixSymmetricSum. */ unsigned int @@ -343,14 +343,14 @@ namespace internal * A class similar to TensorProductMatrixSymmetricSum. * * The class TensorProductMatrixSymmetricSum stores a - * 1D mass matrix, 1D stiffness matrix, eigenvalues and eigenvectors + * 1d mass matrix, 1d stiffness matrix, eigenvalues and eigenvectors * for each direction. If one uses one TensorProductMatrixSymmetricSum * instance for, e.g., each cell, these quantities are stored * for each cell. There is no possibility to reuse quantities between * TensorProductMatrixSymmetricSum instances even if the values of the * internal data structures might be the same. This class targets the case * of many TensorProductMatrixSymmetricSum instances, where some of them might - * possibly share the underlying 1D matrices and hence re-use the same data. + * possibly share the underlying 1d matrices and hence re-use the same data. * * This class is flexible and allows to interpret the parameter * @p index arbitrarily. In the case of an element-centric patch @@ -429,7 +429,7 @@ public: memory_consumption() const; /** - * Return the number of 1D matrices of each type stored internally. + * Return the number of 1d matrices of each type stored internally. * In the case that no compression could be performed, its value * is the parameter passed to the function reserve() times the * number of dimension. If compression could be performed, the @@ -446,13 +446,13 @@ private: const bool compress_matrices; /** - * Container used to collect 1D matrices if no compression is + * Container used to collect 1d matrices if no compression is * requested. The memory is freed during finalize(). */ std::vector mass_and_derivative_matrices; /** - * Container used during setup to determine the unique 1D + * Container used during setup to determine the unique 1d * matrices. The memory is freed during finalize(). */ std::map< @@ -471,12 +471,12 @@ private: std::vector indices; /** - * Vector of 1D mass matrices. + * Vector of 1d mass matrices. */ AlignedVector mass_matrices; /** - * Vector of 1D derivative matrices. + * Vector of 1d derivative matrices. */ AlignedVector derivative_matrices; diff --git a/include/deal.II/lac/trilinos_precondition.h b/include/deal.II/lac/trilinos_precondition.h index fbe9b42052..d1f6a213a1 100644 --- a/include/deal.II/lac/trilinos_precondition.h +++ b/include/deal.II/lac/trilinos_precondition.h @@ -896,7 +896,7 @@ namespace TrilinosWrappers * that many fill-ins will be added, so that the IC preconditioner comes * closer to a direct sparse Cholesky decomposition. Note, however, that * this will drastically increase the memory requirement, especially - * when the preconditioner is used in 3D. + * when the preconditioner is used in 3d. */ unsigned int ic_fill; @@ -974,7 +974,7 @@ namespace TrilinosWrappers * literature. When @p fill is large, the preconditioner comes closer to * a (direct) sparse LU decomposition. Note, however, that this will * drastically increase the memory requirement, especially when the - * preconditioner is used in 3D. + * preconditioner is used in 3d. * *
  • @p ilu_atol and @p ilu_rtol: These two parameters allow * perturbation of the diagonal of the matrix, which sometimes can help to @@ -1127,7 +1127,7 @@ namespace TrilinosWrappers * that many fill-ins will be added, so that the ILU preconditioner * comes closer to a (direct) sparse LU decomposition. Note, however, * that this will drastically increase the memory requirement, - * especially when the preconditioner is used in 3D. + * especially when the preconditioner is used in 3d. */ unsigned int ilut_fill; diff --git a/include/deal.II/matrix_free/cuda_fe_evaluation.h b/include/deal.II/matrix_free/cuda_fe_evaluation.h index 3fe5af5aeb..39a6214f0f 100644 --- a/include/deal.II/matrix_free/cuda_fe_evaluation.h +++ b/include/deal.II/matrix_free/cuda_fe_evaluation.h @@ -68,7 +68,7 @@ namespace CUDAWrappers * @tparam fe_degree Degree of the tensor prodict finite element with fe_degree+1 * degrees of freedom per coordinate direction * - * @tparam n_q_points_1d Number of points in the quadrature formular in 1D, + * @tparam n_q_points_1d Number of points in the quadrature formular in 1d, * defaults to fe_degree+1 * * @tparam n_components Number of vector components when solving a system of diff --git a/include/deal.II/matrix_free/evaluation_kernels.h b/include/deal.II/matrix_free/evaluation_kernels.h index b5a0d33010..73355187f9 100644 --- a/include/deal.II/matrix_free/evaluation_kernels.h +++ b/include/deal.II/matrix_free/evaluation_kernels.h @@ -3091,7 +3091,7 @@ namespace internal } /* - * Helper function which applies the 1D kernels for on one + * Helper function which applies the 1d kernels for on one * component in a face. normal_dir indicates the direction of the continuous * component of the RT space. std::integral_constant is the * evaluation path, and std::integral_constant below is the diff --git a/include/deal.II/matrix_free/face_info.h b/include/deal.II/matrix_free/face_info.h index 5c23961f02..0ed76703f8 100644 --- a/include/deal.II/matrix_free/face_info.h +++ b/include/deal.II/matrix_free/face_info.h @@ -97,7 +97,7 @@ namespace internal unsigned char subface_index; /** - * In 3D, one of the two cells adjacent to a face might use a different + * In 3d, one of the two cells adjacent to a face might use a different * orientation (also called as face orientation, face flip and face * rotation) than the standard orientation. This variable stores the * values of face orientation, face flip and face diff --git a/include/deal.II/matrix_free/fe_evaluation.h b/include/deal.II/matrix_free/fe_evaluation.h index 94ad871bff..d074724ac5 100644 --- a/include/deal.II/matrix_free/fe_evaluation.h +++ b/include/deal.II/matrix_free/fe_evaluation.h @@ -1429,7 +1429,7 @@ protected: * determinant of the Jacobian and the quadrature weight). In the * @p integrate() call, an integral contribution tested by each basis function * underlying the FEEvaluation object (e.g. the four linear shape functions of - * FE_Q@<2@>(1) in 2D) is computed, which gives the vector entries to be + * FE_Q@<2@>(1) in 2d) is computed, which gives the vector entries to be * summed into the @p dst vector. Note that the above code needs to explicitly * loop over the components in the vectorized array for evaluating the * function, which is necessary for interfacing with a generic Function object @@ -1657,7 +1657,7 @@ protected: * specify the polynomial degree as a template parameter. This guarantees * maximum * efficiency: The evaluation with sum factorization performs a number of nested - * short 1D loops of length equal to the polynomial degree plus one. If the + * short 1d loops of length equal to the polynomial degree plus one. If the * loop bounds are known at compile time, the compiler can unroll loops as * deemed most efficient by its heuristics. At least the innermost loop is * almost always completely unrolled, avoiding the loop overhead. @@ -1881,7 +1881,7 @@ protected: * if the degree is not known at compile time, but performance will usually be * worse by a factor of 2-3. * - * @tparam n_q_points_1d Number of points in the quadrature formula in 1D, + * @tparam n_q_points_1d Number of points in the quadrature formula in 1d, * defaults to fe_degree+1 * * @tparam n_components Number of vector components when solving a system of @@ -2380,7 +2380,7 @@ private: * rather than a compile time constant that slows down the * execution. * - * @tparam n_q_points_1d Number of points in the quadrature formula in 1D, + * @tparam n_q_points_1d Number of points in the quadrature formula in 1d, * usually chosen as fe_degree+1 * * @tparam n_components Number of vector components when solving a system of diff --git a/include/deal.II/matrix_free/fe_evaluation_data.h b/include/deal.II/matrix_free/fe_evaluation_data.h index 03be313a7a..639f1e743e 100644 --- a/include/deal.II/matrix_free/fe_evaluation_data.h +++ b/include/deal.II/matrix_free/fe_evaluation_data.h @@ -314,7 +314,7 @@ public: * Return a read-only pointer to the first field of function hessians on * quadrature points. First comes the xx-component of the hessian for the * first component on all quadrature points, then the yy-component, - * zz-component in (3D), then the xy-component, and so on. Next comes the xx- + * zz-component in (3d), then the xy-component, and so on. Next comes the xx- * component of the second component, and so on. This is related to the * internal data structures used in this class. The raw data after a call to * @p evaluate only contains unit cell operations, so possible @@ -329,7 +329,7 @@ public: * Return a read and write pointer to the first field of function hessians * on quadrature points. First comes the xx-component of the hessian for the * first component on all quadrature points, then the yy-component, - * zz-component in (3D), then the xy-component, and so on. Next comes the + * zz-component in (3d), then the xy-component, and so on. Next comes the * xx-component of the second component, and so on. This is related to the * internal data structures used in this class. The raw data after a call to * @p evaluate only contains unit cell operations, so possible @@ -672,7 +672,7 @@ protected: /** * A pointer to the unit cell shape data, i.e., values, gradients and - * Hessians in 1D at the quadrature points that constitute the tensor + * Hessians in 1d at the quadrature points that constitute the tensor * product. Also contained in matrix_info, but it simplifies code if we * store a reference to it. */ diff --git a/include/deal.II/matrix_free/fe_point_evaluation.h b/include/deal.II/matrix_free/fe_point_evaluation.h index 2d3aa93464..658c9e074f 100644 --- a/include/deal.II/matrix_free/fe_point_evaluation.h +++ b/include/deal.II/matrix_free/fe_point_evaluation.h @@ -622,7 +622,7 @@ private: SmartPointer> fe; /** - * Description of the 1D polynomial basis for tensor product elements used + * Description of the 1d polynomial basis for tensor product elements used * for the fast path of this class using tensor product evaluators. */ std::vector> poly; diff --git a/include/deal.II/matrix_free/hanging_nodes_internal.h b/include/deal.II/matrix_free/hanging_nodes_internal.h index d8be02dc0f..a53ac8cea1 100644 --- a/include/deal.II/matrix_free/hanging_nodes_internal.h +++ b/include/deal.II/matrix_free/hanging_nodes_internal.h @@ -46,7 +46,7 @@ namespace internal * the subcell, or the position of an element along each direction. The * second field determines if there is a constrained face with that * direction as normal. The last field determines if there is a - * constrained edge in that direction (only valid in 3D). + * constrained edge in that direction (only valid in 3d). */ enum class ConstraintKinds : std::uint16_t { @@ -319,7 +319,7 @@ namespace internal private: /** - * Set up line-to-cell mapping for edge constraints in 3D. + * Set up line-to-cell mapping for edge constraints in 3d. */ void setup_line_to_cell(const Triangulation &triangulation); diff --git a/include/deal.II/matrix_free/mapping_data_on_the_fly.h b/include/deal.II/matrix_free/mapping_data_on_the_fly.h index 3d2a6990b3..3848ba5430 100644 --- a/include/deal.II/matrix_free/mapping_data_on_the_fly.h +++ b/include/deal.II/matrix_free/mapping_data_on_the_fly.h @@ -131,7 +131,7 @@ namespace internal get_data_storage(); /** - * Return a reference to 1D quadrature underlying this object. + * Return a reference to 1d quadrature underlying this object. */ const Quadrature<1> & get_quadrature() const; @@ -155,7 +155,7 @@ namespace internal std::unique_ptr> fe_values; /** - * Get 1D quadrature formula to be used for reinitializing shape info. + * Get 1d quadrature formula to be used for reinitializing shape info. */ const Quadrature<1> quadrature_1d; diff --git a/include/deal.II/matrix_free/mapping_info.h b/include/deal.II/matrix_free/mapping_info.h index 0b8b4cb76a..6e6369c026 100644 --- a/include/deal.II/matrix_free/mapping_info.h +++ b/include/deal.II/matrix_free/mapping_info.h @@ -60,7 +60,7 @@ namespace internal * CellIterator::level() and CellIterator::index(), in order to allow * for different kinds of iterators, e.g. standard DoFHandler, * multigrid, etc.) on a fixed Triangulation. In addition, a mapping - * and several 1D quadrature formulas are given. + * and several 1d quadrature formulas are given. */ void initialize( diff --git a/include/deal.II/matrix_free/matrix_free.h b/include/deal.II/matrix_free/matrix_free.h index e4d32de455..5e77a500fa 100644 --- a/include/deal.II/matrix_free/matrix_free.h +++ b/include/deal.II/matrix_free/matrix_free.h @@ -326,7 +326,7 @@ public: * The third option @p color is to use a traditional algorithm of coloring * on the global level. This scheme is a special case of the second option * where only one partition is present. Note that for problems with - * hanging nodes, there are quite many colors (50 or more in 3D), which + * hanging nodes, there are quite many colors (50 or more in 3d), which * might degrade parallel performance (bad cache behavior, many * synchronization points). * diff --git a/include/deal.II/matrix_free/operators.h b/include/deal.II/matrix_free/operators.h index 03de54f81c..b3e1f86d57 100644 --- a/include/deal.II/matrix_free/operators.h +++ b/include/deal.II/matrix_free/operators.h @@ -601,7 +601,7 @@ namespace MatrixFreeOperators * mass matrix on an element for the special case of an evaluation object * with as many quadrature points as there are cell degrees of freedom. It * uses algorithms from FEEvaluation and produces the exact mass matrix for - * DGQ elements. This algorithm uses tensor products of inverse 1D shape + * DGQ elements. This algorithm uses tensor products of inverse 1d shape * matrices over quadrature points, so the inverse operation is exactly as * expensive as applying the forward operator on each cell. Of course, for * continuous finite elements this operation does not produce the inverse of diff --git a/include/deal.II/matrix_free/shape_info.h b/include/deal.II/matrix_free/shape_info.h index 2715745dc5..88d296d349 100644 --- a/include/deal.II/matrix_free/shape_info.h +++ b/include/deal.II/matrix_free/shape_info.h @@ -70,7 +70,7 @@ namespace internal /** * Symmetric tensor product shape functions fulfilling a Hermite * identity with values and first derivatives zero at the element end - * points in 1D. + * points in 1d. */ tensor_symmetric_hermite = 1, @@ -152,7 +152,7 @@ namespace internal ElementType element_type; /** - * Stores the shape values of the 1D finite element evaluated at all 1D + * Stores the shape values of the 1d finite element evaluated at all 1d * quadrature points. The length of * this array is n_dofs_1d * n_q_points_1d and quadrature * points are the index running fastest. @@ -160,16 +160,16 @@ namespace internal AlignedVector shape_values; /** - * Stores the shape gradients of the 1D finite element evaluated at all - * 1D quadrature points. The length of + * Stores the shape gradients of the 1d finite element evaluated at all + * 1d quadrature points. The length of * this array is n_dofs_1d * n_q_points_1d and quadrature * points are the index running fastest. */ AlignedVector shape_gradients; /** - * Stores the shape Hessians of the 1D finite element evaluated at all - * 1D quadrature points. The length of + * Stores the shape Hessians of the 1d finite element evaluated at all + * 1d quadrature points. The length of * this array is n_dofs_1d * n_q_points_1d and quadrature * points are the index running fastest. */ @@ -232,7 +232,7 @@ namespace internal * with the `_collocation` fields. The size of the array equals the * layout of the `shape_values` array, and it is combined with the shape * values array such that this matrix is the pseudo inverse of - * shape_values. In case the number of 1D quadrature points equals the + * shape_values. In case the number of 1d quadrature points equals the * size of the basis, this array is exactly the inverse of the * shape_values array. The length of this array is n_dofs_1d * * n_q_points_1d and quadrature points are the index running @@ -246,14 +246,14 @@ namespace internal AlignedVector inverse_shape_values_eo; /** - * Collects all data of 1D shape values evaluated at the point 0 and 1 + * Collects all data of 1d shape values evaluated at the point 0 and 1 * (the vertices) in one data structure. The sorting of data is to * start with the values, then gradients, then second derivatives. */ std::array, 2> shape_data_on_face; /** - * Collects all data of 1D nodal shape values (defined by the Lagrange + * Collects all data of 1d nodal shape values (defined by the Lagrange * polynomials in the points of the quadrature rule) evaluated at the * point 0 and 1 (the vertices) in one data structure. * @@ -282,7 +282,7 @@ namespace internal std::array, 2> hessians_within_subface; /** - * A 1D subface interpolation matrices to the first and second quadrant. + * A 1d subface interpolation matrices to the first and second quadrant. * This data structure is only set up for FE_Q for dim > 1. */ std::array, 2> subface_interpolation_matrices; @@ -391,7 +391,7 @@ namespace internal /** * Compute a table with numbers of re-orientation for all versions of - * face flips, orientation, and rotation (relating only to 3D elements). + * face flips, orientation, and rotation (relating only to 3d elements). */ static Table<2, unsigned int> compute_orientation_table(const unsigned int n_points_per_dim); @@ -487,7 +487,7 @@ namespace internal * @p dofs_per_face entries. * * The indices stored in this member variable are as follows. Consider - * for example a 2D element of degree 3 with the following degrees of + * for example a 2d element of degree 3 with the following degrees of * freedom in lexicographic numbering: * @code * 12 13 14 15 @@ -501,7 +501,7 @@ namespace internal * 3, 7, 11, 15 for face 1, the third row holds the indices * 0, 1, 2, 3 for face 2, and the last (fourth) row holds * the indices 12, 13, 14, 15. Similarly, the indices are - * stored in 3D. (Note that the y faces in 3D use indices reversed in + * stored in 3d. (Note that the y faces in 3d use indices reversed in * terms of the lexicographic numbers due to the orientation of the * coordinate system.) * @@ -525,7 +525,7 @@ namespace internal * face and the derivatives, using 2*dofs_per_face entries. * * The indices stored in this member variable are as follows. Consider - * for example a 2D element of degree 3 with the following degrees of + * for example a 2d element of degree 3 with the following degrees of * freedom in lexicographic numbering: * @code * 20 21 22 23 24 @@ -541,8 +541,8 @@ namespace internal * 19, 18, 24, 23 for face 1, the third row holds the indices * 0, 5, 1, 6, 2, 7, 3, 8, 4, 9 for face 2, and the last * (fourth) row holds the indices 20, 15, 21, 16, 22, 17, 23, 18, - * 24, 19. Similarly, the indices are stored in 3D. (Note that - * the y faces in 3D use indices reversed in terms of the lexicographic + * 24, 19. Similarly, the indices are stored in 3d. (Note that + * the y faces in 3d use indices reversed in terms of the lexicographic * numbers due to the orientation of the coordinate system.) * * @note This object is only filled in case @p element_type evaluates to @@ -576,7 +576,7 @@ namespace internal UnivariateShapeData &univariate_shape_data); /** - * Check whether symmetric 1D basis functions are such that the shape + * Check whether symmetric 1d basis functions are such that the shape * values form a diagonal matrix, i.e., the nodal points are collocated * with the quadrature points. This allows for specialized algorithms * that save some operations in the evaluation. diff --git a/include/deal.II/matrix_free/tensor_product_kernels.h b/include/deal.II/matrix_free/tensor_product_kernels.h index 369471596d..8613bd14b2 100644 --- a/include/deal.II/matrix_free/tensor_product_kernels.h +++ b/include/deal.II/matrix_free/tensor_product_kernels.h @@ -278,7 +278,7 @@ namespace internal /** * This function applies the tensor product kernel, corresponding to a - * multiplication of 1D stripes, along the given @p direction of the tensor + * multiplication of 1d stripes, along the given @p direction of the tensor * data in the input array. This function allows the @p in and @p out * arrays to alias for the case n_rows == n_columns, i.e., it is safe to * perform the contraction in place where @p in and @p out point to the @@ -291,7 +291,7 @@ namespace internal * array, otherwise it sums over the columns * @tparam add If true, the result is added to the output vector, else * the computed values overwrite the content in the output - * @tparam one_line If true, the kernel is only applied along a single 1D + * @tparam one_line If true, the kernel is only applied along a single 1d * stripe within a dim-dimensional tensor, not the full * n_rows^dim points as in the @p false case. * @@ -1786,7 +1786,7 @@ namespace internal * This class implements a different approach to the symmetric case for * values, gradients, and Hessians also treated with the above functions: It * is possible to reduce the cost per dimension from N^2 to N^2/2, where N - * is the number of 1D dofs (there are only N^2/2 different entries in the + * is the number of 1d dofs (there are only N^2/2 different entries in the * shape matrix, so this is plausible). The approach is based on the idea of * applying the operator on the even and odd part of the input vectors * separately, given that the shape functions evaluated on quadrature points @@ -1929,7 +1929,7 @@ namespace internal /** * This function applies the tensor product kernel, corresponding to a - * multiplication of 1D stripes, along the given @p direction of the tensor + * multiplication of 1d stripes, along the given @p direction of the tensor * data in the input array. This function allows the @p in and @p out * arrays to alias for the case n_rows == n_columns, i.e., it is safe to * perform the contraction in place where @p in and @p out point to the @@ -1946,7 +1946,7 @@ namespace internal * shape values (type=0), shape gradients (type=1) or * second derivatives (type=2, similar to type 0 but * without two additional zero entries) - * @tparam one_line If true, the kernel is only applied along a single 1D + * @tparam one_line If true, the kernel is only applied along a single 1d * stripe within a dim-dimensional tensor, not the full * n_rows^dim points as in the @p false case. * @@ -2128,7 +2128,7 @@ namespace internal * the Legendre basis, with symmetric shape functions in the even slots * (rows of the values array) and point-symmetric in the odd slots. Like the * even-odd decomposition, the number of operations are N^2/2 rather than - * N^2 FMAs (fused multiply-add), where N is the number of 1D dofs. The + * N^2 FMAs (fused multiply-add), where N is the number of 1d dofs. The * difference is in the way the input and output quantities are symmetrized. * * @tparam dim Space dimension in which this class is applied @@ -2253,7 +2253,7 @@ namespace internal /** * This function applies the tensor product kernel, corresponding to a - * multiplication of 1D stripes, along the given @p direction of the tensor + * multiplication of 1d stripes, along the given @p direction of the tensor * data in the input array. This function allows the @p in and @p out * arrays to alias for the case n_rows == n_columns, i.e., it is safe to * perform the contraction in place where @p in and @p out point to the @@ -2269,7 +2269,7 @@ namespace internal * @tparam type Determines whether the evaluation is symmetric in even * rows (type=0) or odd rows (type=1) of @p shape_data and * skew-symmetric in odd rows (type=0) or even rows (type=1) - * @tparam one_line If true, the kernel is only applied along a single 1D + * @tparam one_line If true, the kernel is only applied along a single 1d * stripe within a dim-dimensional tensor, not the full * n_rows^dim points as in the @p false case. * @@ -2497,7 +2497,7 @@ namespace internal /** - * Internal evaluator for shape function in 2D and 3D using the + * Internal evaluator for shape function in 2d and 3d using the * tensor product form of the anisotropic basis functions of the * raviart-thomas element, with degree k+1 in normal direction and * k in tangential direction. @@ -2598,7 +2598,7 @@ namespace internal /** * This function applies the tensor product kernel, corresponding to a - * multiplication of 1D stripes, along the given @p direction of the tensor + * multiplication of 1d stripes, along the given @p direction of the tensor * data in the input array. This function allows the @p in and @p out * arrays to alias for the case n_rows == n_columns, i.e., it is safe to * perform the contraction in place where @p in and @p out point to the @@ -2615,7 +2615,7 @@ namespace internal * RT space in terms of the normal onto the face, e.g * 0 if the is in x-direction, 1 if in y-direction * etc. - * @tparam one_line If true, the kernel is only applied along a single 1D + * @tparam one_line If true, the kernel is only applied along a single 1d * stripe within a dim-dimensional tensor, not the full * n_rows^dim points as in the @p false case. * @@ -2987,7 +2987,7 @@ namespace internal * $\varphi_i$ given a vector of coefficients $u_i$ in the form * $u_h(\mathbf{x}) = \sum_{i=1}^{k^d} \varphi_i(\mathbf{x}) u_i$. The shape * functions $\varphi_i(\mathbf{x}) = - * \prod_{d=1}^{\text{dim}}\varphi_{i_d}^\text{1D}(x_d)$ represent a tensor + * \prod_{d=1}^{\text{dim}}\varphi_{i_d}^\text{1d}(x_d)$ represent a tensor * product. The function returns a pair with the value of the interpolation * as the first component and the gradient in reference coordinates as the * second component. Note that for compound types (e.g. the `values` field @@ -2997,7 +2997,7 @@ namespace internal * function. * * @param poly The underlying one-dimensional polynomial basis - * $\{\varphi^{1D}_{i_1}\}$ given as a vector of polynomials. + * $\{\varphi^{1d}_{i_1}\}$ given as a vector of polynomials. * * @param values The expansion coefficients $u_i$ of type `Number` in * the polynomial interpolation. The coefficients can be simply `double` @@ -3007,8 +3007,8 @@ namespace internal * @param p The position in reference coordinates where the interpolation * should be evaluated. * - * @param d_linear Flag to specify whether a d-linear (linear in 1D, - * bi-linear in 2D, tri-linear in 3D) interpolation should be made, which + * @param d_linear Flag to specify whether a d-linear (linear in 1d, + * bi-linear in 2d, tri-linear in 3d) interpolation should be made, which * allows to unroll loops and considerably speed up evaluation. * * @param renumber Optional parameter to specify a renumbering in the diff --git a/include/deal.II/multigrid/mg_transfer_global_coarsening.h b/include/deal.II/multigrid/mg_transfer_global_coarsening.h index a0b19e9845..352080978b 100644 --- a/include/deal.II/multigrid/mg_transfer_global_coarsening.h +++ b/include/deal.II/multigrid/mg_transfer_global_coarsening.h @@ -384,7 +384,7 @@ private: AlignedVector> prolongation_matrix; /** - * 1D prolongation matrix for tensor-product elements. + * 1d prolongation matrix for tensor-product elements. */ AlignedVector> prolongation_matrix_1d; @@ -394,7 +394,7 @@ private: AlignedVector> restriction_matrix; /** - * 1D restriction matrix for tensor-product elements. + * 1d restriction matrix for tensor-product elements. */ AlignedVector> restriction_matrix_1d; diff --git a/include/deal.II/multigrid/mg_transfer_internal.h b/include/deal.II/multigrid/mg_transfer_internal.h index df015f282a..7d3fe89536 100644 --- a/include/deal.II/multigrid/mg_transfer_internal.h +++ b/include/deal.II/multigrid/mg_transfer_internal.h @@ -86,7 +86,7 @@ namespace internal /** * A variable storing whether the element is continuous and there is a - * joint degree of freedom in the center of the 1D line. + * joint degree of freedom in the center of the 1d line. */ bool element_is_continuous; diff --git a/include/deal.II/multigrid/mg_transfer_matrix_free.h b/include/deal.II/multigrid/mg_transfer_matrix_free.h index af0f3ff9f3..535226f218 100644 --- a/include/deal.II/multigrid/mg_transfer_matrix_free.h +++ b/include/deal.II/multigrid/mg_transfer_matrix_free.h @@ -209,7 +209,7 @@ private: /** * A variable storing whether the element is continuous and there is a joint - * degree of freedom in the center of the 1D line. + * degree of freedom in the center of the 1d line. */ bool element_is_continuous; diff --git a/include/deal.II/non_matching/fe_values.h b/include/deal.II/non_matching/fe_values.h index 5778208315..1ca47ef735 100644 --- a/include/deal.II/non_matching/fe_values.h +++ b/include/deal.II/non_matching/fe_values.h @@ -184,7 +184,7 @@ namespace NonMatching * @param q_collection Collection of Quadrature rules over $[0, 1]^{dim}$ * that should be used when a cell is not intersected and we do not need to * generate immersed quadrature rules. - * @param q_collection_1D Collection of 1-dimensional quadrature rules used + * @param q_collection_1d Collection of 1-dimensional quadrature rules used * to generate the immersed quadrature rules. See the QuadratureGenerator * class. * @param mesh_classifier Object used to determine when the immersed @@ -206,7 +206,7 @@ namespace NonMatching FEValues(const hp::MappingCollection &mapping_collection, const hp::FECollection & fe_collection, const hp::QCollection & q_collection, - const hp::QCollection<1> & q_collection_1D, + const hp::QCollection<1> & q_collection_1d, const RegionUpdateFlags region_update_flags, const MeshClassifier & mesh_classifier, const DoFHandler & dof_handler, @@ -478,7 +478,7 @@ namespace NonMatching * @param q_collection Collection of Quadrature rules over $[0, 1]^{dim-1}$ * that should be used when a face is not intersected and we do not need to * generate immersed quadrature rules. - * @param q_collection_1D Collection of 1-dimensional quadrature rules used + * @param q_collection_1d Collection of 1-dimensional quadrature rules used * to generate the immersed quadrature rules. See the QuadratureGenerator * class. * @param mesh_classifier Object used to determine when the immersed @@ -500,7 +500,7 @@ namespace NonMatching FEInterfaceValues(const hp::MappingCollection &mapping_collection, const hp::FECollection & fe_collection, const hp::QCollection & q_collection, - const hp::QCollection<1> & q_collection_1D, + const hp::QCollection<1> & q_collection_1d, const RegionUpdateFlags region_update_flags, const MeshClassifier & mesh_classifier, const DoFHandler & dof_handler, diff --git a/include/deal.II/non_matching/quadrature_generator.h b/include/deal.II/non_matching/quadrature_generator.h index dc550cbfed..75db3d4263 100644 --- a/include/deal.II/non_matching/quadrature_generator.h +++ b/include/deal.II/non_matching/quadrature_generator.h @@ -159,19 +159,19 @@ namespace NonMatching * The underlying algorithm use a 1-dimensional quadrature rule as base for * creating the immersed quadrature rules. Gauss-Legendre quadrature * (QGauss) is recommended. The constructor takes an hp::QCollection<1>. - * One can select which 1D-quadrature in the collection should be used - * through the set_1D_quadrature() function. The number of quadrature points + * One can select which 1d-quadrature in the collection should be used + * through the set_1d_quadrature() function. The number of quadrature points * in the constructed quadratures will vary depending on the level set * function. More quadrature points will be created if the intersection is * "bad", for example, if the zero-contour has a high curvature compared to - * the size of the box. However, if the number of points in the 1D quadrature + * the size of the box. However, if the number of points in the 1d quadrature * is $n$ the number of points will be proportional to $n^{dim}$ in the bulk * quadratures and to $n^{dim-1}$ in the surface quadrature. For example, - * in the 2D-example in the above figure, there are 2 points in the - * 1D-quadrature. If the 1D-quadrature is a Gauss-Legendre quadrature and the + * in the 2d-example in the above figure, there are 2 points in the + * 1d-quadrature. If the 1d-quadrature is a Gauss-Legendre quadrature and the * grid has size $h$, the immersed quadratures typically give global errors * proportional to $h^{2n}$, both for the bulk and surface integrals. If the - * 1D-quadrature has positive weights, the weights of the immersed quadratures + * 1d-quadrature has positive weights, the weights of the immersed quadratures * will also be positive. * * A detailed description of the underlying algorithm can be found in @@ -191,10 +191,10 @@ namespace NonMatching using AdditionalData = AdditionalQGeneratorData; /** - * Constructor. Each Quadrature<1> in @p quadratures1D can be chosen as base + * Constructor. Each Quadrature<1> in @p quadratures1d can be chosen as base * for generating the immersed quadrature rules. * - * @note It is important that each 1D-quadrature rule in the + * @note It is important that each 1d-quadrature rule in the * hp::QCollection does not contain the points 0 and 1. */ QuadratureGenerator( @@ -246,7 +246,7 @@ namespace NonMatching get_surface_quadrature() const; /** - * Set which 1D-quadrature in the collection passed to the constructor + * Set which 1d-quadrature in the collection passed to the constructor * should be used to create the immersed quadratures. */ void @@ -284,7 +284,7 @@ namespace NonMatching * function, $\phi$. It then creates the (dim-1)-dimensional quadratures by * calling QuadratureGenerator with $\phi$. This means that what holds for the * QuadratureGenerator class in general also holds for this class. In - * particular, if the 1D-quadrature that is used as base contains $n$ points, + * particular, if the 1d-quadrature that is used as base contains $n$ points, * the number of points will be proportional to $n^{dim-1}$ in the in the * inside/outside quadratures and to $n^{dim-2}$ in the surface quadrature. */ @@ -295,10 +295,10 @@ namespace NonMatching using AdditionalData = AdditionalQGeneratorData; /** - * Constructor. Each Quadrature<1> in @p quadratures1D can be chosen as base + * Constructor. Each Quadrature<1> in @p quadratures1d can be chosen as base * for generating the immersed quadrature rules. * - * @note It is important that each 1D-quadrature rule in the + * @note It is important that each 1d-quadrature rule in the * hp::QCollection does not contain the points 0 and 1. */ FaceQuadratureGenerator( @@ -352,7 +352,7 @@ namespace NonMatching get_surface_quadrature() const; /** - * Set which 1D-quadrature in the collection passed to the constructor + * Set which 1d-quadrature in the collection passed to the constructor * should be used to create the immersed quadratures. */ void @@ -377,7 +377,7 @@ namespace NonMatching * Specialization of the FaceQuadratureGenerator class for the 1-dimensional * case. * - * In 1D, a face is only a point. Thus to generate the immersed + * In 1d, a face is only a point. Thus to generate the immersed * quadrature rules we add a single 0-dimensional quadrature point to the * inside or outside quadrature rule depending on if the level set function is * positive or negative at the face. The added quadrature point will have @@ -385,7 +385,7 @@ namespace NonMatching * to integrating over a dim-1 dimensional curve. Thus, surface quadrature * generated by this specialized class is always empty. * - * This class must be specialized in 1D, because the general + * This class must be specialized in 1d, because the general * FaceQuadratureGenerator class uses the QuadratureGenerator * class internally, which does not make sense when dim-1 = 0. */ @@ -434,7 +434,7 @@ namespace NonMatching * $\{x \in F : \psi(x) = 0 \}$ * where, $F$ is the face of the BoundingBox passed to generate(). * - * @note In 1D, this quadrature always contains 0 points. + * @note In 1d, this quadrature always contains 0 points. */ const ImmersedSurfaceQuadrature<0, 1> & get_surface_quadrature() const; @@ -464,7 +464,7 @@ namespace NonMatching /** * Quadrature for the region * $\{x \in F : \psi(x) = 0 \}$. - * This quadrature always contains zero points in 1D. + * This quadrature always contains zero points in 1d. */ const ImmersedSurfaceQuadrature<0, 1> surface_quadrature; }; @@ -799,16 +799,16 @@ namespace NonMatching * $dim=spacedim$, points for the surface quadrature. * * For each lower dimensional quadrature point, $(x_I, w_I)$ in the - * indefinite quadrature, we create several 1D-level set functions by + * indefinite quadrature, we create several 1d-level set functions by * restricting $\psi_j$ to $x_I$. We then partition the interval $[L, R]$ * into $[y_0, y_1, ..., y_n]$, where $y_0 = L$, $y_n = R$, and the - * remaining $y_i$ are the roots of the 1D-level set functions in + * remaining $y_i$ are the roots of the 1d-level set functions in * $[L, R]$. Since the level set functions change sign between the * roots, each interval belong to different regions in the quadrature * partitioning. * * In each interval, $[y_i, y_{i+1}]$, we distribute points - * according to the 1D-base quadrature, $(x_q, w_q)$ and take the + * according to the 1d-base quadrature, $(x_q, w_q)$ and take the * cartesian product with $(x_I, w_I)$ to create the $dim$-dimensional * quadrature points, $(X_q, W_q)$: * $X_q = x_I \times (y_i + (y_{i+1} - y_i) x_q)$, @@ -849,7 +849,7 @@ namespace NonMatching QPartitioning & q_partitioning); /** - * Set which 1D-quadrature in the collection passed to the constructor + * Set which 1d-quadrature in the collection passed to the constructor * should be used to create the immersed quadratures. */ void @@ -892,13 +892,13 @@ namespace NonMatching unsigned int q_index; /** - * 1D-functions, that are restrictions of each dim-dimensional level set + * 1d-functions, that are restrictions of each dim-dimensional level set * function passed to generate() to some $(dim-1)$-dimensional point. */ std::vector> point_restrictions; /** - * Class used to find the roots of the above 1D-restictions. + * Class used to find the roots of the above 1d-restictions. */ RootFinder root_finder; @@ -980,13 +980,13 @@ namespace NonMatching const AdditionalQGeneratorData additional_data; /** - * Which 1D-quadrature in the collection we should use to generate + * Which 1d-quadrature in the collection we should use to generate * the immersed quadrature. */ unsigned int q_index; /** - * Index of the quadrature in q_collection1D that should use to + * Index of the quadrature in q_collection1d that should use to * generate the immersed quadrature rules. */ const SmartPointer> q_collection1D; @@ -1108,7 +1108,7 @@ namespace NonMatching const unsigned int n_box_splits); /** - * Set which 1D-quadrature in the collection passed to the constructor + * Set which 1d-quadrature in the collection passed to the constructor * should be used to create the immersed quadratures. */ void @@ -1183,21 +1183,21 @@ namespace NonMatching /** * Stores tensor products of each of the Quadrature<1>'s in - * q_collection1D. + * q_collection1d. */ hp::QCollection tensor_products; }; /** - * The 1D-base case of the recursive algorithm QGenerator. + * The 1d-base case of the recursive algorithm QGenerator. * * Let $L$ and $R$ be the left and right bounds of the one-dimensional * BoundingBox. This interval is partitioned into $[x_0, x_1, ..., x_n]$ * where $x_0 = L$, $x_n = R$, and the remaining $x_i$ are the roots * of the level set functions in the interval $[L, R]$. In each interval, * $[x_i, x_{i+1}]$, quadrature points are distributed according to a - * 1D-quadrature rule. These points are added to one of the regions of + * 1d-quadrature rule. These points are added to one of the regions of * QPartitioning determined from the signs of the level set * functions on the interval (see documentation of QPartitioning). * @@ -1227,7 +1227,7 @@ namespace NonMatching const unsigned int n_box_splits); /** - * Set which 1D-quadrature in the collection passed to the constructor + * Set which 1d-quadrature in the collection passed to the constructor * should be used to create the immersed quadratures. */ void @@ -1255,7 +1255,7 @@ namespace NonMatching /** * This would be the height-function direction in higher dimensions, - * but in 1D there is only one coordinate direction. + * but in 1d there is only one coordinate direction. */ const unsigned int direction = 0; @@ -1269,12 +1269,12 @@ namespace NonMatching /** - * Take the tensor product between (point, weight) and @p quadrature1D + * Take the tensor product between (point, weight) and @p quadrature1d * scaled over [start, end] and add the resulting dim-dimensional * quadrature points to @p quadrature. * * @p component_in_dim specifies which dim-dimensional coordinate - * quadrature1D should be written to. + * quadrature1d should be written to. */ template void diff --git a/include/deal.II/numerics/data_out_resample.h b/include/deal.II/numerics/data_out_resample.h index d7cd72735a..af6eb4afb6 100644 --- a/include/deal.II/numerics/data_out_resample.h +++ b/include/deal.II/numerics/data_out_resample.h @@ -34,11 +34,11 @@ DEAL_II_NAMESPACE_OPEN * A DataOut-like class which interpolates values defined on one Triangulation * onto a second potentially unrelated Triangulation. By using this class, * one can output the result obtained on an unstructured mesh onto a - * structured one or one can create a slice in 3D. + * structured one or one can create a slice in 3d. * * The following code snippet shows the steps how to use the class when the * solution is given for a three dimensional triangulation and the result - * should be outputted on a (2D) slice: + * should be outputted on a (2d) slice: * @code * // setup and first usage * DataOutResample<3, 2, 3> data_out(patch_tria,patch_mapping); diff --git a/include/deal.II/numerics/tensor_product_matrix_creator.h b/include/deal.II/numerics/tensor_product_matrix_creator.h index c2d5a24a2f..d17e1710c1 100644 --- a/include/deal.II/numerics/tensor_product_matrix_creator.h +++ b/include/deal.II/numerics/tensor_product_matrix_creator.h @@ -54,7 +54,7 @@ namespace TensorProductMatrixCreator }; /** - * Create 1D mass matrix and 1D derivative matrix for a scalar + * Create 1d mass matrix and 1d derivative matrix for a scalar * constant-coefficient * Laplacian for a @p dim dimensional Cartesian cell. Its boundary types * can be specified with @p boundary_ids. The cell extent (including the cell extent diff --git a/include/deal.II/numerics/vector_tools.h b/include/deal.II/numerics/vector_tools.h index 75ab8fdb1a..85738aef45 100644 --- a/include/deal.II/numerics/vector_tools.h +++ b/include/deal.II/numerics/vector_tools.h @@ -244,10 +244,10 @@ DEAL_II_NAMESPACE_OPEN * want to choose a quadrature formula with more quadrature points or one with * another distribution of the quadrature points in this case. You should also * take into account the superconvergence properties of finite elements in - * some points: for example in 1D, the standard finite element method is a + * some points: for example in 1d, the standard finite element method is a * collocation method and should return the exact value at nodal points. * Therefore, the trapezoidal rule should always return a vanishing L-infinity - * error. Conversely, in 2D the maximum L-infinity error should be located at + * error. Conversely, in 2d the maximum L-infinity error should be located at * the vertices or at the center of the cell, which would make it plausible to * use the Simpson quadrature rule. On the other hand, there may be * superconvergence at Gauss integration points. These examples are not diff --git a/include/deal.II/numerics/vector_tools_boundary.h b/include/deal.II/numerics/vector_tools_boundary.h index 8a4c7e1db1..50a724aefd 100644 --- a/include/deal.II/numerics/vector_tools_boundary.h +++ b/include/deal.II/numerics/vector_tools_boundary.h @@ -566,9 +566,9 @@ namespace VectorTools *

    Computing constraints

    * * To compute the constraints we use a projection method based upon the - * paper mentioned above. In 2D this is done in a single stage for the edge- + * paper mentioned above. In 2d this is done in a single stage for the edge- * based shape functions, regardless of the order of the finite element. In - * 3D this is done in two stages, edges first and then faces. + * 3d this is done in two stages, edges first and then faces. * * For each cell, each edge, $e$, is projected by solving the linear system * $Ax=b$ where $x$ is the vector of constraints on degrees of freedom on the @@ -621,7 +621,7 @@ namespace VectorTools * The second argument of this function denotes the first vector component * of the finite element which corresponds to the vector function that you * wish to constrain. For example, if we are solving Maxwell's equations in - * 3D and have components $(E_x,E_y,E_z,B_x,B_y,B_z)$ and we want the + * 3d and have components $(E_x,E_y,E_z,B_x,B_y,B_z)$ and we want the * boundary conditions $\vec{n}\times\vec{B}=\vec{n}\times\vec{f}$, then @p * first_vector_component would be 3. The @p boundary_function must return 6 * components in this example, with the first 3 corresponding to $\vec{E}$ diff --git a/source/dofs/dof_handler.cc b/source/dofs/dof_handler.cc index 0e91d85544..072f6ad07e 100644 --- a/source/dofs/dof_handler.cc +++ b/source/dofs/dof_handler.cc @@ -504,7 +504,7 @@ namespace internal dof_handler.mg_levels.back()->dof_object.dofs = std::vector( tria.n_raw_quads(i) * - fe.n_dofs_per_quad(0 /*note: in 2D there is only one quad*/), + fe.n_dofs_per_quad(0 /*note: in 2d there is only one quad*/), numbers::invalid_dof_index); } diff --git a/source/dofs/dof_handler_policy.cc b/source/dofs/dof_handler_policy.cc index 341e69923b..c05d87f198 100644 --- a/source/dofs/dof_handler_policy.cc +++ b/source/dofs/dof_handler_policy.cc @@ -2466,8 +2466,8 @@ namespace internal /** * The part of the renumber_mg_dofs() functionality that operates on - * faces. There only needs to happen something if we are in 2D or 3D, so - * we need to separate out the 1D case. + * faces. There only needs to happen something if we are in 2d or 3d, so + * we need to separate out the 1d case. * * See renumber_mg_dofs() for the meaning of the arguments. */ diff --git a/source/fe/fe_poly_tensor.cc b/source/fe/fe_poly_tensor.cc index 62bb78a6e0..dca1c22c84 100644 --- a/source/fe/fe_poly_tensor.cc +++ b/source/fe/fe_poly_tensor.cc @@ -490,7 +490,7 @@ FE_PolyTensor::fill_fe_values( { /* * This assumes that the dofs are ordered by first vertices, lines, quads - * and volume dofs. Note that in 2D this always gives false. + * and volume dofs. Note that in 2d this always gives false. */ const bool is_quad_dof = (dim == 2 ? false : @@ -1119,7 +1119,7 @@ FE_PolyTensor::fill_fe_face_values( { /* * This assumes that the dofs are ordered by first vertices, lines, quads - * and volume dofs. Note that in 2D this always gives false. + * and volume dofs. Note that in 2d this always gives false. */ const bool is_quad_dof = (dim == 2 ? false : @@ -1804,7 +1804,7 @@ FE_PolyTensor::fill_fe_subface_values( { /* * This assumes that the dofs are ordered by first vertices, lines, quads - * and volume dofs. Note that in 2D this always gives false. + * and volume dofs. Note that in 2d this always gives false. */ const bool is_quad_dof = (dim == 2 ? false : diff --git a/source/fe/fe_q_hierarchical.cc b/source/fe/fe_q_hierarchical.cc index 9b75a979ee..3797fdbc82 100644 --- a/source/fe/fe_q_hierarchical.cc +++ b/source/fe/fe_q_hierarchical.cc @@ -2046,7 +2046,7 @@ FE_Q_Hierarchical::hierarchic_to_fe_q_hierarchical_numbering( for (unsigned int i = 0; i < fe.n_dofs_per_line(); ++i) h2l[next_index++] = n + 2 + i; // inside quad - Assert(fe.n_dofs_per_quad(0 /*only one quad in 2D*/) == + Assert(fe.n_dofs_per_quad(0 /*only one quad in 2d*/) == fe.n_dofs_per_line() * fe.n_dofs_per_line(), ExcInternalError()); for (unsigned int i = 0; i < fe.n_dofs_per_line(); ++i) @@ -2216,7 +2216,7 @@ FE_Q_Hierarchical::has_support_on_face(const unsigned int shape_index, // have no support no-where on // the boundary if (((dim == 2) && (shape_index >= - this->get_first_quad_index(0 /*only one quad in 2D*/))) || + this->get_first_quad_index(0 /*only one quad in 2d*/))) || ((dim == 3) && (shape_index >= this->get_first_hex_index()))) return false; diff --git a/source/grid/grid_generator.cc b/source/grid/grid_generator.cc index eb21f2751d..26c9e3995d 100644 --- a/source/grid/grid_generator.cc +++ b/source/grid/grid_generator.cc @@ -2275,9 +2275,9 @@ namespace GridGenerator } /* - * Verify that the edge points to the right in 1D, vectors are oriented in - * a counter clockwise direction in 2D, or form a right handed system in - * 3D. + * Verify that the edge points to the right in 1d, vectors are oriented in + * a counter clockwise direction in 2d, or form a right handed system in + * 3d. */ bool twisted_data = false; switch (dim) @@ -6623,8 +6623,8 @@ namespace GridGenerator * * @warning even though this function is implemented for structdim 1 and * structdim 2, it will produce wrong results when called for - * boundary lines in 3D in most cases since a boundary line can be shared - * by an arbitrary number of cells in 3D. + * boundary lines in 3d in most cases since a boundary line can be shared + * by an arbitrary number of cells in 3d. */ template void @@ -7852,12 +7852,12 @@ namespace GridGenerator in_tria.n_global_levels() > 1 ? temp_tria : in_tria; /* static tables with the definitions of cells, faces and edges by its - * vertices for 2D and 3D. For the inheritance of the manifold_id, + * vertices for 2d and 3d. For the inheritance of the manifold_id, * definitions of inner-faces and boundary-faces are required. In case of - * 3D, also inner-edges and boundary-edges need to be defined. + * 3d, also inner-edges and boundary-edges need to be defined. */ - /* Cell definition 2D: + /* Cell definition 2d: * A quadrilateral element is converted to 8 simplices elements. Each * triangle is defined by 3 vertices. */ @@ -7870,7 +7870,7 @@ namespace GridGenerator {{8, 5, 7}}, {{3, 7, 5}}}}; - /* Cell definition 3D: + /* Cell definition 3d: * A hexahedron element is converted to 24 tetrahedron elements. Each * tetrahedron is defined by 4 vertices. */ @@ -7884,7 +7884,7 @@ namespace GridGenerator {{13, 9, 11, 7}}, {{13, 11, 8, 6}}, {{10, 12, 9, 1}}, {{9, 12, 11, 3}}, {{11, 12, 8, 2}}, {{8, 12, 10, 0}}}}; - /* Boundary-faces 2D: + /* Boundary-faces 2d: * After converting, each of the 4 quadrilateral faces is defined by faces * of 2 different triangles, i.e., lines. Note that lines are defined by 2 * vertices. @@ -7895,7 +7895,7 @@ namespace GridGenerator {{{{0, 6}}, {{6, 1}}}}, {{{{2, 7}}, {{7, 3}}}}}}; - /* Boundary-faces 3D: + /* Boundary-faces 3d: * After converting, each of the 6 hexahedron faces corresponds to faces of * 4 different tetrahedron faces, i.e., triangles. Note that a triangle is * defined by 3 vertices. @@ -7909,7 +7909,7 @@ namespace GridGenerator {{{{0, 1, 12}}, {{1, 12, 3}}, {{12, 3, 2}}, {{0, 12, 2}}}}, {{{{4, 5, 13}}, {{5, 13, 7}}, {{13, 7, 6}}, {{4, 13, 6}}}}}}; - /* Inner-faces 2D: + /* Inner-faces 2d: * The converted triangulation based on simplices has 8 faces that do not * form the boundary, i.e. inner-faces, each defined by 2 vertices. */ @@ -7923,7 +7923,7 @@ namespace GridGenerator {{7, 8}}, {{7, 5}}}}; - /* Inner-faces 3D: + /* Inner-faces 3d: * The converted triangulation based on simplices has 72 faces that do not * form the boundary, i.e. inner-faces, each defined by 3 vertices. */ @@ -7947,7 +7947,7 @@ namespace GridGenerator {{12, 13, 9}}, {{12, 13, 11}}, {{9, 11, 13}}, {{9, 11, 12}}, {{12, 13, 11}}, {{12, 13, 8}}, {{8, 11, 13}}, {{8, 11, 12}}}}; - /* Inner-edges 3D: + /* Inner-edges 3d: * The converted triangulation based on simplices has 60 edges that do not * coincide with the boundary, i.e. inner-edges, each defined by 2 vertices. */ @@ -7963,7 +7963,7 @@ namespace GridGenerator {{12, 13}}, {{9, 11}}, {{9, 13}}, {{11, 13}}, {{9, 12}}, {{11, 12}}, {{12, 13}}, {{11, 8}}, {{11, 13}}, {{8, 13}}, {{11, 12}}, {{8, 12}}}}; - /* Boundary-edges 3D: + /* Boundary-edges 3d: * For each of the 6 boundary-faces of the hexahedron, there are 8 edges (of * different tetrahedrons) that coincide with the boundary, i.e. * boundary-edges. Each boundary-edge is defined by 2 vertices. 4 of these diff --git a/source/grid/reference_cell.cc b/source/grid/reference_cell.cc index b855e6a4fc..d7e7b0e9b3 100644 --- a/source/grid/reference_cell.cc +++ b/source/grid/reference_cell.cc @@ -183,18 +183,18 @@ ReferenceCell::get_default_linear_mapping() const template Quadrature -ReferenceCell::get_gauss_type_quadrature(const unsigned n_points_1D) const +ReferenceCell::get_gauss_type_quadrature(const unsigned n_points_1d) const { AssertDimension(dim, get_dimension()); if (is_hyper_cube()) - return QGauss(n_points_1D); + return QGauss(n_points_1d); else if (is_simplex()) - return QGaussSimplex(n_points_1D); + return QGaussSimplex(n_points_1d); else if (*this == ReferenceCells::Pyramid) - return QGaussPyramid(n_points_1D); + return QGaussPyramid(n_points_1d); else if (*this == ReferenceCells::Wedge) - return QGaussWedge(n_points_1D); + return QGaussWedge(n_points_1d); else Assert(false, ExcNotImplemented()); diff --git a/source/grid/tria.cc b/source/grid/tria.cc index 25c83796d4..810c54783d 100644 --- a/source/grid/tria.cc +++ b/source/grid/tria.cc @@ -472,7 +472,7 @@ namespace * in the middle of this object, * if it exists. In order to * exist, the object needs to be - * refined - for 2D and 3D it + * refined - for 2d and 3d it * needs to be refined * isotropically or else the * anisotropic children have to @@ -1284,7 +1284,7 @@ namespace internal * not only call vector::reserve(), but does really append * the needed elements. * - * In 2D e.g. refined lines have to be stored in pairs, whereas new + * In 2d e.g. refined lines have to be stored in pairs, whereas new * lines in the interior of refined cells can be stored as single lines. */ void @@ -2732,7 +2732,7 @@ namespace internal * index the number of cells containing * this line. This information is needed to * decide whether a refined line may be - * coarsened or not in 3D. In 1D and 2D + * coarsened or not in 3d. In 1d and 2d * this argument is not needed and thus * ignored. The same applies for the last * argument and quads instead of lines. @@ -3599,7 +3599,7 @@ namespace internal * * The faces of the cell have to * be refined already, whereas - * the inner lines in 2D will be + * the inner lines in 2d will be * created in this * function. Therefore iterator * pointers into the vectors of @@ -10649,9 +10649,9 @@ namespace internal /** * Some dimension dependent stuff for mesh smoothing. * - * At present, this function does nothing in 1d and 2D, but + * At present, this function does nothing in 1d and 2d, but * makes sure no two cells with a level difference greater than - * one share one line in 3D. This is a requirement needed for + * one share one line in 3d. This is a requirement needed for * the interpolation of hanging nodes, since otherwise two steps * of interpolation would be necessary. This would make the * processes implemented in the @p AffineConstraints class much diff --git a/source/non_matching/quadrature_generator.cc b/source/non_matching/quadrature_generator.cc index df0f805b0e..195cdeb818 100644 --- a/source/non_matching/quadrature_generator.cc +++ b/source/non_matching/quadrature_generator.cc @@ -1398,7 +1398,7 @@ namespace NonMatching std::vector local_dof_values; /** - * Description of the 1D polynomial basis for tensor product elements + * Description of the 1d polynomial basis for tensor product elements * used for the fast path of this class using tensor product * evaluators. */ diff --git a/source/numerics/smoothness_estimator.cc b/source/numerics/smoothness_estimator.cc index 14a4d644b8..7a7b041cce 100644 --- a/source/numerics/smoothness_estimator.cc +++ b/source/numerics/smoothness_estimator.cc @@ -82,7 +82,7 @@ namespace SmoothnessEstimator * highest absolute value, i.e. $l^\infty$-norm. The bool * parameter defines which indices should be used in processing. In the * current case we are interested in coefficients which correspond to $0 - * <= i+j < N$ and $0 <= i+j+k < N$ in 2D and 3D, respectively. + * <= i+j < N$ and $0 <= i+j+k < N$ in 2d and 3d, respectively. */ template std::pair @@ -347,7 +347,7 @@ namespace SmoothnessEstimator * value, i.e. $l^\infty$-norm. The bool parameter defines * which indices should be used in processing. In the current case we are * interested in coefficients which correspond to $0 < i^2+j^2 < N^2$ and - * $0 < i^2+j^2+k^2 < N^2$ in 2D and 3D, respectively. + * $0 < i^2+j^2+k^2 < N^2$ in 2d and 3d, respectively. */ template std::pair