From 0c1767643bf6e38e4bbaf6b4fa42b775f6758eca Mon Sep 17 00:00:00 2001 From: David Wells Date: Fri, 15 May 2020 13:47:50 -0400 Subject: [PATCH] Improve spelling in step-70. --- examples/step-70/doc/intro.dox | 12 +++++------ examples/step-70/doc/results.dox | 10 ++++----- examples/step-70/step-70.cc | 36 ++++++++++++++++---------------- 3 files changed, 29 insertions(+), 29 deletions(-) diff --git a/examples/step-70/doc/intro.dox b/examples/step-70/doc/intro.dox index 15b8a1e9e2..78d4f5c574 100644 --- a/examples/step-70/doc/intro.dox +++ b/examples/step-70/doc/intro.dox @@ -20,7 +20,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 @@ -60,7 +60,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. @@ -203,7 +203,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. @@ -232,7 +232,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 @@ -285,7 +285,7 @@ to impose the boundary condition over $\Gamma$.

Co-dimension zero case

-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: @@ -323,7 +323,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. diff --git a/examples/step-70/doc/results.dox b/examples/step-70/doc/results.dox index c8f2371e6e..d81bc77517 100644 --- a/examples/step-70/doc/results.dox +++ b/examples/step-70/doc/results.dox @@ -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. diff --git a/examples/step-70/step-70.cc b/examples/step-70/step-70.cc index 4ae89c7648..ed07f009ff 100644 --- a/examples/step-70/step-70.cc +++ b/examples/step-70/step-70.cc @@ -150,11 +150,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 @@ -189,7 +189,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; @@ -227,8 +227,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 homogeneous_dirichlet_ids{0}; @@ -240,7 +240,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, Point, std::set, etc.) are comma @@ -265,7 +265,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. // @@ -287,7 +287,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 @@ -354,7 +354,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`: @@ -435,7 +435,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(); @@ -445,7 +445,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(); @@ -584,7 +584,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, @@ -616,7 +616,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 StokesImmersedProblem::StokesImmersedProblem( @@ -664,14 +664,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 @@ -894,7 +894,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); @@ -1785,7 +1785,7 @@ namespace Step70 Functions::ParsedFunction::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"); -- 2.39.5