Add Codespell to pre-commit (#9097)

.github/CODEOWNERS

@@ -1,4 +1,4 @@
-# automatically requests pull request reviews for files matching the given pattern; the last match takes precendence
+# automatically requests pull request reviews for files matching the given pattern; the last match takes precedence
 
 # maintainers own everything
 * @spacetelescope/jwst-pipeline-maintainers 

.pre-commit-config.yaml

@@ -22,6 +22,13 @@ repos:
       - id: ruff
         args: ["--fix"]
       - id: ruff-format
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.4.0
+    hooks:
+    - id: codespell
+      args: ["--write-changes"]
+      additional_dependencies:
+        - tomli
   - repo: https://github.com/pre-commit/mirrors-mypy
     rev: v1.6.1  # Use the latest stable version
     hooks:

CONTRIBUTING.md

@@ -44,21 +44,21 @@ aren't making branches directly on 'spacetelescope/jwst'.
 
 2. Now that you have remotely forked `jwst`, it needs to be downloaded
 to your machine. To create this 'local' clone, choose an area on your file system
-and use the `git clone` command to dowload your remote fork on to your machine.
+and use the `git clone` command to download your remote fork on to your machine.
 
 		>> cd directory
 		>> git clone [email protected]:<your_username>/jwst.git
 
 3. Make sure that your references to 'origin' and 'upstream' are set correctly - you will
-need this to keep everything in sync and push your changes online. While your inital
+need this to keep everything in sync and push your changes online. While your initial
 local clone will be an exact copy of your remote, which is an exact copy of the 'upstream'
 `spacetelescope/jwst`, these all must be kept in sync manually (via git fetch/pull/push).
 
 	To check the current status of these references:
 
 		>> git remote -v
 
-After your inital clone, you will likely be missing the reference to 'upstream'
+After your initial clone, you will likely be missing the reference to 'upstream'
 (which is just the most commonly used name in git to refer to the main project repository - you
 can call this whatever you want but the origin/upstream conventions are most commonly used) - to 
 set this, use the `add` git command:
@@ -388,7 +388,7 @@ Our pre-commit Git hook, also described in the
 [Installing JWST for Development](Step-3-Installing-jwst-for-development) section,
 is designed to help contributors run all the checks on their contributions every time they commit.
 
-The following three style checks are performed:
+The following style checks are performed:
 
 * **PEP8-compliant code**
 
@@ -416,10 +416,19 @@ The following three style checks are performed:
 	The docstring style for the `jwst` repository generally conforms to the
 	[Numpy style guide](https://numpydoc.readthedocs.io/en/latest/format.html), and the docstring
 	style rules are enforced using [numpydoc-validation](https://numpydoc.readthedocs.io/en/latest/validation.html).
-	To run these checks locally, use the command
+
+	To run these checks standalone, use the command
 
         >> pre-commit run numpydoc-validation
 
+* **Spell checking**
+
+	We use [Codespell](https://github.com/codespell-project/codespell) to check for common
+	misspellings in both our codebase and documentation.
+	To run the spell checker standalone, use the command
+
+        >> pre-commit run codespell
+
 
 * **PEP-compliant type hints**
 

changes/9097.general.rst

@@ -0,0 +1 @@
+Add codespell spell checker

docs/conf.py

@@ -462,7 +462,7 @@ def check_sphinx_version(expected_version):
 # The format is a list of tuples containing the path and title.
 # epub_pre_files = []
 
-# HTML files shat should be inserted after the pages created by sphinx.
+# HTML files that should be inserted after the pages created by sphinx.
 # The format is a list of tuples containing the path and title.
 # epub_post_files = []
 

docs/jwst/associations/association.rst

@@ -12,7 +12,7 @@ and are created by association rules. However, as will be described,
 the association rules are Python classes which inherit from the
 ``Association`` class.
 
-Associations created from these rule classes, refered to as just
+Associations created from these rule classes, referred to as just
 ``rules``, have the type of the class they are created from and have all
 the methods and attributes of those classes. Such instances are used
 to populate the created associations with new members and check the

docs/jwst/data_products/msa_metadata.rst

@@ -303,7 +303,7 @@ pre-image ID, and source stellarity.
 +------+------+-----------+-------+------------+-------------+--------------+------------+
 
 For each slitlet identified as having a source assigned to it in the shutter metadata,
-the source name, alias, RA, Dec, and stellarity are retreived from the `SOURCE_INFO`
+the source name, alias, RA, Dec, and stellarity are retrieved from the `SOURCE_INFO`
 table and stored with the ``Slit`` object created in the calibration software.
 The stellarity values are used in the :ref:`source type <srctype_step>`
 step to determine whether the source should be treated as point-like or extended.

docs/jwst/data_products/stages.rst

@@ -51,7 +51,7 @@ Throughout this document, we will use the "Stage" terminology to refer to data p
 Stage 0, 1, and 2 products are always files containing the data from a single exposure and a
 single detector. A NIRCam exposure that uses all 10 detectors will therefore result in 10 separate
 FITS files for each of the Stage 0, 1, and 2 products. Because these stages contain the data for a single
-exposure, they are refered to as "exposure-based" products and use an "exposure-based" file naming
+exposure, they are referred to as "exposure-based" products and use an "exposure-based" file naming
 syntax. Stage 3 products, on the other hand, are constructed from the combined data of
 multiple exposures for a given source or target. They are referred to as "source-based" products
 and use a "source-based" file naming syntax. Observing modes that include multiple defined sources

docs/jwst/exp_to_source/main.rst

@@ -5,7 +5,7 @@ Description
 Stage 2 exposure-based data products to Stage 3 source-based data products.
 It is only used when there is a known source list for the exposure data,
 which is required in order to reorganize the data by source. Hence it is
-only useable for NIRSpec MOS, NIRSpec fixed-slit, NIRCam WFSS, and NIRISS
+only usable for NIRSpec MOS, NIRSpec fixed-slit, NIRCam WFSS, and NIRISS
 WFSS data. Details on the operation for each mode are given below.
 
 The tool is run near the beginning of the :ref:`calwebb_spec3 <calwebb_spec3>`

docs/jwst/extract_1d/arguments.rst

@@ -122,7 +122,7 @@ Step Arguments for IFU Data
 
 ``--ifu_rscale``
    A float designating the number of PSF FWHMs to use for the extraction radius. This
-   is a MIRI MRS only paramenter. Values accepted are between 0.5 to 3.0. The default extraction
+   is a MIRI MRS only parameter. Values accepted are between 0.5 to 3.0. The default extraction
    size is set to 2 * FWHM. Values below 2 will result in a smaller
    radius, a value of 2 results in no change to radius and a value above 2 results in a larger
    extraction radius.

docs/jwst/extract_2d/main.rst

@@ -133,7 +133,7 @@ WFSS Examples
 The extraction of sources from WFSS grism images is a multi-step process, as outlined above.
 Here we show detailed examples of how to customize the list of WFSS grism objects to be
 extracted, in order to better explain the various steps.
-First, the input file (or data model) must aleady have a WCS object assigned to it by running
+First, the input file (or data model) must already have a WCS object assigned to it by running
 the :ref:`assign_wcs <assign_wcs_step>` step. The default values
 for the wavelength range of each spectral order to be extracted are also required;
 they are stored in the ``wavelengthrange`` reference file, which can be retrieved from CRDS.

docs/jwst/jump/arguments.rst

@@ -115,7 +115,7 @@ is defined as:
 
 **Parameter that affects both Snowball and Shower flagging**
 
-* ``--max_extended_radius``: The maxiumum extension of the jump and saturation that will be flagged for showers or snowballs
+* ``--max_extended_radius``: The maximum extension of the jump and saturation that will be flagged for showers or snowballs
 
 **Parameters that affect Sigma Clipping**
 

docs/jwst/outlier_detection/outlier_detection_tso.rst

@@ -9,7 +9,7 @@ series observations.
 Normal imaging data benefit from combining all integrations into a
 single image. TSO data's value, however, comes from looking for variations from one
 integration to the next.  The outlier detection algorithm, therefore, gets run with 
-a few variations to accomodate the nature of these 3D data.
+a few variations to accommodate the nature of these 3D data.
 A :py:class:`~jwst.datamodels.CubeModel` object serves as the basic format for all
 processing performed by this step. This routine performs the following operations:
 

docs/jwst/ramp_fitting/description.rst

@@ -32,7 +32,7 @@ to flag occurrences of both saturation and cosmic-ray (CR) hits.
 A ramp segment is a set of contiguous groups that have no non-zero DQ values
 assigned. The one exception to this rule is the occurrence of a "JUMP_DET"
 (jump detected) flag: a group with this flag will be used as the first group of
-the next segment. Any occurences of a "DO_NOT_USE" flag will be excluded from a
+the next segment. Any occurrences of a "DO_NOT_USE" flag will be excluded from a
 segment. When a "SATURATION" flag is found, the segment is terminated at the
 preceding group and all subsequent groups are rejected.
 Any segment containing only one good group is ignored if there is any other
@@ -96,7 +96,7 @@ the frame zero array are set to zero by the preceding :ref:`saturation <saturati
 step in the pipeline. Unsaturated elements will have non-zero values in the
 frame zero array. If frame zero is *not* saturated, then it's value will be
 divided by the frame time for the exposure in order to compute a slope for the pixel
-in that integration. This is analagous to the situation in which only the first group
+in that integration. This is analogous to the situation in which only the first group
 in an integration is unsaturated and used by itself to compute a slope.
 
 Note that the computation of slopes from either a single group or the single frame

docs/jwst/references_general/ifuslicer_reffile.rst

@@ -39,7 +39,7 @@ The “data” field is an array with 30 rows pertaining to the 30 slices and th
           y_center
             Y coordinate of the center (in meters)
           x_size
-            X size of teh aperture (in meters)
+            X size of the aperture (in meters)
           y_size
             Y size of the aperture (in meters)
 :model: Transform from relative positions within the IFU slicer to absolute positions

docs/jwst/references_general/msa_reffile.rst

@@ -40,7 +40,7 @@ The MSA reference file has 5 fields, named
           y_center
             Y coordinate of the center (in meters)
           x_size
-            X size of teh aperture (in meters)
+            X size of the aperture (in meters)
           y_size
             Y size of the aperture (in meters)
    :model: Transform from relative positions within Quadrant 1 to absolute positions within the MSA

docs/jwst/resample/main.rst

@@ -95,7 +95,7 @@ of the FITS file. Each pixel in the context image is a bit field that encodes
 information about which input image has contributed to the corresponding
 pixel in the resampled data array. Context image uses 32 bit integers to encode
 this information and hence it can keep track of only 32 input images.
-First bit corresponds to the first input image, second bit corrsponds to the
+First bit corresponds to the first input image, second bit corresponds to the
 second input image, and so on. If the number of input images is larger than 32,
 then it is necessary to have multiple context images ("planes") to hold
 information about all input images

docs/jwst/tweakreg/README.rst

@@ -339,7 +339,7 @@ The ``tweakreg`` step has the following optional arguments:
   .. note::
       Mathematically, alignment of images observed in different tangent planes
       requires ``fitgeometry='general'`` in order to fit source catalogs
-      in the different images even if mis-alignment is caused only by a shift
+      in the different images even if misalignment is caused only by a shift
       or rotation in the tangent plane of one of the images.
 
       However, under certain circumstances, such as small alignment errors or

docs/jwst/user_documentation/datamodels.rst

@@ -37,5 +37,5 @@ created internally when the pipeline/step is run.
 
 By default, when running in Python, the corrected data will be returned in-memory
 as a ``DataModel`` instead of being written as an output file.
-See :ref:`controlling output file behavior`<python_outputs>` for instrucions on
+See :ref:`controlling output file behavior`<python_outputs>` for instructions on
 how to write the returned ``DataModel`` to an output file.

docs/jwst/user_documentation/introduction.rst

@@ -15,7 +15,7 @@ hosted open-source on Github, and can be run either via
 the :ref:`Python interface <run_from_python>`.
 
 The full end-to-end 'pipeline' (from raw data to high-level data products)
-is comprised of three seperate pipeline stages that are run individually
+is comprised of three separate pipeline stages that are run individually
 to produce output products at different calibration levels:
 
 	:Stage 1: Detector-level corrections and ramp fitting for individual

docs/jwst/user_documentation/parameters.rst

@@ -12,7 +12,7 @@ a hierarchy involved - overrides set on a pipeline or step object will take prec
 over values in a parameter file. See :ref:`Parameter Precedence` for a full description of
 how a parameter gets its final value.
 
-If there is need to re-use a set of parameters often, parameters can be stored
+If there is need to reuse a set of parameters often, parameters can be stored
 in **parameter files**. See :ref:`parameter_files` for more information.
 
 To see what parameters are available for any given
@@ -133,5 +133,5 @@ file from CRDS when running a pipeline:
     $ strun calwebb_detector1 jw00017001001_01101_00001_nrca1_uncal.fits
           --steps.dark_current.override_dark='my_dark.fits'
 
-If there is need to re-use a set of parameters often, parameters can be stored
+If there is need to reuse a set of parameters often, parameters can be stored
 in **parameter files**. See :ref:`parameter_files` for more information.

docs/jwst/user_documentation/reference_files_crds.rst

@@ -6,7 +6,7 @@ Reference Files, Parameter Files and CRDS
 
 The JWST pipeline uses version-controlled :ref:`reference files <crds_reference_files>` and
 :ref:`parameter files <crds_parameter_files>` to supply pipeline steps with necessary data
-and set pipeline/step parameters, respectivley. These files both use the ASDF format,
+and set pipeline/step parameters, respectively. These files both use the ASDF format,
 and are managed by the Calibration References Data System (:ref:`CRDS <crds>`) system.
 
 .. _crds_reference_files:
@@ -39,7 +39,7 @@ Parameter Files
 
 Parameter files, which like reference files are encoded in ASDF and
 version-controlled by CRDS, define the 'best' set of parameters for pipeline
-steps as determined by the JWST instrument teams, based on insturment, observing
+steps as determined by the JWST instrument teams, based on instrument, observing
 model, filter, etc. They also may evolve over time as understanding of caibration
 improves.
 

docs/jwst/user_documentation/running_pipeline_python.rst

@@ -175,7 +175,7 @@ but they can be overridden if desired.
 
 As discussed in :ref:`above<configuring_pipeline_python>`, when setting a
 step-level parameter when that step is a substep of a pipeline, it must be passed
-to the `steps` argument dictionary. For exaple, to change the ``rejection_threshold``
+to the `steps` argument dictionary. For example, to change the ``rejection_threshold``
 parameter of the jump detection step when running the full Detector1Pipeline:
 
 ::
@@ -495,7 +495,7 @@ Advanced use - `pipeline.run()` vs. `pipeline.call`
 ===================================================
 
 Another option for running pipelines or steps is to use the `.run()` method
-instead of the `.call()` method. **Using .run() is not reccomended** and
+instead of the `.call()` method. **Using .run() is not recommended** and
 considered advanced use, but it is an option to users.
 
 The difference between ``.run()`` in ``.call()`` is in the retrieval and use
@@ -547,7 +547,7 @@ Since the pipeline uses multiprocessing it is critical that any code using the p
 to the guidelines described in the
 `python multiprocessing documentation <https://docs.python.org/3/library/multiprocessing.html#multiprocessing-programming>`_.
 The pipeline uses the `forkserver` start method internally and it is recommended that any
-multiprocessing scripts that use the pipline use the same start. As detailed in the
+multiprocessing scripts that use the pipeline use the same start. As detailed in the
 `python documentation <https://docs.python.org/3/library/multiprocessing.html#the-spawn-and-forkserver-start-methods>`_
 this will require that code be "protected" with a ``if __name__ == '__main__':`` check as follows
 

jwst/ami/lg_model.py

@@ -105,7 +105,7 @@ def __init__(
             )  # retain ability to possibly  use other named masks, for now
         self.ctrs = mask.ctrs
         self.d = mask.hdia
-        self.D = mask.activeD
+        self.D = mask.active_D
 
         self.N = len(self.ctrs)
         self.fmt = "%10.4e"
@@ -292,7 +292,7 @@ def fit_image(
         self,
         image,
         reference=None,
-        modelin=None,
+        model_in=None,
         savepsfs=False,
         dqm=None,
         weighted=False,
@@ -317,7 +317,7 @@ def fit_image(
         reference : 2D float array
             Input reference image
 
-        modelin : 2D array
+        model_in : 2D array
             Optional model image
 
         savepsfs : bool
@@ -329,11 +329,11 @@ def fit_image(
         weighted : bool
             Use weighted operations in the least squares routine
         """
-        self.model_in = modelin
+        self.model_in = model_in
         self.weighted = weighted
         self.saveval = savepsfs
 
-        if modelin is None:  # No model provided
+        if model_in is None:  # No model provided
             # Perform a set of automatic routines
             # A Cleaned up version of your image to enable Fourier fitting for
             # centering crosscorrelation with FindCentering() and
@@ -360,7 +360,7 @@ def fit_image(
                 pixscale=self.pixel,
             )
         else:
-            self.fittingmodel = modelin
+            self.fittingmodel = model_in
         if self.weighted is False:
             self.soln, self.residual, self.cond, self.linfit_result = leastsqnrm.matrix_operations(
                 image, self.fittingmodel, dqm=dqm

jwst/ami/mask_definition_ami.py

@@ -29,7 +29,7 @@ def __init__(self, nrm_model, maskname="jwst_ami", chooseholes=None):
 
         self.maskname = maskname  # there's only one mask but this is used in oifits
         self.hdia = nrm_model.flat_to_flat
-        self.activeD = nrm_model.diameter
+        self.active_D = nrm_model.diameter
         self.OD = nrm_model.pupil_circumscribed
         self.ctrs = []
 

jwst/ami/matrix_dft.py

@@ -7,7 +7,7 @@
 specified centering type. These have to do with where the (0, 0) element of
 the Fourier transform is located, i.e. where the PSF center ends up.
 - 'FFTSTYLE' centered on one pixel
-- 'SYMMETRIC' centerd on crosshairs between middle pixel
+- 'SYMMETRIC' centered on crosshairs between middle pixel
 - 'ADJUSTABLE', always centered in output array depending on
 whether it is even or odd
 'ADJUSTABLE' is the default.

jwst/ami/nrm_core.py

@@ -236,7 +236,7 @@ def fit_fringes_single_integration(self, slc):
 
         nrm.fit_image(
             self.ctrd,
-            modelin=nrm.model,
+            model_in=nrm.model,
             dqm=self.dqslice,
             weighted=self.weighted,
         )

jwst/ami/utils.py

@@ -52,7 +52,7 @@ class Affine2d:
     coordinates. We know the analytical form of F(u,v) from the literature,
     and need to calculate G(u,v) at a grid of points in the (u,v) space, with
     two lattice vectors a and b defining the grid.  These lattice vectors have
-    components a=(au,av) and b=(bu,bv) along the u and v axes.
+    components a=(a_u,a_v) and b=(b_u,b_v) along the u and v axes.
 
     Discussion with Randall Telfer (2018.05.18)  clarified that:
 
@@ -621,7 +621,7 @@ def findslope(a):
     1 rad/FDpixel of phase slope => ODarray.shape[0]/(2 pi) shift
     x rad/FDpixel of phase slope => x * ODarray.shape[0]/(2 pi) ODpixels shift
 
-    Gain between rad/pix phase slope and original domin pixels is
+    Gain between rad/pix phase slope and original domain pixels is
          a.shape[0 or 1]/(2 pi)
     Multiply the measured phase slope by this gain for pixels of incoming array
          centroid shift away from array center.