From: David Wells Date: Sat, 7 Mar 2020 20:31:05 +0000 (-0500) Subject: step-69: improve spelling. X-Git-Tag: v9.2.0-rc1~441^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F9638%2Fhead;p=dealii.git step-69: improve spelling. --- diff --git a/examples/step-69/doc/intro.dox b/examples/step-69/doc/intro.dox index 508c44d0ce..4659c8895b 100644 --- a/examples/step-69/doc/intro.dox +++ b/examples/step-69/doc/intro.dox @@ -23,7 +23,7 @@ time integration, see @cite GuermondEtAl2018. @dealiiTutorialDOI{10.5281/zenodo.3698223,https://zenodo.org/badge/DOI/10.5281/zenodo.3698223.svg} -

Introduction

This tutorial presents a first-order scheme for solving compressible @@ -103,7 +103,7 @@ the solution itself does not lead to an energy estimate because the pairing $\langle \text{div} \, \mathbb{f}(\mathbf{u}), \mathbf{u}\rangle$ (understood as the $L^2(\Omega)$ inner product or duality pairing) is not guaranteed to be non-negative. Notions such as energy-stability or $L^2(\Omega)$-stability are -(in general) meaningles in this context. +(in general) meaningless in this context. Historically, the most fruitful step taken in order to deepen the understanding of hyperbolic conservation laws was to assume that the @@ -115,7 +115,7 @@ of the parabolic regularization - {\epsilon} \Delta \mathbf{u}^{\epsilon} = 0. @f} Such solutions, which are understood as the solution recovered in the -zero-viscosity limit, are often refered to as viscosity solutions. +zero-viscosity limit, are often referred to as viscosity solutions. (This is, because physically $\epsilon$ can be understood as related to the viscosity of the fluid, i.e., a quantity that indicates the amount of friction neighboring gas particles moving at different speeds exert on each other. The Euler equations themselves are derived under @@ -150,7 +150,7 @@ be satisfied at every point of the domain, not just in an averaged (integral, or high order moments) sense. In context of a numerical approximation, a violation of such a constraint -has dire consequences: it almost surely leads to catrastrophic failure of +has dire consequences: it almost surely leads to catastrophic failure of the numerical scheme, loss of hyperbolicity, and overall, loss of well-posedness of the (discrete) problem. It would also mean that we have computed something that can not be interpreted physically. (For example, what are we to make @@ -281,12 +281,12 @@ where \lambda_{\text{max}} (\mathbf{U}_j^{n}, \mathbf{U}_i^{n}, \textbf{n}_{ji}) \} \|\mathbf{c}_{ij}\|$ if $i \not = j$ is the so called graph viscosity. The graph viscosity serves as a - stabilization term, it is omewhat the discrete counterpart of + stabilization term, it is somewhat the discrete counterpart of $\epsilon \Delta \mathbf{u}$ that appears in the notion of viscosity solution described above. We will base our construction of $d_{ij}$ on an estimate of the maximal local wavespeed $\lambda_{\text{max}}$ that will be explained in detail in a moment. - - the diagonal entres of the viscosity matrix are defined as + - the diagonal entries of the viscosity matrix are defined as $d_{ii} = - \sum_{j \in \mathcal{I}(i)\backslash \{i\}} d_{ij}$. - $\textbf{n}_{ij} = \frac{\mathbf{c}_{ij}}{ \|\mathbf{c}_{ij}\| }$ is a normalization of the $\textbf{c}_{ij}$ matrix that enters the @@ -296,7 +296,7 @@ where The definition of $\lambda_{\text{max}} (\mathbf{U},\mathbf{V}, \textbf{n})$ is far from trivial and we will postpone the precise -definition in order to focus first on some algorithmic and implementational +definition in order to focus first on some algorithmic and implementation questions. We note that - $m_i$ and $\mathbf{c}_{ij}$ do not evolve in time (provided we keep the discretization fixed). It thus makes sense to assemble these @@ -357,7 +357,7 @@ the time-step size $\tau$ has to be chosen subject to a CFL condition i\in\mathcal{V}}\left(\frac{m_i}{-2\,d_{ii}^{n}}\right), @f} where $0Discretization class, or a single // method (such as the make_one_step() function of the -// TimeStepping class). We typically declare parameter variables +// %TimeStepping class). We typically declare parameter variables // and scratch data object `private` and make methods and data structures // used by other classes `public`. // @@ -351,12 +351,12 @@ namespace Step69 Tensor<1, 3> initial_1d_state; }; - // @sect4{The TimeStepping class} + // @sect4{The %TimeStepping class} // // With the OfflineData and ProblemDescription // classes at hand we can now implement the explicit time-stepping scheme // that was introduced in the discussion above. The main method of the - // TimeStepping class is make_one_step(vector_type &U, + // %TimeStepping class is make_one_step(vector_type &U, // double t) that takes a reference to a state vector // U and a time point t (as input arguments) // computes the updated solution, stores it in the vector @@ -457,7 +457,7 @@ namespace Step69 // @sect4{The MainLoop class} // // Now, all that is left to do is to chain the methods implemented in the - // TimeStepping, InitialValues, and + // %TimeStepping, InitialValues, and // SchlierenPostprocessor classes together. We do this in a // separate class MainLoop that contains an object of every // class and again reads in a number of parameters with the help of the @@ -705,7 +705,7 @@ namespace Step69 // assemble the local part of a matrix exclusively on a given MPI // rank. Instead, we will compute nonlinear updates while iterating // over (the local part) of a connectivity stencil; a task for which - // deal.II's own SparsityPattern is specificially optimized for. + // deal.II's own SparsityPattern is specifically optimized for. // // This design consideration has a caveat, though. What makes the // deal.II SparseMatrix class fast is the on_subranges lambda we need to name the iterator type // of the object returned by boost::irange(). This is unfortunately a very convoluted name exposing - // implementational details about boost::irange. For this + // implementation details about boost::irange. For this // reason we resort to the decltype // specifier, a C++11 feature that returns the type of an entity, or @@ -1280,7 +1280,7 @@ namespace Step69 // Finally, we normalize the vectors stored in // OfflineData::BoundaryNormalMap. This operation has - // not been thread paralellized as it would neither illustrate any + // not been thread parallelized as it would neither illustrate any // important concept nor lead to any noticeable speed gain. for (auto &it : boundary_normal_map) { @@ -1809,7 +1809,7 @@ namespace Step69 // @sect4{The Forward Euler step} - // The constructor of the TimeStepping class does not contain + // The constructor of the %TimeStepping class does not contain // any surprising code: template @@ -1881,7 +1881,7 @@ namespace Step69 // symmetric, i.e., $d_{ij} = d_{ji}$. In this regard we note here that // $\int_{\Omega} \nabla \phi_j \phi_i \, \mathrm{d}\mathbf{x}= - // \int_{\Omega} \nabla \phi_i \phi_j \, \mathrm{d}\mathbf{x}$ (or - // equivanlently $\mathbf{c}_{ij} = - \mathbf{c}_{ji}$) provided either + // equivalently $\mathbf{c}_{ij} = - \mathbf{c}_{ji}$) provided either // $\mathbf{x}_i$ or $\mathbf{x}_j$ is a support point located away // from the boundary. In this case we can check that // $\lambda_{\text{max}} (\mathbf{U}_i^{n}, \mathbf{U}_j^{n}, @@ -2299,7 +2299,7 @@ namespace Step69 // The second thing to note is that we have to compute global minimum and // maximum $\max_j |\nabla r_j|$ and $\min_j |\nabla r_j|$. Following the // same ideas used to compute the time step size in the class member - // TimeStepping::step() we define $\max_j |\nabla r_j|$ + // %TimeStepping::step() we define $\max_j |\nabla r_j|$ // and $\min_j |\nabla r_j|$ as atomic doubles in order to resolve any // conflicts between threads. As usual, we use // Utilities::MPI::max() and