]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Improve spelling in step-70. 10237/head
authorDavid Wells <drwells@email.unc.edu>
Fri, 15 May 2020 17:47:50 +0000 (13:47 -0400)
committerDavid Wells <drwells@email.unc.edu>
Fri, 15 May 2020 19:04:38 +0000 (15:04 -0400)
examples/step-70/doc/intro.dox
examples/step-70/doc/results.dox
examples/step-70/step-70.cc

index 4803206930f824e7cfdae421022b42e267ce3145..39d203d134e194d80fb8bde951ab491af772f684 100644 (file)
@@ -19,7 +19,7 @@ because they often involve a container (with fixed boundaries, and possibly
 complex geometries such as baffles), represented by the domain $\Omega$,
 and one (or more) immersed and rotating impellers (represented by the domain $\Omega^{\text{imp}}$).
 The domain in which we would like to solve the flow equations is the (time
-depedendent) difference between the two domains, namely:
+dependent) difference between the two domains, namely:
 $\Omega\setminus\Omega^{\text{imp}}$.
 
 For rotating impellers, the use of Arbitrary Lagrangian Eulerian formulations
@@ -59,7 +59,7 @@ flow (i.e. a flow where $\text{Re}\rightarrow 0$) and a no-slip boundary
 condition is applied on the moving *embedded domain* $\Gamma$ associated with
 the impeller. However, this tutorial could be readily extended
 to other equations (e.g. the Navier-Stokes equations, linear elasticity
-equation, etc.). It can can be seen as a natural extension of step-60 that
+equation, etc.). It can be seen as a natural extension of step-60 that
 enables the solution of large problems using a distributed parallel computing
 architecture via MPI.
 
@@ -202,7 +202,7 @@ error. The consistency terms and the stabilization term are added to the
 right hand side with the actual boundary data $\mathbf{g}$.
 
 When $\mathbf{u}$ satisfies the condition $\mathbf{u}=\mathbf{g}$ on $\Gamma$,
-all the consistency and stabilty integrals on $\Gamma$ cancel out, and one is
+all the consistency and stability integrals on $\Gamma$ cancel out, and one is
 left with the usual weak form of Stokes flow, that is, the above formulation is
 consistent.
 
@@ -231,7 +231,7 @@ discretization, since in this case it can be shown that the dual problem is
 also consistent, leading to a solution where not only the energy norm of the
 solution converges with the correct order, but also its $L^2$ norm.
 
-The above formulation works under the assumption that the domain is discretised
+The above formulation works under the assumption that the domain is discretized
 exactly. However, if the deformation of the impeller is a rigid body
 motion, it is possible to artificially extend the solution of the Stokes
 problem inside the propeller itself, since a rigid body motion is also a
@@ -284,7 +284,7 @@ to impose the boundary condition over $\Gamma$.
 
 <h4>Co-dimension zero case</h4>
 
-In this case, $\Gamma$ has the same dimension, but is imbedded into $\Omega$.
+In this case, $\Gamma$ has the same dimension, but is embedded into $\Omega$.
 In the case of $\mathcal{L}^2$ penalization, the additional penalization
 term, can be interpreted as a Darcy term within $\Gamma$, resulting in:
 
@@ -322,7 +322,7 @@ implementation, thanks to the dimension independent capabilities of deal.II.
 
 In this tutorial, both the embedded grid $\Gamma$ and the embedding
 grid are described using a parallel::distributed::Triangulation. These two
-triangulations can be built from deal.II GridGenerators namespace or by reading
+triangulations can be built from the GridGenerator namespace or by reading
 a mesh file produced with another application (e.g. GMSH). This is slightly
 more general than what was previously done in step-60.
 
index c8f2371e6efe318749f62eb265814e3f8a4b2300..d81bc77517f1c0da3e11638d3ce8873452e91c5a 100644 (file)
@@ -35,7 +35,7 @@ Aborting!
 However, as the error message already states, the code that triggers the
 exception will also generate the specified file ("parameters.prm" in this case)
 that simply contains the default values for all parameters this program cares
-about (for the correct dimension and co-dimension, according to the wether a
+about (for the correct dimension and co-dimension, according to the whether a
 string "23" or "3" is contained in the file name). By inspection of the default
 parameter file, we see the following:
 
@@ -240,7 +240,7 @@ end
 @endcode
 
 and you would run the program with Q3/Q2 Taylor-Hood finite elements, for 101
-steps, using a Nistche penalty of `10`, and leaving all the other parameters to
+steps, using a Nitsche penalty of `10`, and leaving all the other parameters to
 their default value. You could then inspect all the other parameters in the
 produced file `parameters_22.prm`.
 
@@ -312,7 +312,7 @@ Time : 1, time step: 0.002
 @endcode
 
 You may notice that assembling the coupling system is more expensive than
-assembling the Stokes part. This depends highly on the number of gauss points
+assembling the Stokes part. This depends highly on the number of Gauss points
 (solid particles) that are used to apply the Nitsche restriction.
 In the present case, a relatively low number of tracer particles are used.
 Consequently, tracking their motion is relatively cheap.
@@ -356,7 +356,7 @@ volume of the impeller have returned very close to their initial position,
 whereas those in the swept volume were slightly more deformed. This deformation
 is non-physical. It is caused by the numerical error induced by the explicit
 Euler scheme used to advect the particles, by the loss of accuracy due to the
-fictious domain and, finally, by the discretization error on the Stokes
+fictitious domain and, finally, by the discretization error on the Stokes
 equations. The first two errors are the leading cause of this deformation and
 they could be alleviated by the use of a finer mesh and a lower time step.
 
@@ -465,7 +465,7 @@ problem with distributed Lagrange multipliers, on
 parallel::distributed::Triangulation objects.
 
 The timings above show that the current preconditioning strategy does not work
-well for Nitsche penalisation, and we should come up with a better
+well for Nitsche penalization, and we should come up with a better
 preconditioner if we want to aim at larger problems. Moreover, a checkpoint
 restart strategy should be implemented to allow for longer simulations to be
 interrupted and restored, as it is done for example in the tutorial step-69.
index a58d28eb7024f202dadef28e84339e5ccd97b65d..07847ec145e40eaf8a48f8fbba8b052f83e0163a 100644 (file)
@@ -149,11 +149,11 @@ namespace Step70
 {
   using namespace dealii;
 
-  // Similiarly to what we have done in step-60, we set up a class that holds
+  // Similarly to what we have done in step-60, we set up a class that holds
   // all the parameters of our problem and derive it from the ParameterAcceptor
   // class to simplify the management and creation of parameter files.
   //
-  // The ParameterAcceptor paradigm requires all parameters to be writeable by
+  // The ParameterAcceptor paradigm requires all parameters to be writable by
   // the ParameterAcceptor methods. In order to avoid bugs that would be very
   // difficult to trace down (such as writing things like `time = 0` instead of
   // `time == 0`), we declare all the parameters in an external class, which is
@@ -188,7 +188,7 @@ namespace Step70
     std::string output_directory = ".";
 
     // We will use a Taylor-Hood function space of arbitrary order. This
-    // parameter is used to initialize the FiniteElement space with the corret
+    // parameter is used to initialize the FiniteElement space with the correct
     // FESystem object
     unsigned int velocity_degree = 2;
 
@@ -226,8 +226,8 @@ namespace Step70
     double viscosity    = 1.0;
     double penalty_term = 100;
 
-    // By default, we create a hyper_cube without colorisation, and we use
-    // homogenous Dirichlet boundary conditions. In this set we store the
+    // By default, we create a hyper_cube without colorization, and we use
+    // homogeneous Dirichlet boundary conditions. In this set we store the
     // boundary ids to use when setting the boundary conditions:
     std::list<types::boundary_id> homogeneous_dirichlet_ids{0};
 
@@ -239,7 +239,7 @@ namespace Step70
     // The mechanism with which the arguments are parsed from and to a string is
     // explained in detail in the Patterns::Tools::Convert class, which is
     // used to translate from strings to most of the basic STL types (vectors,
-    // maps, tuples) and basic dealii types (Point, Tensor, BoundingBox, etc.).
+    // maps, tuples) and basic deal.II types (Point, Tensor, BoundingBox, etc.).
     //
     // In general objects that can be represented by rank 1 uniform elements
     // (i.e., std::vector<double>, Point<dim>, std::set<int>, etc.) are comma
@@ -264,7 +264,7 @@ namespace Step70
     // GridGenerator namespace. If the GridGenerator function fails, this
     // program will interpret the name of the grid as a vtk grid filename, and
     // the arguments as a map from manifold_id to the CAD files describing the
-    // geometry of the domain. Every CAD file will be analysed and a Manifold of
+    // geometry of the domain. Every CAD file will be analyzed and a Manifold of
     // the OpenCASCADE namespace will be generated according to the content of
     // the CAD file itself.
     //
@@ -286,7 +286,7 @@ namespace Step70
     // to control the minimum size of the fluid grid, and guarantee that it is
     // compatible with the solid grid. The minimum number of refinement levels
     // is also controlled to ensured sufficient accuracy in the
-    // bulk of the flow. Additionnaly, we perform local refinement
+    // bulk of the flow. Additionally, we perform local refinement
     // based on standard error estimators on the fluid velocity field.
     //
     // We permit the user to choose between the
@@ -353,7 +353,7 @@ namespace Step70
   };
 
   // Similarly, we assume that the solid position can be computed explicitly at
-  // each time step, exploiting the knoweledge of the angular velocity. We
+  // each time step, exploiting the knowledge of the angular velocity. We
   // compute the exact position of the solid particle assuming that the solid is
   // rotated by an amount equal to the time step multiplied by the angular
   // velocity computed at the point `p`:
@@ -434,7 +434,7 @@ namespace Step70
 
     // The assembly routine is very similar to other Stokes assembly routines,
     void assemble_stokes_system();
-    // with the exception of the Nistche restriction part, which exploits one of
+    // with the exception of the Nitsche restriction part, which exploits one of
     // the particle handlers to integrate on a non-matching part of the fluid
     // domain, corresponding to the position of the solid.
     void assemble_nitsche_restriction();
@@ -444,7 +444,7 @@ namespace Step70
 
     // The refine_and_transfer() method is called only every
     // `refinement_frequency` steps, and makes sure that all the fields
-    // that were computed on the time step before refinement are transfered
+    // that were computed on the time step before refinement are transferred
     // correctly to the new grid. This includes vector fields, as well as
     // particle information.
     void refine_and_transfer();
@@ -583,7 +583,7 @@ namespace Step70
     // overlapping.
     //
     // In order to allow for the efficient exchange of information between
-    // non-overlapping parallell::distributed::Triangulation objects, some
+    // non-overlapping parallel::distributed::Triangulation objects, some
     // algorithms of the library require the user to provide a rough description
     // of the area occupied by the locally owned part of the triangulation, in
     // the form of a collection of axis-aligned bounding boxes for each process,
@@ -615,7 +615,7 @@ namespace Step70
 
   // In the constructor, we create the mpi_communicator as well as
   // the triangulations and dof_handler for both the fluid and the solid.
-  // Using the mpi_communicator, both the ConditionalOSStream and TimerOutput
+  // Using the mpi_communicator, both the ConditionalOStream and TimerOutput
   // are constructed.
   template <int dim, int spacedim>
   StokesImmersedProblem<dim, spacedim>::StokesImmersedProblem(
@@ -663,14 +663,14 @@ namespace Step70
     // ready to attach to it the correct manifold descriptions. We perform the
     // next lines of codes only if deal.II has been built with OpenCASCADE
     // support. For each entry in the map, we try to open the corresponding CAD
-    // file, we analyse it, and according to its content, opt for either a
+    // file, we analyze it, and according to its content, opt for either a
     // ArchLengthProjectionLineManifold (if the CAD file contains a single
     // TopoDS_Edge or a single TopoDS_Wire) or a NURBSPatchManifold, if the file
     // contains a single face. Notice that if the CAD files do not contain
     // single wires, edges, or faces, an assertion will be throw in the
     // generation of the Manifold.
     //
-    // We use the Patterns::Tools::Convert class to do the convertion from the
+    // We use the Patterns::Tools::Convert class to do the conversion from the
     // string to a map between manifold ids and file names for us:
 
 #ifdef DEAL_II_WITH_OPENCASCADE
@@ -893,7 +893,7 @@ namespace Step70
     // particles. This mimics what would happen in the case where another
     // problem was solved in the solid domain (as in fluid-structure
     // interaction. In this latter case, additional DOFs on the solid domain
-    // would be coupled to what is occuring in the fluid domain.
+    // would be coupled to what is occurring in the fluid domain.
     relevant_tracer_particles = owned_tracer_particles;
 
     // Now make sure that upon refinement, particles are correctly transferred.
@@ -1295,7 +1295,7 @@ namespace Step70
         local_matrix = 0;
         local_rhs    = 0;
 
-        // We get the refence to the cell within which the particle lies from
+        // We get the reference to the cell within which the particle lies from
         // the particle itself. Consequently, we can assemble the additional
         // terms in the system matrix the rhs as we would normally.
         const auto &cell = particle->get_surrounding_cell(fluid_tria);
@@ -1782,7 +1782,7 @@ namespace Step70
       Functions::ParsedFunction<spacedim>::declare_parameters(this->prm,
                                                               spacedim + 1);
     });
-    // and define a meaningful default angular velocity instaed of zero
+    // and define a meaningful default angular velocity instead of zero
     angular_velocity.declare_parameters_call_back.connect([&]() {
       this->prm.set("Function expression",
                     "t < .500001 ? 6.283185 : -6.283185");

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.