Fix typos and spelling in the docs

doc/sphinx/src/building.rst

@@ -163,7 +163,7 @@ preconditions:
 ============================================== ================================================================================= ===========================================
 
 When installing ``singularity-eos``, data files are also installed. The
-follwing options control where the data files are installed:
+following options control where the data files are installed:
 
 ====================================== ======= ===========================================
   Option                               Default  Comment
@@ -395,7 +395,7 @@ To start using Spack, we use the provided activation script
    $> source ~/spack/share/spack/setup-env.sh
 
 You will always need to *activate* spack for each new shell. You may
-find it convienant to invoke this Spack setup in your login script,
+find it convenient to invoke this Spack setup in your login script,
 though be aware that Spack will prepend paths to your environment which
 may cause conflicts with other package tools and software.
 
@@ -422,7 +422,7 @@ However, Spack has put in a lot of effort to be able to automatically
 discover the available tools and software on any given system. While not
 perfect, we can get a fairly robust starting point.
 
-Assume we are on an HPC system that has Envionrmental Modules that
+Assume we are on an HPC system that has Environmental Modules that
 provides compilers, MPI implementations, and sundry other common tools.
 To help Spack find these, let's load a specific configuration into the
 active shell environment.

doc/sphinx/src/contributing.rst

@@ -12,7 +12,7 @@ repository, or submit a pull request!
 Pull request protocol
 ----------------------
 
-There is a pull reuqest template that will be auto-populated when you
+There is a pull request template that will be auto-populated when you
 submit a pull request. A pull request should have a summary of
 changes. You should also add tests for bugs fixed or new features you
 add.
@@ -36,7 +36,7 @@ useful output. For example:
     CFM=clang-format-12 VERBOSE=1 ./util/scripts/format.sh
 
 Several sets of tests are triggered on a pull request: a static format
-check, a docs buld, and unit tests of analytic models and the stellar
+check, a docs build, and unit tests of analytic models and the stellar
 collapse model. These are run through GitHub's CPU infrastructure. We
 have a second set of tests run on a wider set of architectures that
 also access the Sesame library, which we are not able to make public.
@@ -72,7 +72,7 @@ be requested to split your pull request into two or more separate
 contributions. You may also receive many "nitpicky" comments about
 code style or structure. These comments help keep a broad codebase,
 with many contributors uniform in style and maintainable with
-consistent expectations accross the code base. While there is no
+consistent expectations across the code base. While there is no
 formal style guide for now, the regular contributors have a sense for
 the broad style of the project. You should take these stylistic and
 "nitpicky" suggestions seriously, but you should also feel free to
@@ -81,7 +81,7 @@ push back.
 As with any creative endeavor, we put a lot of ourselves into our
 code. It can be painful to receive criticism on your contribution and
 easy to take it personally. While you should resist the urge to take
-offense, it is also partly code reviewer's responsiblity to create a
+offense, it is also partly code reviewer's responsibility to create a
 constructive environment, as discussed below.
 
 Expectations of code reviewers
@@ -100,7 +100,7 @@ congenial:
   want to try this other pattern."
 
 * Avoid language that can be misconstrued, even if it's common
-  notation in the commnunity. For example, avoid phrases like "code
+  notation in the community. For example, avoid phrases like "code
   smell."
 
 * Explain why you make a suggestion. In addition to saying "try X
@@ -117,7 +117,7 @@ congenial:
 General principle for everyone
 ```````````````````````````````
 
-It's hard to convey tone in text correspondance. Try to read what
+It's hard to convey tone in text correspondence. Try to read what
 others write favorably and try to write in such a way that your tone
 can't be mis-interpreted as malicious.
 
@@ -147,7 +147,7 @@ The basic process for adding a new EOS can be summarized as
 #. Create a Fortran interface to initialize your EOS into an array of EOS
 
 In addition to these main steps, there are a couple more that are required if
-you would like your EOS to work with our fortran interface, which will be
+you would like your EOS to work with our Fortran interface, which will be
 discussed below.
 
 Step 1: Create a new header file for your EOS
@@ -156,7 +156,7 @@ Step 1: Create a new header file for your EOS
 In general, the best practice is to simply copy an existing EOS file and modify
 it for the new EOS. However, there are some subtleties here that are important.
 
-- Parameters for the EOS can be initialzed via an initializer list, and
+- Parameters for the EOS can be initialized via an initializer list, and
   additional parameter checking can be done in the constructor.
 - Any EOS must have a set of member functions that conform to the general
   :ref:`EOS API<eos methods reference section>`. In essence, these functions are
@@ -291,7 +291,7 @@ At this point your new EOS should be usable to any host code written in C++. To
 allow the EOS to work with Fortran, an initializer wrapper function needs to be
 defined and interfaced with Fortran.
 
-First, the C++ intialization function needs to be named soas to avoid namespace
+First, the C++ initialization function needs to be named so as to avoid namespace
 conflicts. We typically name the initialization functions ``init_sg_<EOSName>``.
 For example, the function for initialing an ideal gas looks like
 
@@ -329,7 +329,7 @@ We also overload the initialization function to make the ``enabled`` and
       return init_sg_IdealGas(matindex, eos, gm1, Cv, def_en, def_v);
     }
 
-Finally the fortran side, we then define a fortran interface to the C++
+Finally the Fortran side, we then define a Fortran interface to the C++
 initialization function,
 
 .. code-block:: fortran
@@ -347,7 +347,7 @@ initialization function,
         end function init_sg_IdealGas
       end interface
 
-and a fortran wrapper function to call the C++ function:
+and a Fortran wrapper function to call the C++ function:
 
 .. code-block:: fortran
 
@@ -370,13 +370,13 @@ A Note on the EOS Builder
 `````````````````````````
 
 The :ref:`EOS Builder <eos builder section>` is a tool that eliminates the need
-for chaining together an EOS with a series of modifiers by instead specifing
+for chaining together an EOS with a series of modifiers by instead specifying
 the parameters and modifications in one function. This convenience comes at the
 cost of added development complexity though, and so we do not require a new EOS
 to be available for the EOS Builder.
 
 At a basic level though, the EOS needs to be declared in the ``EOSType`` enum
-and logic needs to be added to initialze the EOS parameters. More effort may be
+and logic needs to be added to initialize the EOS parameters. More effort may be
 needed to make the EOS compatible with modifiers and we point the interested
 contributor to the existing EOS as examples.
 
@@ -408,7 +408,7 @@ Some notes on style and code architecture
 * A major influence on code style and architecture is the
   `ten rules for developing safety-critical code`_, by Gerard Holzmann.
   Safety critical code is code that exists in a context where failure
-  implies serious harm. A flight controler on an airplane or
+  implies serious harm. A flight controller on an airplane or
   spacecraft or the microcontroller in a car are examples of
   safety-critical contexts. ``singularity-eos`` is not safety-critical
   but many of the coding habits advocated for by Holzmann produce
@@ -469,7 +469,7 @@ style. Here we briefly discuss a few things one should be aware of.
   ``PORTABLE_INLINE_FUNCTION``,
   ``PORTABLE_FORCEINLINE_FUNCTION``. These macros are imported from
   the `ports-of-call`_ library and resolve to the appropriate
-  decorations for a given device-side backend such as cuda so the code
+  decorations for a given device-side backend such as Cuda so the code
   compiles correctly. Code that doesn't need to run on device,
   such as EOS class constructors, does not need these decorations.
 
@@ -500,7 +500,7 @@ style. Here we briefly discuss a few things one should be aware of.
   "reference-semantics." This means that if you copy an EOS object, it
   should always be a shallow copy, not a deep copy, unless a deep copy
   is explicitly requested. This is for performance reasons and also to
-  simplify the managment of data on device.
+  simplify the management of data on device.
 
 * **Real:** The ``Real`` datatype is either a single precision or
   double precision floating point number, depending on how

doc/sphinx/src/models.rst

@@ -34,7 +34,7 @@ EOS Theory
 
 An equation of state (EOS) is a constituitive model that generally relates
 thermodynamic quantities such as pressure, temperature, density, internal
-energy, free energy, and entropy consistent with the constraints of equillibrium
+energy, free energy, and entropy consistent with the constraints of equilibrium
 thermodynamics.
 
 ``singularity-eos`` contains a number of equations of state that are most useful
@@ -75,7 +75,7 @@ To some degree it is the complexity of the reference state and the heat
 capacity that will determine an EOS's ability to capture the complex behavior of
 a material. At the simplest level, the ideal gas EOS uses a reference state at
 zero pressure and energy, while more complex equations of state such as the
-Davis EOS use the material's isentrope. In ths way, the reference curve
+Davis EOS use the material's isentrope. In this way, the reference curve
 indicates the conditions under which you can expect the EOS to represent the
 intended behavior.
 
@@ -106,7 +106,7 @@ where all potentials are specific. Here :math:`e` is again the internal energy,
 is the Gibbs free energy. While equations of state formulated using the
 Helmholtz free energy can be particularly attractive (such as the sesame
 tables), finding a convenient form can be difficult. As such, it becomes
-imperitive to extend the Mie-Gruneisen form so that it can form a complete
+imperative to extend the Mie-Gruneisen form so that it can form a complete
 EOS.
 
 The heat capacity is defined as
@@ -222,7 +222,7 @@ the electron equation of state or ion equation of state.
 
 The tabulated models may also support loading tables specifically for
 electron or ion equations of state. In these cases, an ``enum class``
-specifies which component of the material is being requst:
+specifies which component of the material is being requested:
 
 .. code-block:: cpp
 
@@ -232,7 +232,7 @@ where here ``ElectronOnly`` is the free electrons of the material,
 corresponding to Sesame 304 tables, ``IonCold`` is the ions plus cold
 curve (i.e., the ions if you don't know what a cold curve is),
 corresponding to the Sesame 303 tables, and ``Total`` is the sum of
-free electrons and ions, correspodning to the Sesame 301 tables.
+free electrons and ions, corresponding to the Sesame 301 tables.
 
 .. note::
 
@@ -355,7 +355,7 @@ Nomenclature Disambiguation
 The Gruneisen Parameter
 '''''''''''''''''''''''
 In this description of the EOS models, we use :math:`\Gamma` to represent the
-Gruneisen coeficient since this is the most commonly-used symbol in the
+Gruneisen coefficient since this is the most commonly-used symbol in the
 context of Mie-Gruneisen equations of state. The definition of the Gruneisen
 parameter is
 
@@ -870,7 +870,7 @@ Gruneisen EOS
 
 One of the most commonly-used EOS to represent solids is the Steinberg variation
 of the Mie-Gruneisen EOS, often just shortened to "Gruneisen" EOS. This EOS
-uses the Hugoniot as the reference curve and thus is extremly powerful because
+uses the Hugoniot as the reference curve and thus is extremely powerful because
 the basic shock response of a material can be modeled using minimal parameters.
 
 The pressure follows the traditional Mie-Gruneisen form,
@@ -896,7 +896,7 @@ The user should note that this implies that :math:`e=0` at the reference
 temperature, :math:`T_0`. Given this simple relationship, the user should
 treat the temperature from this EOS as only a rough estimate.
 
-Given the inconsisetency in the temperature, we have made the choice **not** to
+Given the inconsistency in the temperature, we have made the choice **not** to
 expose the entropy for this EOS. **Requesting an entropy value will result in an
 error.**
 
@@ -927,7 +927,7 @@ When the unitless user parameter :math:`b=0`, the Gruneisen parameter is of a
 form where :math:`\rho\Gamma =` constant in compression, i.e. when
 :math:`\eta > 0`.
 If the unitless user parameter :math:`b=\Gamma_0`, the Gruneisen parameter is of a
-form where :math:`\Gamma_0 =` constant in compression. These two limitig cases are 
+form where :math:`\Gamma_0 =` constant in compression. These two limiting cases are
 shown in the figure below.
 
 .. image:: ../SteinbergGammarho.png
@@ -946,7 +946,7 @@ The reference pressure along the Hugoniot is determined by
       \end{cases}
 
 where :math:`P_0` is the reference pressure and :math:`c_0`, :math:`s_1`,
-:math:`s_2`, and :math:`s_3` are fitting paramters to the
+:math:`s_2`, and :math:`s_3` are fitting parameters to the
 :math:`U_s`-:math:`u_p` curve such that
 
 .. math::
@@ -1002,7 +1002,7 @@ There is an overload of the ``Gruneisen`` class which computes
 Both constructors also optionally accept `MeanAtomicProperties` for
 the atomic mass and number as a final optional parameter.
 
-Extendended Vinet EOS
+Extended Vinet EOS
 `````````````````````
 
 The extended Vinet EOS is a full EOS, extended in both temperature and density
@@ -1172,7 +1172,7 @@ Solving the jump equations above gives that the reference pressure along the Hug
 
 Note the singularity at :math:`s \eta = 1` which limits this model's validity to compressions
 :math:`\eta << 1/s`. If your problem can be expected to have compressions of this order, you should use the PowerMG
-EOS that is explicitely constructed for large compressions. 
+EOS that is explicitly constructed for large compressions.
 The assumption of linear :math:`U_s`- :math:`u_p` relation is simply not valid at large compressions.
 
 The energy along the Hugoniot is given by
@@ -1181,7 +1181,7 @@ The energy along the Hugoniot is given by
 
     E_H(\rho) = \frac{P_H \eta }{2 \rho_0} + E_0 .
 
-The temperature on the Hugoniot is hard to derive explicitely but with the help of Mathematica
+The temperature on the Hugoniot is hard to derive explicitly but with the help of Mathematica
 we can solve
 
 .. math::
@@ -1239,7 +1239,7 @@ the atomic mass and number as a final optional parameter.
 Mie-Gruneisen power expansion EOS
 `````````````````````````````````
 As we noted above, the assumption of a linear :math:`U_s`- :math:`u_p` relation is simply not valid at large compressions. At 
-Sandia National Laboratories Z-pinch machine, the compression is routinely so large that a new Mie-Gruneisen EOS was developped,
+Sandia National Laboratories Z-pinch machine, the compression is routinely so large that a new Mie-Gruneisen EOS was developed,
 by `Robinson <PowerMG_>`_, that could handle these large compressions. The overall structure and motivation for approximations 
 are as described above; in compression it is only the formula for :math:`P_H`, and by extension :math:`T_H`, that differ. This 
 EOS is however modified in expansion to follow an isentrope instead of the invalid-in-expansion Hugoniot.
@@ -1453,7 +1453,7 @@ Using the fact that the heat capacity can be expressed as
 
     C_V = T\left( \frac{\partial S}{\partial T} \right)_V,
 
-the temperature off of the reference isoentrope can be integrated from this
+the temperature off of the reference isentrope can be integrated from this
 identity to yield
 
 .. math::
@@ -1469,7 +1469,7 @@ expressed as a function of temperature and density such that
     S(\rho, T) = \frac{C_{V,0}}{\alpha} \left( \frac{T}{T_{S,0}(\rho)} \right)^\alpha.
 
 The :math:`e(\rho, P)` formulation can now be more-conveniently cast in terms of
-termperature such that
+temperature such that
 
 .. math::
 
@@ -1496,7 +1496,7 @@ Finally, the pressure and energy along the isentrope are given by
 
 
 where :math:`A`, :math:`B`, :math:`C`, :math:`y`, and :math:`Z` are all
-user-settable parameters and again quantities with a subcript of :math:`0`
+user-settable parameters and again quantities with a subscript of :math:`0`
 refer to the reference state. The variable :math:`\bar{\rho}` is simply an
 integration variable. The parameter :math:`C` is especially useful for ensuring
 that the high-pressure portion of the shock Hugoniot does not cross that of the
@@ -1531,7 +1531,7 @@ Davis Products EOS
 
 The Davis products EOS is created from the reference isentrope passing through
 the CJ state of the high explosive along with a constant heat capacity. The
-constant heat capacity leads to the energy being a simple funciton of the
+constant heat capacity leads to the energy being a simple function of the
 temperature deviation from the reference isentrope such that
 
 .. math::

doc/sphinx/src/modifiers.rst

@@ -11,7 +11,7 @@ given EOS model by shifting all energies up or down. Modifiers can be
 used to, for example, production-harden a model.
 
 Only certain combinations of ``EOS`` and ``modifier`` are permitted by
-the defualt ``Variant``. For example, only ``IdealGas``,
+the default ``Variant``. For example, only ``IdealGas``,
 ``SpinerEOS``, and ``StellarCollapse`` support the ``RelativisticEOS``
 and ``UnitSystem`` modifiers. All models support the ``ShiftedEOS``
 and ``ScaledEOS`` modifiers. However, note that modifiers do not
@@ -59,7 +59,7 @@ To understand the scaled EOS, consider the pressure for an ideal gas:
 
   P = \Gamma \rho \varepsilon
 
-where here :math:`\Gamma` is the Gruneien parameter, :math:`\rho` is
+where here :math:`\Gamma` is the Gruneisen parameter, :math:`\rho` is
 the density, and :math:`\varepsilon` is the specific internal
 energy. The pressure is unchanged under the operation
 
@@ -99,7 +99,7 @@ this scaling to the definition of the Helmholtz free energy yields
   F_\mathrm{eos} = e_\mathrm{eos} - TS_\mathrm{eos} = \frac{1}{R} F_\mathrm{in}
     = \frac{1}{R}e_\mathrm{in} - T\left(\frac{1}{R}S_\mathrm{in}\right),
 
-where the implicaiton is that this inverse the scaling ratio should also be
+where the implication is that this inverse the scaling ratio should also be
 applied to energy. The inverse scaling ratio must be applied to the entropy
 here in order to ensure that all other thermodynamic potentials
 (energy, entropy, and the Gibbs free energy) scale similarly.

doc/sphinx/src/philosophy.rst

@@ -44,7 +44,7 @@ This also motivates the hot-swappable modifiers for equation of state
 models. Capturing real-world material, or production-hardening an
 equation of state can be challenging and imperfect. The modifiers
 allow the user to ensure an EOS meets their needs, in a way that is
-reproducible and comparable accross host codes.
+reproducible and comparable across host codes.
 
 No Compromise on Performance Portability
 ------------------------------------------
@@ -56,6 +56,6 @@ Performance, Flexibility, Usability, and Extendability
 --------------------------------------------------------
 
 We recognize that performance, runtime usability and flexibility, and
-extendability are all imporant, and do our best to navigate this
+extendability are all important, and do our best to navigate this
 trade-space. We write our code in as modular a way as possible, but we
 recognize that sometimes abstraction gets in the way.