CI: Add codespell (#133)

.codespell-ignore-words

@@ -0,0 +1,3 @@
+Blocs
+ptd
+recuse

.codespellrc

@@ -0,0 +1,3 @@
+[codespell]
+skip = .git,*.ipynb,*.bib,*.ps,*.patch,*~,CHANGES,*/tmp_build_dir
+ignore-words = .codespell-ignore-words

.github/workflows/codespell.yml

@@ -0,0 +1,23 @@
+name: codespell
+
+on: [push, pull_request]
+
+concurrency:
+  group: ${{ github.ref }}-${{ github.head_ref }}-codespell
+  cancel-in-progress: true
+
+jobs:
+  codespell:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install codespell
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends python3-pip
+          pip3 install --user codespell
+
+      - name: Run codespell
+        run: codespell

BDS/hydro_bds.H

@@ -38,7 +38,7 @@ namespace BDS {
  * \param [in]     iconserv    If true, use conservative form, otherwise use convective.
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XYZ]VEL macro.
+ *                             defines the component position by [XYZ]VEL macro.
  */
 
 void ComputeEdgeState ( amrex::Box const& bx, int ncomp,
@@ -98,7 +98,7 @@ void ComputeSlopes ( amrex::Box const& bx,
  * \param [in]     pbc         Boundary conditions (device).
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XYZ]VEL macro.
+ *                             defines the component position by [XYZ]VEL macro.
  *
  *
  */

BDS/hydro_bds_edge_state_2D.cpp

@@ -32,7 +32,7 @@ constexpr amrex::Real eps = 1.0e-8;
  * \param [in]     iconserv    Indicates conservative dimensions.
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XY]VEL macro.
+ *                             defines the component position by [XY]VEL macro.
  *
  */
 
@@ -343,7 +343,7 @@ Real eval (const Real s,
  * \param [in]     pbc         Boundary conditions (device).
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XY]VEL macro.
+ *                             defines the component position by [XY]VEL macro.
  *
  */
 

BDS/hydro_bds_edge_state_3D.cpp

@@ -34,7 +34,7 @@ constexpr amrex::Real eps = 1.0e-8;
  * \param [in]     iconserv    Indicates conservative dimensions.
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XYZ]VEL macro.
+ *                             defines the component position by [XYZ]VEL macro.
  */
 
 void
@@ -521,7 +521,7 @@ Real eval (const Real s,
  * \param [in]     pbc         Boundary conditions (device).
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XYZ]VEL macro.
+ *                             defines the component position by [XYZ]VEL macro.
  *
  *
  */

CODE_OF_CONDUCT.md

@@ -5,7 +5,7 @@
 We as members, contributors, and leaders pledge to make participation in our
 community a harassment-free experience for everyone, regardless of age, body
 size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
+identity and expression, level of experience, education, socioeconomic status,
 nationality, personal appearance, race, caste, color, religion, or sexual
 identity and orientation.
 

Docs/source/Godunov.rst

@@ -9,7 +9,7 @@ AMReX-Hydro's implementation uses dimenensionally unsplit algorithms with full c
 with the option to use either piecewise linear (PLM) :cite:`colella:1990, saltzman`
 or piecewise parabolic (PPM) :cite:`ppm, millercolella:2002` reconstructions of the state.
 
-These alogrithms are applied in the Godunov namespace. For API documentation, see
+These algorithms are applied in the Godunov namespace. For API documentation, see
 `Doxygen: Godunov Namespace`_.
 
 .. _`Doxygen: Godunov Namespace`: https://amrex-fluids.github.io/amrex-hydro/Doxygen/html/namespaceGodunov.html
@@ -65,7 +65,7 @@ applying boundary conditions
 and then choosing between these states using the upwinding procedure
 defined below.  In particular, in the :math:`y` direction we define
 
-.. States on y-faces only have y BCs enforced, etc. This means y-faces in the x boundary don't have any additional BCs enforced (beyond the fact that the cell-centered U used to compute them had BCs enforced and slopes takes certain BCs into account). However, the hi/lo edge states have BCs enforced before the final upwind. No backflow prevention for trans terms, beacuse they're transverse.
+.. States on y-faces only have y BCs enforced, etc. This means y-faces in the x boundary don't have any additional BCs enforced (beyond the fact that the cell-centered U used to compute them had BCs enforced and slopes takes certain BCs into account). However, the hi/lo edge states have BCs enforced before the final upwind. No backflow prevention for trans terms, because they're transverse.
 
 .. math::
 
@@ -88,7 +88,7 @@ formation of the edge state.
 
 .. FIXME? It appears that for use_forces_in_trans, they're added both before upwinding to define the advective velocity AND before upwinding to define the transverse velocities. That doesn't quite seem right... Ooops, I was making a local var into a pointer. What the code does is create a local var (twice) and then add the forcing term only to the local var. So the effect is the results have the correct factor of the forcing terms in there (not 2x as I was worried about).
 
-Next, boundary conditions are enforced on domain faces as decribed in :ref:`bcs` #2.
+Next, boundary conditions are enforced on domain faces as described in :ref:`bcs` #2.
 Note that this means face-based values lying within the physical boundary but not exactly on the
 boundary face (e.g. values located on the y-faces of ghost cells abutting the x-boundary but not on the y-boundary)
 do not have boundary conditions enforced at this point.
@@ -135,7 +135,7 @@ with a factor of the z-derivative at cell centers
            - \frac{dt}{3} \left( \frac{\hat{u}_{i,j+1,k+\half} \hat{w}^{adv}_{i,j+1,k+\half} - \hat{u}_{i,j+1,k-\half} \hat{w}^{adv}_{i,j+1,k-\half}}{dz} \right) \\
                & + \frac{dt}{3} \left( \frac{\hat{w}^{adv}_{i,j+1,k+\half} - \hat{w}^{adv}_{i,j+1,k-\half}}{dz} \right) u_{i,j+1,k} \\
 
-and then apply boundary conditions on domian faces before upwinding according to
+and then apply boundary conditions on domain faces before upwinding according to
 :math:`\hat{v}_{i,j+\frac{1}{2},k}^{adv}` as was done above for :math:`\widehat{\U}`.
 :math:`\widebreve{\boldsymbol{U}}_{{i,j-\frac{1}{2},k}}, \widebreve{\boldsymbol{U}}_{i,j,k+\frac{1}{2}}`
 and :math:`\widebreve{\boldsymbol{U}}_{i,j,k-\frac{1}{2}}` are constructed in a similar manner.
@@ -157,7 +157,7 @@ We now have all the terms needed to form :math:`\tilde{u}`.
 If ``use_forces_in_trans`` is false, the forcing terms were not included in the computation of the
 transverse deriviates and are instead included at this point.
 We apply boundary conditions on domain faces,
-including preventing backflow (as decribed in :ref:`bcs` #2 & 3).
+including preventing backflow (as described in :ref:`bcs` #2 & 3).
 
 The normal velocity at each face is then determined by an upwinding procedure
 based on the states predicted from the cell centers on either side.  The

Docs/source/MOL.rst

@@ -7,7 +7,7 @@ The procedure for computing MAC velocities and edge states with MOL involves ext
 and does not involve any time derivatives. All slope computations use
 second-order limited slopes as described in :ref:`slopes`.
 
-These alogrithms are applied in the MOL namespace. For API documentation, see
+These algorithms are applied in the MOL namespace. For API documentation, see
 `Doxygen: MOL Namespace`_.
 
 .. _`Doxygen: MOL Namespace`: https://amrex-fluids.github.io/amrex-hydro/Doxygen/html/namespaceMOL.html
@@ -27,7 +27,7 @@ every x-face:
 
 where :math:`u^x` are the (limited) slopes in the x-direction.
 
-Boundary conditions are applied (as decribed in :ref:`bcs`).
+Boundary conditions are applied (as described in :ref:`bcs`).
 Then, at each face we upwind based on :math:`u_L` and :math:`u_R`
 
 .. math::
@@ -58,7 +58,7 @@ faces as above:
 
 where :math:`s^x` are the (limited) slopes in the x-direction.
 
-Boundary conditions are applied (as decribed in :ref:`bcs`).
+Boundary conditions are applied (as described in :ref:`bcs`).
 Then, at each face, we upwind based on :math:`u^{MAC}_{i-\frac{1}{2},j,k}`
 
 .. math::
@@ -97,7 +97,7 @@ where we calculate :math:`u^x`, :math:`u^y` and :math:`u^z` as described in :ref
 and :math:`\delta_x`, :math:`\delta_y`, and :math:`\delta_z` are the components of the distance vector from
 the cell centroid to the face centroid of the face at :math:`(i-\frac{1}{2},j,k).`
 
-Boundary conditions are applied (as decribed in :ref:`bcs`).
+Boundary conditions are applied (as described in :ref:`bcs`).
 Then, at each face we upwind based on :math:`u_L` and :math:`u_R`
 
 .. math::
@@ -129,7 +129,7 @@ where we calculate :math:`s^x`, :math:`s^y` and :math:`s^z` as described in :ref
 and :math:`\delta_x`, :math:`\delta_y`, and :math:`\delta_z` are the components of the distance vector from
 the cell centroid to the face centroid of the face at :math:`(i-\frac{1}{2},j,k).`
 
-Boundary conditions are applied (as decribed in :ref:`bcs`).
+Boundary conditions are applied (as described in :ref:`bcs`).
 Then, at each face we then upwind based on :math:`u^{MAC}_{i-\frac{1}{2},j,k}`
 
 .. math::

Docs/source/Projections.rst

@@ -40,7 +40,7 @@ time-explicitly, and the time step will be constrained by the time
 it takes for the maximum characteristic speed to traverse one grid cell.
 However, in low speed flow applications, it can be shown the acoustics
 transport very little energy in the system. As a result, the time-step
-restrictions arising from numerical treatement of the advection terms
+restrictions arising from numerical treatment of the advection terms
 can be unnecessarily limited, even if A-stable methods are used to incorporate
 the diffusion and source terms.
 
@@ -119,7 +119,7 @@ section of AMReX's documentation.
 .. _projections_inputs:
 
 Both Projector classes provide the following parameters, which can be set in an
-inputs file or on the command line. For the MacProjector, these must be preceeded by
+inputs file or on the command line. For the MacProjector, these must be preceded by
 "mac_proj.", or for the NodalProjector, "nodal_proj."
 
 +-------------------+-----------------------------------------------------------------------+-------------+--------------+
@@ -180,7 +180,7 @@ the MacProjector internally computes the divergence of the vector field, :math:`
 to compute the right-hand-side, and after the solve, subtracts the weighted gradient term to
 make the vector field result satisfy the divergence constraint.
 
-.. Note that passing ``nullptr`` for :math:`D(U^*)` is used for the MAC synchronization step in time-subcycling AMR (and more specifically, IAMR), where we want to solve for the correction velocity field which accounts for the mis-match in the advection velocity at the coarse-fine interface resulting from solving for the advection velocity on single levels rather than on the composite grid. In this case, currently, only the Poisson solve is done. Might make more sense to have MacProjector allocate and pass out -beta grad phi? or +beta grad phi?
+.. Note that passing ``nullptr`` for :math:`D(U^*)` is used for the MAC synchronization step in time-subcycling AMR (and more specifically, IAMR), where we want to solve for the correction velocity field which accounts for the mismatch in the advection velocity at the coarse-fine interface resulting from solving for the advection velocity on single levels rather than on the composite grid. In this case, currently, only the Poisson solve is done. Might make more sense to have MacProjector allocate and pass out -beta grad phi? or +beta grad phi?
 
 In the simplest form of the call, :math:`S` is assumed to be zero and does not need to be specified.
 Typically, the user does not allocate the solution array, but it is also possible to create and pass
@@ -319,7 +319,7 @@ operator like the MAC projection; instead we demonstrate below the steps needed
 to compute the approximate projection.  This means we must
 
 The ``NodalProjector`` class can be used to solve the nodal projection without explicitly
-calling the linear solver. In addtion to solving the nodal variable coefficient Poisson
+calling the linear solver. In addition to solving the nodal variable coefficient Poisson
 equation, it internally computes the right-hand-side,
 including the the divergence of the vector field, :math:`D(U^*)`,
 and also subtracts the weighted gradient term to make the vector field result satisfy the

EBGodunov/hydro_ebgodunov_extrap_vel_to_faces.cpp

@@ -129,7 +129,7 @@ EBGodunov::ExtrapVelToFaces ( MultiFab const& vel,
 
             }
             // Test includes 3 rows of ghost cells.
-            // Godunov::ExtrapVelToFacesOnBox is callled on bx => need u_ad on
+            // Godunov::ExtrapVelToFacesOnBox is called on bx => need u_ad on
             // xebx_g1 (not xebx_g2 as in EB). Then need PredictVelOnXFace on
             // xebx_g1, which will call slopes on cell (i-1), slopes uses cell (i-1)-2
             // => check regular on grow 3

MOL/hydro_mol.H

@@ -50,7 +50,7 @@ namespace MOL {
  * \param [in]     d_bcrec_ptr BCRec
  * \param [in]     is_velocity Indicates a component is velocity so boundary conditions can
  *                             be properly addressed. The header hydro_constants.H
- *                             defines the component positon by [XYZ]VEL macro.
+ *                             defines the component position by [XYZ]VEL macro.
  *
  * Compute upwinded FC states by extrapolating CC values in SPACE ONLY.
  * This is NOT a Godunov type extrapolation: there is NO dependence on time!

Redistribution/FOR_PAPER/hydro_redistribution.cpp

@@ -307,7 +307,7 @@ Redistribution::Make1DProfile ( Box const& bx, int ncomp,
                     bool extdir_khi = (d_bcrec_ptr[n].hi(2) == amrex::BCType::ext_dir ||
                                        d_bcrec_ptr[n].hi(2) == amrex::BCType::hoextrap);
 #endif
-                    // Initialize so that the slope stencil goes from -1:1 in each diretion
+                    // Initialize so that the slope stencil goes from -1:1 in each direction
                     int nx = 1; int ny = 1; int nz = 1;
 
                     // Do we have enough extent in each coordinate direction to use the 3x3x3 stencil

Redistribution/FOR_PAPER/hydro_redistribution.cpp.hack

@@ -366,7 +366,7 @@ Redistribution::Make1DProfile ( Box const& bx, int ncomp,
                     bool extdir_khi = (d_bcrec_ptr[n].hi(2) == amrex::BCType::ext_dir ||
                                        d_bcrec_ptr[n].hi(2) == amrex::BCType::hoextrap);
 #endif
-                    // Initialize so that the slope stencil goes from -1:1 in each diretion
+                    // Initialize so that the slope stencil goes from -1:1 in each direction
                     int nx = 1; int ny = 1; int nz = 1;
 
                     // Do we have enough extent in each coordinate direction to use the 3x3x3 stencil

Tests/MAC_Projection_EB/main.cpp

@@ -79,7 +79,7 @@ int main (int argc, char* argv[])
 
 #ifndef AMREX_USE_HYPRE
         if (use_hypre == 1)
-           amrex::Abort("Cant use hypre if we dont build with USE_HYPRE=TRUE");
+           amrex::Abort("Can't use hypre if we dont build with USE_HYPRE=TRUE");
 #endif
 
         if (n_cell%8 != 0)

Tests/Nodal_Projection_EB/main.cpp

@@ -59,7 +59,7 @@ int main (int argc, char* argv[])
 
 #ifndef AMREX_USE_HYPRE
         if (use_hypre == 1)
-           amrex::Abort("Cant use hypre if we dont build with USE_HYPRE=TRUE");
+           amrex::Abort("Can't use hypre if we dont build with USE_HYPRE=TRUE");
 #endif
 
         if (n_cell%8 != 0)

Utils/hydro_utils.H

@@ -21,7 +21,7 @@
 
 namespace HydroUtils {
 /**
- * \brief Compute edge state and flux. Most general version for use with multilevel synchonization.
+ * \brief Compute edge state and flux. Most general version for use with multilevel synchronization.
  *        All other versions ultimately call this one.
  */
 void