However, in the transonic and supersonic regime, and shock-hydrodynamics
applications the use of variational schemes might be questionable. In fact,
at the time of this writing, most shock-hydrodynamics codes are still
-firmly grounded on finite volumes methods. The main reason for failure of
+firmly grounded on finite volume methods. The main reason for failure of
variational schemes in such extreme regimes is the lack of pointwise
stability. This stems from the fact that <i>a priori</i> bounds on
integrated quantities (e.g. integrals of moments) have in general no
to always work, all the time, no exception. This illustrates that deal.II
can be used far beyond the context of variational schemes in Hilbert spaces
and that a large number of classes, modules and namespaces from deal.II can
-be adapted for such purpose.
+be adapted for such a purpose.
<h3>Description of the scheme </h3>
<i>graph-based</i> finite element schemes (see for instance
@cite Rainald2008 for a historical overview). However, it is important to
highlight that the algebraic structure of the scheme (presented in this
-tutorial) and the node-loops are not just performance gimmick. Actually, the
+tutorial) and the node-loops are not just a performance gimmick. Actually, the
structure of this scheme was born out of theoretical necessity: the proof of
pointwise stability of the scheme hinges on the specific algebraic structure of
the scheme. In addition, it is not possible to compute the algebraic
// initialize everything that does not depend on parameters in the
// constructor, and defer the creation of the mesh to the
// <code>setup()</code> method that can be called once all parameters are
- // read-in via ParameterAcceptor::initialize().
+ // read in via ParameterAcceptor::initialize().
template <int dim>
class Discretization : public ParameterAcceptor
{
// members of <code>OfflineData</code> have well-defined values
// independent of the current time step. This means that they can be
// initialized ahead of time (at <i>time step zero</i>) and are not meant
- // to be modified at any other later time step. For instance, the
+ // to be modified at any later time step. For instance, the
// sparsity pattern should not change as we advance in time (we are not
// doing any form of adaptivity in space). Similarly, the entries of the
// lumped mass matrix should not be modified as we advance in time
// contains a map from a global index of type types::global_dof_index of
// a boundary degree of freedom to a tuple consisting of a normal vector,
// the boundary id, and the position associated with the degree of
- // freedom. We actually have to compute and store this geometric
+ // freedom. We have to compute and store this geometric
// information in this class because we won't have access to geometric
// (or cell-based) information later on in the algebraic loops over the
// sparsity pattern.
// guess for an upper bound on the maximum wavespeed. More precisely,
// equations (2.11) (3.7), (3.8) and (4.3) of @cite GuermondPopov2016b
// are enough to define a guaranteed upper bound on the maximum
- // wavespeed. This estimate is returned by the a call to the function
+ // wavespeed. This estimate is returned by a call to the function
// <code>lambda_max_two_rarefaction()</code>. At its core the
// construction of such an upper bound uses the so-called two-rarefaction
// approximation for the intermediate pressure $p^*$, see for instance
projects / dealii.git / commitdiff