]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Standardize 2D/3D -> 2d/3d in the tutorials. 14776/head
authorWolfgang Bangerth <bangerth@colostate.edu>
Thu, 9 Feb 2023 03:19:36 +0000 (20:19 -0700)
committerWolfgang Bangerth <bangerth@colostate.edu>
Thu, 9 Feb 2023 03:19:36 +0000 (20:19 -0700)
27 files changed:
examples/step-22/step-22.cc
examples/step-25/step-25.cc
examples/step-29/step-29.cc
examples/step-3/step-3.cc
examples/step-30/step-30.cc
examples/step-32/step-32.cc
examples/step-37/step-37.cc
examples/step-4/step-4.cc
examples/step-41/step-41.cc
examples/step-44/step-44.cc
examples/step-48/step-48.cc
examples/step-5/step-5.cc
examples/step-51/step-51.cc
examples/step-59/step-59.cc
examples/step-63/step-63.cc
examples/step-65/step-65.cc
examples/step-66/step-66.cc
examples/step-67/step-67.cc
examples/step-69/step-69.cc
examples/step-7/step-7.cc
examples/step-70/step-70.cc
examples/step-75/step-75.cc
examples/step-76/step-76.cc
examples/step-8/step-8.cc
examples/step-82/step-82.cc
examples/step-85/step-85.cc
examples/step-9/step-9.cc

index cde92544a9032ee02d7a10622d7c82fcc6f7aa21..dc3f2c23ff23d32fa6ec75c4b6c3c57437a16e22 100644 (file)
@@ -58,7 +58,7 @@
 #include <deal.II/lac/sparse_direct.h>
 
 // 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 <deal.II/lac/sparse_ilu.h>
 
 // This is C++:
@@ -83,14 +83,14 @@ namespace Step22
   template <int dim>
   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);
 
index f5c2f5227fcb83bc0795cf1a6e55284a750fca69..fe45b093efa71e8c03d5515747ee63c3dce81f3e 100644 (file)
@@ -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,
index fa7781939249a1126f3e2754666c15d46909009a..1de9f212746a70b8f66af11a70ad8040f3c748f6 100644 (file)
@@ -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<dim> transducer =
       (dim == 2) ? Point<dim>(0.5, 0.0) : Point<dim>(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<dim>(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.
index bcc5c4b3cbc080b6936c1b4c07dc39f91df3f765..83d25e481e1c3528bfb0498e7246a85faae9e8cd 100644 (file)
@@ -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
index 1f151aab4b30b11172bd46be2e96e1722df9c2f1..d8264a91a72a5e7c3ac655d2262d8fa412f3b40c 100644 (file)
@@ -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 <code>const unsigned int dim = 3;</code>.
       const unsigned int dim = 2;
 
index f5a914ce1bb635ef4441ebf3473280116fd8e732..77501b5b7c34359fdf5184362f204719cb83b9a5 100644 (file)
@@ -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
index f238e3c781f8d1f503f72732f0578057e2e91891..01cbf726dc470b6e45d91fb7859a6a07600d10c1 100644 (file)
@@ -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
index 6084770a39b7d31b4bd5fbf90ddfdd22eeb7bcef..fa977d8844ebe28557ef643fd1fb20b844357857 100644 (file)
@@ -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<dim>::value(const Point<dim> &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<dim>::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<dim>::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
   // <code>active_cell_iterator</code> 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
index b52f55e544b7ce82be9ea16f47b9be7d736c08c2..428d2b9e7768a03f24c20a0d50e888c6a7a10b56 100644 (file)
@@ -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 <int dim>
   void ObstacleProblem<dim>::make_grid()
index 3ea19e30acffe1f199964fd7941b5de1199e1e6a..ed1e960190a59559fed5b2650551f28d04931ecf 100644 (file)
@@ -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
index a9454d1d7c3d36282696f5ea8e29272fcc40ad54..6198e133af677c85039326801e94feece8ce8c53 100644 (file)
@@ -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 <int dim>
index f5f64b173cc450795f5cdce1b5988ca6eb2bb165..8cd1aa28c277721f237585d650b8679e2f043fa5 100644 (file)
@@ -330,7 +330,7 @@ void Step5<dim>::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.
index 648cdc13923f63d24557311ce514d790e992f312..05702de80707461245a3656c8de2417d05b9f57f 100644 (file)
@@ -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 <int dim>
   class ConvectionVelocity : public TensorFunction<1, dim>
   {
index 7d7af6b45cf572208f365284c72fccad2f191ab2..0a24164ffad49f6c6c892d58101188d7545b77fb 100644 (file)
@@ -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 <int dim, int fe_degree, typename number>
   void PreconditionBlockJacobi<dim, fe_degree, number>::initialize(
@@ -731,7 +731,7 @@ namespace Step59
     name.replace(name.find('<') + 1, 1, "1");
     std::unique_ptr<FiniteElement<1>> 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<dim, fe_degree, fe_degree + 1, 1, number> 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.
index 09887d97c61986359463201e23ecc1b1d0591b50..eab8d009dc8db95d9ec1783772da3ebbabb75d99 100644 (file)
@@ -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.
index a6e333025d10becd28cfacc9f6c9a77b0d38ffa4..4fa64636ee899b47e51961baf488ecc78fbb4b82 100644 (file)
@@ -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) &ndash; 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
index 8815f97bf62ff208dcae8421cce788c9e67e2d23..f633aea7c477166bfb8da5782c4a31f23b77e187 100644 (file)
@@ -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 <i>Gelfand problem</i> we
 // create an object of the <code>GelfandProblem</code> 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[])
 {
index 1da6c6e3bc5d490b0f859eeecc7346a2a744c2f6..a596657ca9d9d1e9d087f773477af5010884f2ef 100644 (file)
@@ -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
index e4a28b3c58b33893e0072a11ce81a79291066ad3..018d6c22ac0f1e092d129127d9498e7d75a5a350 100644 (file)
@@ -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 <code>U</code> and a unit vector
-  // <code>n_ij</code> and computes the <i>projected</i> 1D state in
+  // <code>n_ij</code> and computes the <i>projected</i> 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 <i>primitive</i> variables instead of
+      // We return the 1d state in <i>primitive</i> variables instead of
       // conserved quantities. The return array consists of density $\rho$,
       // velocity $u$, pressure $p$ and local speed of sound $a$:
 
index 6229dae8516a67a518e06583699f594d115ce758..89d5ae6a3305c55bcc747f88c3afdbf9f3d17466 100644 (file)
@@ -1070,8 +1070,8 @@ namespace Step7
     // <code>1</code>, 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 <code>2</code>, 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 <code>2</code>, 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 <code>q</code>, we use <code>q</code>
     // subdivisions, and the order of the elements is determined in the same
index d2e6be3fc181408f13fe575479907394a6c08cf3..1d66c58db9e16eb1fe5969b6a8d1a4e82bb10966 100644 (file)
@@ -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.
index 35d01aa71668de517dcc1b0dc5e2a48f2f876507..53fe298666b01cbba6aac5872ecb962aaeafe52f 100644 (file)
@@ -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().
index bc0044957e74eed0f1a9c0e381657d7718a82052..adb5c45cf5aad778b1278498bdaf2df5cf3ca0fd 100644 (file)
@@ -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<dim,
                                                      n_points_1d - 1,
@@ -886,7 +886,7 @@ namespace Euler_DG
                   }
 
                 // Evaluate local integrals related to cell by quadrature and
-                // add into cell contribution via a simple 1D interpolation:
+                // add into cell contribution via a simple 1d interpolation:
                 internal::FEFaceNormalEvaluationImpl<dim,
                                                      n_points_1d - 1,
                                                      VectorizedArrayType>::
index 8b5700c42cedb7a3a8aa5e9d1dde1b0e7a2733a9..c5b4c3cbfbe01c8d57a0a18e029ec82d0f41257b 100644 (file)
@@ -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
index a0f0eb3ccea814fac9bc98eb746df9e3eadd194c..961f3f841818f04cadbb75ee5ccca50d5176f913 100644 (file)
@@ -1467,7 +1467,7 @@ namespace Step82
 // This is the <code>main</code> 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
index 6e05c8073dff19e98a68dd6bbff72309359c51c0..9f4e774c3c8a5335904b2fd25516cd8dea0e143a 100644 (file)
@@ -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,
index 83b26254a37781fb9dac1cc686bdae8bf34d1e49..ca6f4c615b72e813d17ce1f42874710307737a12 100644 (file)
@@ -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
-  // <em>patches</em> 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
+  // <em>patches</em> 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

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.