From: David Wells Date: Tue, 8 May 2018 16:57:40 +0000 (-0400) Subject: Fix some typos in step-60. X-Git-Tag: v9.0.0-rc5~1^2~5 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=35bcd5115c0690090885945a3d052b2af97d917e;p=dealii.git Fix some typos in step-60. --- diff --git a/examples/step-60/doc/intro.dox b/examples/step-60/doc/intro.dox index 00a45c6219..3c74b6c8bc 100644 --- a/examples/step-60/doc/intro.dox +++ b/examples/step-60/doc/intro.dox @@ -50,7 +50,7 @@ href="https://en.wikipedia.org/wiki/Trace_operator">this wikipedia article for further details on the trace operator). The co-dimension two case is a little more complicated, and in general it is not -possible to construct a continous trace operator, not even from $H^1(\Omega)$ to +possible to construct a continuous trace operator, not even from $H^1(\Omega)$ to $L^2(\Gamma)$, when the dimension of $\Gamma$ is zero or one respectively in two and three dimensions. diff --git a/examples/step-60/doc/results.dox b/examples/step-60/doc/results.dox index 94b3a51370..f914d14499 100644 --- a/examples/step-60/doc/results.dox +++ b/examples/step-60/doc/results.dox @@ -263,7 +263,7 @@ DEAL:cg::Convergence step 108 value 7.65958e-13 You may notice that, in terms of CPU time, assembling the coupling system is twice as expensive as assembling the standard Poisson system, even though the matrix is smaller. This is due to the non-matching nature of the discretization. -Wether this is acceptable or not, depends on the applications. +Whether this is acceptable or not, depends on the applications. If the problem was set in a three-dimensional setting, and the immersed mesh was time dependent, it would be much more expensive to recreate the mesh at each @@ -273,7 +273,7 @@ grid, and embed the domain where you want to perform your computation using the technique presented here. This would require you to only have a surface representatio of your domain (a much cheaper and easier mesh to produce). -To play around a little bit, we are going to complicate a little the ficticious +To play around a little bit, we are going to complicate a little the fictitious domain as well as the boundary conditions we impose on it.

Test case 2 and 3:

diff --git a/examples/step-60/step-60.cc b/examples/step-60/step-60.cc index d9cbdf5727..660b5dcd14 100644 --- a/examples/step-60/step-60.cc +++ b/examples/step-60/step-60.cc @@ -30,7 +30,7 @@ // executable can be run with different parameter settings, it can become // difficult to handle hundreds of parameters simultaneously while maintaining // compatibility between different programs. This is where the class -// Parame terAcceptor proves useful. +// ParameterAcceptor proves useful. // // This class is used to define a public interface for classes that want to use // a single global ParameterHandler to handle parameters. The class provides a @@ -70,12 +70,12 @@ // organized following a Directed Acyclic Graph (DAG). A DAG is a directed graph // with topological ordering: each node structurally represents an object, and // is connected to child nodes by one (or more) oriented edges, from the parent -// to the child. The most significative example of this structure is the +// to the child. The most significant example of this structure is the // Triangulation and its Triangulation::cell_iterator structure. From a // Triangulation (the main node), we can access each cell (children nodes of the // triangulation). From the cells themselves we can access over all vertices of // the cell. In this simple example, the DAG structure can be represented as -// thre node types (the triangulation, the cell iterator, and the vertex) +// three node types (the triangulation, the cell iterator, and the vertex) // connected by oriented edges from the triangulation to the cell iterators, and // from the cell iterator to the vertices. This has several advantages, but it // intrinsically creates “asymmetries”, making certain operations fast and their @@ -97,7 +97,7 @@ // somewhere. GridTools::Cache does exactly this, giving you access to // previously computed objects, or computing them on the fly (and then storing // them inside the class for later use), and making sure that whenever the -// Triangulation is updated, also the relevant data strucutres are recomputed. +// Triangulation is updated, also the relevant data structures are recomputed. #include #include @@ -411,7 +411,7 @@ namespace Step60 Vector embedded_rhs; Vector embedded_value; - // The TimerOuput class is used to provide some statistics on + // The TimerOutput class is used to provide some statistics on // the performance of our program. TimerOutput monitor; }; @@ -425,7 +425,7 @@ namespace Step60 // Parameter files can be organized into section/subsection/etc.: // this has the advantage that defined objects share parameters when // sharing the same section/subsection/etc. ParameterAcceptor allows - // to specify the section name using unix conventions on paths. + // to specify the section name using Unix conventions on paths. // If the section name starts with a slash ("/"), then the section is // interpreted as an *absolute path*, ParameterAcceptor enters a subsection // for each directory in the path, using the last name it encountered as @@ -694,7 +694,7 @@ namespace Step60 // according to the type of FiniteElement you choose. MappingFEField // implements the pure iso-parametric concept, and can be used, for example, // to implement iso-geometric analysis codes in deal.II, by combining it - // with the FEBernstein finite element class. In this example, we'll use the + // with the FE_Bernstein finite element class. In this example, we'll use the // two interchangeably, by taking into account the fact that one // configuration will be a `displacement`, while the other will be an // absolute `deformation` field. @@ -746,7 +746,7 @@ namespace Step60 // but also allow a local refinement depending on the position of $\Gamma$, // according to the value of `parameters.delta_refinement`, that we use to // decide how many rounds of local refinement we should do on $\Omega$, - // corresponding to the the position of $\Gamma$. + // corresponding to the position of $\Gamma$. // // With the mapping in place, it is now possible to query what is the // location of all support points associated with the `embedded_dh`, by @@ -769,14 +769,14 @@ namespace Step60 // support point, to get a chance at refining the embedding grid where it is // necessary, i.e., where the embedded grid is. This can be done manually, // by looping over each support point, and then calling the method - // Mapping::tranform_real_to_unit_cell for each cell of the embedding space, + // Mapping::transform_real_to_unit_cell for each cell of the embedding space, // until we find one that returns points in the unit reference cell, or it // can be done in a more intelligent way. // // The GridTools::find_active_cell_around_point is a possible option that // performs the above task in a cheaper way, by first identifying the // closest vertex of the embedding Triangulation to the target point, and - // then by calling Mapping::tranform_real_to_unit_cell only for those cells + // then by calling Mapping::transform_real_to_unit_cell only for those cells // that share the found vertex. // // In fact, there are algorithms in the GridTools namespace that exploit a @@ -906,7 +906,7 @@ namespace Step60 // Creating the coupling sparsity pattern is a complex operation, // but it can be easily done using the // NonMatching::create_coupling_sparsity_pattern, which requires the - // two DoFHandlers, the quadrature points for the coupling, + // two DoFHandler​s, the quadrature points for the coupling, // a DynamicSparsityPattern (which then needs to be copied into the // sparsity one, as usual), the component mask for the embedding and // embedded Triangulation (which we leave empty) and the mappings