From e9855d6ed8766f6bfc00574b42af070da0e22368 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Wed, 8 Feb 2023 20:19:36 -0700 Subject: [PATCH] Standardize 2D/3D -> 2d/3d in the tutorials. --- examples/step-22/step-22.cc | 14 +++++++------- examples/step-25/step-25.cc | 2 +- examples/step-29/step-29.cc | 10 +++++----- examples/step-3/step-3.cc | 6 +++--- examples/step-30/step-30.cc | 2 +- examples/step-32/step-32.cc | 2 +- examples/step-37/step-37.cc | 2 +- examples/step-4/step-4.cc | 14 +++++++------- examples/step-41/step-41.cc | 2 +- examples/step-44/step-44.cc | 2 +- examples/step-48/step-48.cc | 2 +- examples/step-5/step-5.cc | 2 +- examples/step-51/step-51.cc | 4 ++-- examples/step-59/step-59.cc | 16 ++++++++-------- examples/step-63/step-63.cc | 2 +- examples/step-65/step-65.cc | 4 ++-- examples/step-66/step-66.cc | 4 ++-- examples/step-67/step-67.cc | 6 +++--- examples/step-69/step-69.cc | 6 +++--- examples/step-7/step-7.cc | 4 ++-- examples/step-70/step-70.cc | 2 +- examples/step-75/step-75.cc | 6 +++--- examples/step-76/step-76.cc | 4 ++-- examples/step-8/step-8.cc | 2 +- examples/step-82/step-82.cc | 2 +- examples/step-85/step-85.cc | 4 ++-- examples/step-9/step-9.cc | 6 +++--- 27 files changed, 66 insertions(+), 66 deletions(-) diff --git a/examples/step-22/step-22.cc b/examples/step-22/step-22.cc index cde92544a9..dc3f2c23ff 100644 --- a/examples/step-22/step-22.cc +++ b/examples/step-22/step-22.cc @@ -58,7 +58,7 @@ #include // This includes the library for the incomplete LU factorization that will be -// used as a preconditioner in 3D: +// used as a preconditioner in 3d: #include // This is C++: @@ -83,14 +83,14 @@ namespace Step22 template struct InnerPreconditioner; - // In 2D, we are going to use a sparse direct solver as preconditioner: + // In 2d, we are going to use a sparse direct solver as preconditioner: template <> struct InnerPreconditioner<2> { using type = SparseDirectUMFPACK; }; - // And the ILU preconditioning in 3D, called by SparseILU: + // And the ILU preconditioning in 3d, called by SparseILU: template <> struct InnerPreconditioner<3> { @@ -413,7 +413,7 @@ namespace Step22 // pattern objects. // // We then proceed with distributing degrees of freedom and renumbering - // them: In order to make the ILU preconditioner (in 3D) work efficiently, + // them: In order to make the ILU preconditioner (in 3d) work efficiently, // it is important to enumerate the degrees of freedom in such a way that it // reduces the bandwidth of the matrix, or maybe more importantly: in such a // way that the ILU is as close as possible to a real LU decomposition. On @@ -515,12 +515,12 @@ namespace Step22 // the same way as in step-20, i.e. directly build an object of type // SparsityPattern through DoFTools::make_sparsity_pattern. However, there // is a major reason not to do so: - // In 3D, the function DoFTools::max_couplings_between_dofs yields a + // In 3d, the function DoFTools::max_couplings_between_dofs yields a // conservative but rather large number for the coupling between the // individual dofs, so that the memory initially provided for the creation // of the sparsity pattern of the matrix is far too much -- so much actually // that the initial sparsity pattern won't even fit into the physical memory - // of most systems already for moderately-sized 3D problems, see also the + // of most systems already for moderately-sized 3d problems, see also the // discussion in step-18. Instead, we first build temporary objects that use // a different data structure that doesn't require allocating more memory // than necessary but isn't suitable for use as a basis of SparseMatrix or @@ -1007,7 +1007,7 @@ namespace Step22 // We then apply an initial refinement before solving for the first - // time. In 3D, there are going to be more degrees of freedom, so we + // time. In 3d, there are going to be more degrees of freedom, so we // refine less there: triangulation.refine_global(4 - dim); diff --git a/examples/step-25/step-25.cc b/examples/step-25/step-25.cc index f5c2f5227f..fe45b093ef 100644 --- a/examples/step-25/step-25.cc +++ b/examples/step-25/step-25.cc @@ -139,7 +139,7 @@ namespace Step25 // @sect3{Initial conditions} // In the following two classes, we first implement the exact solution for - // 1D, 2D, and 3D mentioned in the introduction to this program. This + // 1D, 2d, and 3d mentioned in the introduction to this program. This // space-time solution may be of independent interest if one wanted to test // the accuracy of the program by comparing the numerical against the // analytic solution (note however that the program uses a finite domain, diff --git a/examples/step-29/step-29.cc b/examples/step-29/step-29.cc index fa77819392..1de9f21274 100644 --- a/examples/step-29/step-29.cc +++ b/examples/step-29/step-29.cc @@ -422,9 +422,9 @@ namespace Step29 // Next, two points are defined for position and focal point of the // transducer lens, which is the center of the circle whose segment will // form the transducer part of the boundary. Notice that this is the only - // point in the program where things are slightly different in 2D and 3D. - // Even though this tutorial only deals with the 2D case, the necessary - // additions to make this program functional in 3D are so minimal that we + // point in the program where things are slightly different in 2d and 3d. + // Even though this tutorial only deals with the 2d case, the necessary + // additions to make this program functional in 3d are so minimal that we // opt for including them: const Point transducer = (dim == 2) ? Point(0.5, 0.0) : Point(0.5, 0.5, 0.0); @@ -454,7 +454,7 @@ namespace Step29 face->set_manifold_id(1); } // For the circle part of the transducer lens, a SphericalManifold object - // is used (which, of course, in 2D just represents a circle), with center + // is used (which, of course, in 2d just represents a circle), with center // computed as above. triangulation.set_manifold(1, SphericalManifold(focal_point)); @@ -738,7 +738,7 @@ namespace Step29 // with an iterative solver and a preconditioner that do a good job on this // matrix. We chose instead to go a different way and solve the linear // system with the sparse LU decomposition provided by UMFPACK. This is - // often a good first choice for 2D problems and works reasonably well even + // often a good first choice for 2d problems and works reasonably well even // for a large number of DoFs. The deal.II interface to UMFPACK is given by // the SparseDirectUMFPACK class, which is very easy to use and allows us to // solve our linear system with just 3 lines of code. diff --git a/examples/step-3/step-3.cc b/examples/step-3/step-3.cc index bcc5c4b3cb..83d25e481e 100644 --- a/examples/step-3/step-3.cc +++ b/examples/step-3/step-3.cc @@ -261,8 +261,8 @@ void Step3::assemble_system() // Ok, let's start: we need a quadrature formula for the evaluation of the // integrals on each cell. Let's take a Gauss formula with two quadrature // points in each direction, i.e. a total of four points since we are in - // 2D. This quadrature formula integrates polynomials of degrees up to three - // exactly (in 1D). It is easy to check that this is sufficient for the + // 2d. This quadrature formula integrates polynomials of degrees up to three + // exactly (in 1d). It is easy to check that this is sufficient for the // present problem: QGauss<2> quadrature_formula(fe.degree + 1); // And we initialize the object which we have briefly talked about above. It @@ -333,7 +333,7 @@ void Step3::assemble_system() // For use further down below, we define a shortcut for a value that will // be used very frequently. Namely, an abbreviation for the number of degrees - // of freedom on each cell (since we are in 2D and degrees of freedom are + // of freedom on each cell (since we are in 2d and degrees of freedom are // associated with vertices only, this number is four, but we rather want to // write the definition of this variable in a way that does not preclude us // from later choosing a different finite element that has a different diff --git a/examples/step-30/step-30.cc b/examples/step-30/step-30.cc index 1f151aab4b..d8264a91a7 100644 --- a/examples/step-30/step-30.cc +++ b/examples/step-30/step-30.cc @@ -995,7 +995,7 @@ int main() { using namespace Step30; - // If you want to run the program in 3D, simply change the following + // If you want to run the program in 3d, simply change the following // line to const unsigned int dim = 3;. const unsigned int dim = 2; diff --git a/examples/step-32/step-32.cc b/examples/step-32/step-32.cc index f5a914ce1b..77501b5b7c 100644 --- a/examples/step-32/step-32.cc +++ b/examples/step-32/step-32.cc @@ -2860,7 +2860,7 @@ namespace Step32 // Now let's turn to the temperature part: First, we compute the time step - // size. We found that we need smaller time steps for 3D than for 2D for + // size. We found that we need smaller time steps for 3d than for 2d for // the shell geometry. This is because the cells are more distorted in // that case (it is the smallest edge length that determines the CFL // number). Instead of computing the time step from maximum velocity and diff --git a/examples/step-37/step-37.cc b/examples/step-37/step-37.cc index f238e3c781..01cbf726dc 100644 --- a/examples/step-37/step-37.cc +++ b/examples/step-37/step-37.cc @@ -1141,7 +1141,7 @@ namespace Step37 // @sect4{LaplaceProblem::run} // The function that runs the program is very similar to the one in - // step-16. We do few refinement steps in 3D compared to 2D, but that's + // step-16. We do few refinement steps in 3d compared to 2d, but that's // it. // // Before we run the program, we output some information about the detected diff --git a/examples/step-4/step-4.cc b/examples/step-4/step-4.cc index 6084770a39..fa977d8844 100644 --- a/examples/step-4/step-4.cc +++ b/examples/step-4/step-4.cc @@ -166,9 +166,9 @@ public: // // But back to the concrete case here: // For this tutorial, we choose as right hand side the function -// $4(x^4+y^4)$ in 2D, or $4(x^4+y^4+z^4)$ in 3D. We could write this +// $4(x^4+y^4)$ in 2d, or $4(x^4+y^4+z^4)$ in 3d. We could write this // distinction using an if-statement on the space dimension, but here is a -// simple way that also allows us to use the same function in 1D (or in 4D, if +// simple way that also allows us to use the same function in 1d (or in 4D, if // you should desire to do so), by using a short loop. Fortunately, the // compiler knows the size of the loop at compile time (remember that at the // time when you define the template, the compiler doesn't know the value of @@ -197,7 +197,7 @@ double RightHandSide::value(const Point &p, } -// As boundary values, we choose $x^2+y^2$ in 2D, and $x^2+y^2+z^2$ in 3D. This +// As boundary values, we choose $x^2+y^2$ in 2d, and $x^2+y^2+z^2$ in 3d. This // happens to be equal to the square of the vector from the origin to the // point at which we would like to evaluate the function, irrespective of the // dimension. So that is what we return: @@ -250,10 +250,10 @@ Step4::Step4() // @sect4{Step4::make_grid} // Grid creation is something inherently dimension dependent. However, as long -// as the domains are sufficiently similar in 2D or 3D, the library can +// as the domains are sufficiently similar in 2d or 3d, the library can // abstract for you. In our case, we would like to again solve on the square -// $[-1,1]\times [-1,1]$ in 2D, or on the cube $[-1,1] \times [-1,1] \times -// [-1,1]$ in 3D; both can be termed GridGenerator::hyper_cube(), so we may +// $[-1,1]\times [-1,1]$ in 2d, or on the cube $[-1,1] \times [-1,1] \times +// [-1,1]$ in 3d; both can be termed GridGenerator::hyper_cube(), so we may // use the same function in whatever dimension we are. Of course, the // functions that create a hypercube in two and three dimensions are very much // different, but that is something you need not care about. Let the library @@ -348,7 +348,7 @@ void Step4::assemble_system() // Next, we again have to loop over all cells and assemble local // contributions. Note, that a cell is a quadrilateral in two space - // dimensions, but a hexahedron in 3D. In fact, the + // dimensions, but a hexahedron in 3d. In fact, the // active_cell_iterator data type is something different, // depending on the dimension we are in, but to the outside world they look // alike and you will probably never see a difference. In any case, the real diff --git a/examples/step-41/step-41.cc b/examples/step-41/step-41.cc index b52f55e544..428d2b9e77 100644 --- a/examples/step-41/step-41.cc +++ b/examples/step-41/step-41.cc @@ -188,7 +188,7 @@ namespace Step41 // @sect4{ObstacleProblem::make_grid} // We solve our obstacle problem on the square $[-1,1]\times [-1,1]$ in - // 2D. This function therefore just sets up one of the simplest possible + // 2d. This function therefore just sets up one of the simplest possible // meshes. template void ObstacleProblem::make_grid() diff --git a/examples/step-44/step-44.cc b/examples/step-44/step-44.cc index 3ea19e30ac..ed1e960190 100644 --- a/examples/step-44/step-44.cc +++ b/examples/step-44/step-44.cc @@ -2272,7 +2272,7 @@ namespace Step44 // in displacement is non-constant between each time step. constraints.clear(); - // The boundary conditions for the indentation problem in 3D are as + // The boundary conditions for the indentation problem in 3d are as // follows: On the -x, -y and -z faces (IDs 0,2,4) we set up a symmetry // condition to allow only planar movement while the +x and +z faces // (IDs 1,5) are traction free. In this contrived problem, part of the diff --git a/examples/step-48/step-48.cc b/examples/step-48/step-48.cc index a9454d1d7c..6198e133af 100644 --- a/examples/step-48/step-48.cc +++ b/examples/step-48/step-48.cc @@ -256,7 +256,7 @@ namespace Step48 // We define a time-dependent function that is used as initial // value. Different solutions can be obtained by varying the starting // time. This function, taken from step-25, would represent an analytic - // solution in 1D for all times, but is merely used for setting some + // solution in 1d for all times, but is merely used for setting some // starting solution of interest here. More elaborate choices that could // test the convergence of this program are given in step-25. template diff --git a/examples/step-5/step-5.cc b/examples/step-5/step-5.cc index f5f64b173c..8cd1aa28c2 100644 --- a/examples/step-5/step-5.cc +++ b/examples/step-5/step-5.cc @@ -330,7 +330,7 @@ void Step5::run() // two-dimensional triangulation, while this function is a template for // arbitrary dimension. Since this is only a demonstration program, we will // not use different input files for the different dimensions, but rather - // quickly kill the whole program if we are not in 2D. Of course, since the + // quickly kill the whole program if we are not in 2d. Of course, since the // main function below assumes that we are working in two dimensions we // could skip this check, in this version of the program, without any ill // effects. diff --git a/examples/step-51/step-51.cc b/examples/step-51/step-51.cc index 648cdc1392..05702de807 100644 --- a/examples/step-51/step-51.cc +++ b/examples/step-51/step-51.cc @@ -191,8 +191,8 @@ namespace Step51 // Next comes the implementation of the convection velocity. As described in - // the introduction, we choose a velocity field that is $(y, -x)$ in 2D and - // $(y, -x, 1)$ in 3D. This gives a divergence-free velocity field. + // the introduction, we choose a velocity field that is $(y, -x)$ in 2d and + // $(y, -x, 1)$ in 3d. This gives a divergence-free velocity field. template class ConvectionVelocity : public TensorFunction<1, dim> { diff --git a/examples/step-59/step-59.cc b/examples/step-59/step-59.cc index 7d7af6b45c..0a24164ffa 100644 --- a/examples/step-59/step-59.cc +++ b/examples/step-59/step-59.cc @@ -410,7 +410,7 @@ namespace Step59 // polynomial degree $k$ in $d$ space dimensions, out of the $(k+1)^d$ // degrees of freedom of a cell. A similar reduction is also possible for // the interior penalty method that evaluates values and first derivatives - // on the faces. When using a Hermite-like basis in 1D, only up to two basis + // on the faces. When using a Hermite-like basis in 1d, only up to two basis // functions contribute to the value and derivative. The class FE_DGQHermite // implements a tensor product of this concept, as discussed in the // introduction. Thus, only $2(k+1)^{d-1}$ degrees of freedom must be @@ -715,11 +715,11 @@ namespace Step59 // Next we turn to the preconditioner initialization. As explained in the // introduction, we want to construct an (approximate) inverse of the cell - // matrices from a product of 1D mass and Laplace matrices. Our first task - // is to compute the 1D matrices, which we do by first creating a 1D finite + // matrices from a product of 1d mass and Laplace matrices. Our first task + // is to compute the 1d matrices, which we do by first creating a 1d finite // element. Instead of anticipating FE_DGQHermite<1> here, we get the finite // element's name from DoFHandler, replace the @p dim argument (2 or 3) by 1 - // to create a 1D name, and construct the 1D element by using FETools. + // to create a 1d name, and construct the 1d element by using FETools. template void PreconditionBlockJacobi::initialize( @@ -731,7 +731,7 @@ namespace Step59 name.replace(name.find('<') + 1, 1, "1"); std::unique_ptr> fe_1d = FETools::get_fe_by_name<1>(name); - // As for computing the 1D matrices on the unit element, we simply write + // As for computing the 1d matrices on the unit element, we simply write // down what a typical assembly procedure over rows and columns of the // matrix as well as the quadrature points would do. We select the same // Laplace matrices once and for all using the coefficients 0.5 for @@ -773,7 +773,7 @@ namespace Step59 // The left and right boundary terms assembled by the next two // statements appear to have somewhat arbitrary signs, but those are // correct as can be verified by looking at step-39 and inserting - // the value -1 and 1 for the normal vector in the 1D case. + // the value -1 and 1 for the normal vector in the 1d case. sum_laplace += (1. * fe_1d->shape_value(i, Point<1>()) * fe_1d->shape_value(j, Point<1>()) * op.get_penalty_factor() + @@ -812,7 +812,7 @@ namespace Step59 // we check that it is diagonal and then extract the determinant of the // original Jacobian, i.e., the inverse of the determinant of the inverse // Jacobian, and set the weight as $\text{det}(J) / h_d^2$ according to - // the 1D Laplacian times $d-1$ copies of the mass matrix. + // the 1d Laplacian times $d-1$ copies of the mass matrix. cell_matrices.clear(); FEEvaluation phi(*data); unsigned int old_mapping_data_index = numbers::invalid_unsigned_int; @@ -1307,7 +1307,7 @@ namespace Step59 // periodic boundary conditions in the $x$-direction, a Dirichlet condition // on the front face in $y$ direction (i.e., the face with index number 2, // with boundary id equal to 0), and Neumann conditions on the back face as - // well as the two faces in $z$ direction for the 3D case (with boundary id + // well as the two faces in $z$ direction for the 3d case (with boundary id // equal to 1). The extent of the domain is a bit different in the $x$ // direction (where we want to achieve a periodic solution given the // definition of `Solution`) as compared to the $y$ and $z$ directions. diff --git a/examples/step-63/step-63.cc b/examples/step-63/step-63.cc index 09887d97c6..eab8d009dc 100644 --- a/examples/step-63/step-63.cc +++ b/examples/step-63/step-63.cc @@ -894,7 +894,7 @@ namespace Step63 // for degree 1 and degree 3 finite elements. If the user wants to change to // another degree, they may need to adjust these numbers. For block smoothers, // this parameter has a more straightforward interpretation, namely that for - // additive methods in 2D, a DoF can have a repeated contribution from up to 4 + // additive methods in 2d, a DoF can have a repeated contribution from up to 4 // cells, therefore we must relax these methods by 0.25 to compensate. This is // not an issue for multiplicative methods as each cell's inverse application // carries new information to all its DoFs. diff --git a/examples/step-65/step-65.cc b/examples/step-65/step-65.cc index a6e333025d..4fa64636ee 100644 --- a/examples/step-65/step-65.cc +++ b/examples/step-65/step-65.cc @@ -175,7 +175,7 @@ namespace Step65 // ball should be compatible with the outer grid in the sense that their // vertices coincide so as to allow the two grid to be merged. The grid coming // out of GridGenerator::hyper_shell fulfills the requirements on the inner - // side in case it is created with $2d$ coarse cells (6 coarse cells in 3D + // side in case it is created with $2d$ coarse cells (6 coarse cells in 3d // which we are going to use) – this is the same number of cells as // there are boundary faces for the ball. For the outer surface, we use the // fact that the 6 faces on the surface of the shell without a manifold @@ -349,7 +349,7 @@ namespace Step65 // // The reason for choosing this somewhat unusual scheme is due to the heavy // work involved in computing the cell matrix for a relatively high - // polynomial degree in 3D. As we want to highlight the cost of the mapping + // polynomial degree in 3d. As we want to highlight the cost of the mapping // in this tutorial program, we better do the assembly in an optimized way // in order to not chase bottlenecks that have been solved by the community // already. Matrix-matrix multiplication is one of the best optimized diff --git a/examples/step-66/step-66.cc b/examples/step-66/step-66.cc index 8815f97bf6..f633aea7c4 100644 --- a/examples/step-66/step-66.cc +++ b/examples/step-66/step-66.cc @@ -399,7 +399,7 @@ namespace Step66 // For the parallel computation we define a // parallel::distributed::Triangulation. As the computational domain is a - // circle in 2D and a ball in 3D, we assign in addition to the + // circle in 2d and a ball in 3d, we assign in addition to the // SphericalManifold for boundary cells a TransfiniteInterpolationManifold // object for the mapping of the inner cells, which takes care of the inner // cells. In this example we use an isoparametric finite element approach @@ -1154,7 +1154,7 @@ namespace Step66 // framework and disable shared-memory parallelization by limiting the number of // threads to one. Finally to run the solver for the Gelfand problem we // create an object of the GelfandProblem class and call the run -// function. Exemplarily we solve the problem once in 2D and once in 3D each +// function. Exemplarily we solve the problem once in 2d and once in 3d each // with fourth-order Lagrangian finite elements. int main(int argc, char *argv[]) { diff --git a/examples/step-67/step-67.cc b/examples/step-67/step-67.cc index 1da6c6e3bc..a596657ca9 100644 --- a/examples/step-67/step-67.cc +++ b/examples/step-67/step-67.cc @@ -67,7 +67,7 @@ namespace Euler_DG // want to use for the nonlinear terms in the Euler equations. Furthermore, // we specify the time interval for the time-dependent problem, and // implement two different test cases. The first one is an analytical - // solution in 2D, whereas the second is a channel flow around a cylinder as + // solution in 2d, whereas the second is a channel flow around a cylinder as // described in the introduction. Depending on the test case, we also change // the final time up to which we run the simulation, and a variable // `output_tick` that specifies in which intervals we want to write output @@ -1748,7 +1748,7 @@ namespace Euler_DG // step-33. The interface of the DataPostprocessor class is intuitive, // requiring us to provide information about what needs to be evaluated // (typically only the values of the solution, except for the Schlieren plot - // that we only enable in 2D where it makes sense), and the names of what + // that we only enable in 2d where it makes sense), and the names of what // gets evaluated. Note that it would also be possible to extract most // information by calculator tools within visualization programs such as // ParaView, but it is so much more convenient to do it already when writing @@ -1956,7 +1956,7 @@ namespace Euler_DG // choose a constant inflow profile, whereas we set a subsonic outflow at // the right. For the boundary around the cylinder (boundary id equal to 2) // as well as the channel walls (boundary id equal to 3) we use the wall - // boundary type, which is no-normal flow. Furthermore, for the 3D cylinder + // boundary type, which is no-normal flow. Furthermore, for the 3d cylinder // we also add a gravity force in vertical direction. Having the base mesh // in place (including the manifolds set by // GridGenerator::channel_with_cylinder()), we can then perform the diff --git a/examples/step-69/step-69.cc b/examples/step-69/step-69.cc index e4a28b3c58..018d6c22ac 100644 --- a/examples/step-69/step-69.cc +++ b/examples/step-69/step-69.cc @@ -325,7 +325,7 @@ namespace Step69 // // For the purpose of this example step // we simply implement a homogeneous uniform flow field for which the - // direction and a 1D primitive state (density, velocity, pressure) are + // direction and a 1d primitive state (density, velocity, pressure) are // read from the parameter file. // // It would be desirable to initialize the class in a single shot: @@ -1424,7 +1424,7 @@ namespace Step69 // We start again by defining a couple of helper functions: // // The first function takes a state U and a unit vector - // n_ij and computes the projected 1D state in + // n_ij and computes the projected 1d state in // direction of the unit vector. namespace { @@ -1445,7 +1445,7 @@ namespace Step69 const auto perpendicular_m = m - projected_U[1] * n_ij; projected_U[2] = U[1 + dim] - 0.5 * perpendicular_m.norm_square() / U[0]; - // We return the 1D state in primitive variables instead of + // We return the 1d state in primitive variables instead of // conserved quantities. The return array consists of density $\rho$, // velocity $u$, pressure $p$ and local speed of sound $a$: diff --git a/examples/step-7/step-7.cc b/examples/step-7/step-7.cc index 6229dae851..89d5ae6a33 100644 --- a/examples/step-7/step-7.cc +++ b/examples/step-7/step-7.cc @@ -1070,8 +1070,8 @@ namespace Step7 // 1, which is why you haven't seen this parameter in // previous examples). This parameter denotes into how many sub-cells per // space direction each cell shall be subdivided for output. For example, - // if you give 2, this leads to 4 cells in 2D and 8 cells in - // 3D. For quadratic elements, two sub-cells per space direction is + // if you give 2, this leads to 4 cells in 2d and 8 cells in + // 3d. For quadratic elements, two sub-cells per space direction is // obviously the right choice, so this is what we choose. In general, for // elements of polynomial order q, we use q // subdivisions, and the order of the elements is determined in the same diff --git a/examples/step-70/step-70.cc b/examples/step-70/step-70.cc index d2e6be3fc1..1d66c58db9 100644 --- a/examples/step-70/step-70.cc +++ b/examples/step-70/step-70.cc @@ -854,7 +854,7 @@ namespace Step70 "extension. Bailing out.")); // Now we check how many faces are contained in the `Shape`. OpenCASCADE - // is intrinsically 3D, so if this number is zero, we interpret this as + // is intrinsically 3d, so if this number is zero, we interpret this as // a line manifold, otherwise as a // OpenCASCADE::NormalToMeshProjectionManifold in `spacedim` = 3, or // OpenCASCADE::NURBSPatchManifold in `spacedim` = 2. diff --git a/examples/step-75/step-75.cc b/examples/step-75/step-75.cc index 35d01aa716..53fe298666 100644 --- a/examples/step-75/step-75.cc +++ b/examples/step-75/step-75.cc @@ -208,7 +208,7 @@ namespace Step75 // We will use the FEEvaluation class to evaluate the solution vector // at the quadrature points and to perform the integration. In contrast to // other tutorials, the template arguments `degree` is set to $-1$ and - // `number of quadrature in 1D` to $0$. In this case, FEEvaluation selects + // `number of quadrature in 1d` to $0$. In this case, FEEvaluation selects // dynamically the correct polynomial degree and number of quadrature // points. Here, we introduce an alias to FEEvaluation with the correct // template parameters so that we do not have to worry about them later on. @@ -1028,12 +1028,12 @@ namespace Step75 // @sect4{LaplaceProblem::initialize_grid} // For a L-shaped domain, we could use the function GridGenerator::hyper_L() - // as demonstrated in step-50. However in the 2D case, that particular + // as demonstrated in step-50. However in the 2d case, that particular // function removes the first quadrant, while we need the fourth quadrant // removed in our scenario. Thus, we will use a different function // GridGenerator::subdivided_hyper_L() which gives us more options to create // the mesh. Furthermore, we formulate that function in a way that it also - // generates a 3D mesh: the 2D L-shaped domain will basically elongated by 1 + // generates a 3d mesh: the 2d L-shaped domain will basically elongated by 1 // in the positive z-direction. // // We first pretend to build a GridGenerator::subdivided_hyper_rectangle(). diff --git a/examples/step-76/step-76.cc b/examples/step-76/step-76.cc index bc0044957e..adb5c45cf5 100644 --- a/examples/step-76/step-76.cc +++ b/examples/step-76/step-76.cc @@ -783,7 +783,7 @@ namespace Euler_DG phi_m.reinit(cell, face); // Interpolate the values from the cell quadrature points to the - // quadrature points of the current face via a simple 1D + // quadrature points of the current face via a simple 1d // interpolation: internal::FEFaceNormalEvaluationImpl:: diff --git a/examples/step-8/step-8.cc b/examples/step-8/step-8.cc index 8b5700c42c..c5b4c3cbfb 100644 --- a/examples/step-8/step-8.cc +++ b/examples/step-8/step-8.cc @@ -541,7 +541,7 @@ namespace Step8 // The reason for refining is a bit accidental: we use the QGauss // quadrature formula with two points in each direction for integration of the // right hand side; that means that there are four quadrature points on each - // cell (in 2D). If we only refine the initial grid once globally, then there + // cell (in 2d). If we only refine the initial grid once globally, then there // will be only four quadrature points in each direction on the // domain. However, the right hand side function was chosen to be rather // localized and in that case, by pure chance, it happens that all quadrature diff --git a/examples/step-82/step-82.cc b/examples/step-82/step-82.cc index a0f0eb3cce..961f3f8418 100644 --- a/examples/step-82/step-82.cc +++ b/examples/step-82/step-82.cc @@ -1467,7 +1467,7 @@ namespace Step82 // This is the main function. We define here the number of mesh // refinements, the polynomial degree for the two finite element spaces // (for the solution and the two liftings) and the two penalty coefficients. -// We can also change the dimension to run the code in 3D. +// We can also change the dimension to run the code in 3d. int main() { try diff --git a/examples/step-85/step-85.cc b/examples/step-85/step-85.cc index 6e05c8073d..9f4e774c3c 100644 --- a/examples/step-85/step-85.cc +++ b/examples/step-85/step-85.cc @@ -331,9 +331,9 @@ namespace Step85 // To make the assembly easier, we use the class NonMatching::FEValues, // which does the above steps 1 and 2 for us. The algorithm @cite saye_2015 // that is used to generate the quadrature rules on the intersected cells - // uses a 1-dimensional quadrature rule as base. Thus, we pass a 1D + // uses a 1-dimensional quadrature rule as base. Thus, we pass a 1d // Gauss--Legendre quadrature to the constructor of NonMatching::FEValues. - // On the non-intersected cells, a tensor product of this 1D-quadrature will + // On the non-intersected cells, a tensor product of this 1d-quadrature will // be used. // // As stated in the introduction, each cell has 3 different regions: inside, diff --git a/examples/step-9/step-9.cc b/examples/step-9/step-9.cc index 83b26254a3..ca6f4c615b 100644 --- a/examples/step-9/step-9.cc +++ b/examples/step-9/step-9.cc @@ -812,8 +812,8 @@ namespace Step9 // understand data that is associated with nodes: they cannot plot // fifth-degree basis functions, which results in a very inaccurate picture // of the solution we computed. To get around this we save multiple - // patches per cell: in 2D we save 64 bilinear `cells' to the VTU - // file for each cell, and in 3D we save 512. The end result is that the + // patches per cell: in 2d we save 64 bilinear `cells' to the VTU + // file for each cell, and in 3d we save 512. The end result is that the // visualization program will use a piecewise linear interpolation of the // cubic basis functions: this captures the solution detail and, with most // screen resolutions, looks smooth. We save the grid in a separate step @@ -1053,7 +1053,7 @@ namespace Step9 // Then check whether the neighbor is active. If it is, then it // is on the same level or one level coarser (if we are not in - // 1D), and we are interested in it in any case. + // 1d), and we are interested in it in any case. if (neighbor->is_active()) scratch_data.active_neighbors.push_back(neighbor); else -- 2.39.5