Adopt pre commit hook for the codespell tool

.codespellignore.txt

@@ -0,0 +1 @@
+matric

.pre-commit-config.yaml

@@ -28,3 +28,10 @@ repos:
       exclude: docs/source/conf.py|docs/source/genindex.md|docs/source/modindex.md
       additional_dependencies:
         - black==24.4.2 # Matches hook
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.4.1
+    hooks:
+    - id: codespell
+      args: ["--toml", "pyproject.toml"]
+      additional_dependencies:
+        - tomli

docs/source/development/contributing/code_qa_and_typing.md

@@ -49,7 +49,7 @@ short description of the roles of each hook.
 ::::
 
 `pre-commit-hooks`
-: We use these basic hooks to check for remaning `git` merge conflict markers in code
+: We use these basic hooks to check for remaining `git` merge conflict markers in code
 files (`check-merge-conflicts` hook) and for debugger imports and `breakpoint()` calls
 (`dubug-statements` hook), which should not end up in code in the repository.
 
@@ -68,6 +68,10 @@ and we use both the linting (`ruff`) and formatting (`ruff-format`) hooks.
 : This tool is used to pass all python code within notebooks through code formatting. At
 present, this still uses the `black` code formatter and not `ruff-format` as above.
 
+`codespell`
+: This tool checks files for common mis-spellings of words. If `codespell` complains
+about a word that you think is correct, you can add it to `.codespellignore.txt`.
+
 ### Output and configuration
 
 When `pre-commit` runs, you may see some lines about package installation and update,
@@ -82,6 +86,7 @@ ruff-format..........................................................Passed
 mypy.................................................................Passed
 markdownlint.........................................................Passed
 jupytext.............................................................Passed
+codespell............................................................Passed
 ```
 
 ### Updating `pre-commit`
@@ -119,7 +124,7 @@ developed to help support clear and consistent typing. We use
 bit of getting used to but is a key tool in maintaining clear code and variable
 structures.
 
-## Supressing checking
+## Suppressing checking
 
 The `pre-commit` tools sometimes complain about things that we do not want to change.
 Almost all of the tools can be told to suppress checking, using comments with a set
@@ -129,7 +134,7 @@ This should not be done lightly: we are using these QA tools for a reason.
 
 * Code linting issued identified by `ruff` can be ignored by either using `# noqa: E501`
   to ignore the issue for that line.
-* Code formatting changes suggested by `ruff-format` can be supressed by using the
+* Code formatting changes suggested by `ruff-format` can be suppressed by using the
   `# fmt: off` tag at the end of a specific line or wrapping a section in `# fmt: off`
   and then `# fmt: on`.
 * `mypy` uses the syntax `# type: ignore` comment to [suppress

docs/source/development/contributing/overview.md

@@ -529,7 +529,7 @@ in this document. There are two options to do this:
    using the `poetry` environment. This approach is used in the example commands below.
 1. You can use `poetry shell` to start a new shell that uses this environment: you can
    then run commands without needing `poetry run` and they should use the correct
-   enviroment. This is usually more convenient.
+   environment. This is usually more convenient.
 
 You should now be able to run the following command to see that `virtual_ecosystem` is
 installed and is showing the current version.
@@ -626,7 +626,7 @@ could be an Exception) is generated.
 Again, the `pytest` package and plugins are installed by `poetry`. See the [code testing
 page](./code_testing.md) for more details but you should be able to check the tests run
 using the following command. Be warned that the `mypy` steps can be very time consuming
-on the first run, but `pytest` does some cacheing that makes them quicker when they next
+on the first run, but `pytest` does some caching that makes them quicker when they next
 run.
 
 ```sh
@@ -674,7 +674,7 @@ page](./release_process.md) for details.
 ## Setup script example
 
 The scripts below bundle all the commands together to show the set up process, including
-using `pyenv` to mangage `python` versions, ending by running the unit tests. This sets
+using `pyenv` to manage `python` versions, ending by running the unit tests. This sets
 up everything you need, ready to start developing on the `virtual_ecosystem`.
 
 :::{admonition} Setup script

docs/source/development/contributing/release_process.md

@@ -61,7 +61,7 @@ The steps of the process are:
    Log in to [https://readthedocs.org](https://readthedocs.org) which is the admin site
    controlling the build process. From the Versions tab, activate the `release/X.Y.Z`
    branch and wait for it to build. Check the Builds tab to see that it has built
-   successfully! If it has built succesfully, do check pages to make sure that page code
+   successfully! If it has built successfully, do check pages to make sure that page code
    has executed successfully, and then go back to the Versions tab and deactivate and
    hide the branch. If the release branch needs any changes, do come back and check that
    those changes have also built successfully.

docs/source/development/design/core.md

@@ -59,7 +59,7 @@ The config system should provide a way to:
 - or possibly something like a dataclass for dotted notation:
   (config.plant.functional_types.max_height)
 - validate the config against some kind of template
-- It is likely that different configurations may re-use config subsections in different
+- It is likely that different configurations may reuse config subsections in different
   combinations, so the config system should be capable of loading configs from
   **multiple** files, so that a complete config can be built up or updated from multiple
   files, rather than having to compile a single monolithic file for each permutation.

docs/source/development/design/defining_new_models.md

@@ -29,7 +29,7 @@ an ecosystem, examples include the `abiotic`, `animal`, `plants` and `soil` mode
 However, the simulation is designed to be modular:
 
 * Different combinations of models can be configured for a particular simulation.
-* New models can be defined in order to extend the simulation or alter the implemention:
+* New models can be defined in order to extend the simulation or alter the implementation:
   examples of new functionality might be `freshwater` or `disturbance` models.
 
 This page sets out the steps needed to add a new model to the Virtual Ecosystem and
@@ -153,7 +153,7 @@ from pint import Quantity
 # - a Config , used to configure a BaseModel instance.
 # - the load_constants helper function to configure model constants.
 # - the Data class, used as a central data store within the simulation
-# - an custom exception to cover model initalisation failure
+# - an custom exception to cover model initialisation failure
 # - the global LOGGER, used to report information to users.
 from virtual_ecosystem.core.base_model import BaseModel
 from virtual_ecosystem.core.config import Config

docs/source/development/documentation/docstring_style.py

@@ -39,7 +39,7 @@ class MyClass:
 
     Attributes are documented with docstrings underneath the attribute definition. Class
     attributes are grouped with instance attributes in the rendered documentation, so
-    should say explictly that they are a class attribute."""
+    should say explicitly that they are a class attribute."""
 
     def __init__(self, myarg: int, name: str) -> None:
         # Note there is no __init__ docstring.

docs/source/development/documentation/jupyter_notebooks.md

@@ -40,7 +40,7 @@ The `poetry` virtual environment for `virtual_ecosystem` is already setup to
 include `jupyter` and `jupyter-lab`, which is a browser-based application for editing
 and running notebooks. As that virtual environment also has the `virtual_ecosystem`
 package installed in development mode, a `jupyter` notebook running using this
-enviroment will be able to import and use `virtual_ecosystem` code from the active
+environment will be able to import and use `virtual_ecosystem` code from the active
 branch.
 
 You can open `jupyter-lab` in a couple of ways. The simplest way is to use `poetry run
@@ -99,7 +99,7 @@ basic problem is that - although JSON files are text-based and are **technically
 human-readable:
 
 - they contain irrelevant metadata - such as the number of times the notebook has been
-  run - that will generate unneccessary commits.
+  run - that will generate unnecessary commits.
 - they can contain output binary data - such as images - that may also have arbitrary
   changes.
 

docs/source/glossary.md

@@ -18,9 +18,9 @@ jupyter:
 POM
   Particulate Organic Matter. A form of organic matter that derives from the
   decomposition and fragmentation of litter and other necromass. Generally, these
-  particulates are still in a state where the tissue they orginated from can be
+  particulates are still in a state where the tissue they originated from can be
   determined. This chemical complexity makes this a form of protected carbon, however this
-  is generally only a signifcant store of protected carbon in heavily waterlogged soils.
+  is generally only a significant store of protected carbon in heavily waterlogged soils.
 
 MAOM
   Mineral Associated Organic Matter. This is organic matter which has formed a strong

docs/source/using_the_ve/configuration/config.md

@@ -68,7 +68,7 @@ size `cell_nx`).
 
 The configuration system does not require a single input config file, instead the
 configuration can be separated out into a set of config files. This allows different
-configuration files to be re-used in a modular way, allowing a library of configuration
+configuration files to be reused in a modular way, allowing a library of configuration
 options to be set up.
 
 When a simulation is run, users can identify a set of specific configuration files or

docs/source/using_the_ve/configuration/grid.md

@@ -48,7 +48,7 @@ square_grid
 ## Hexagon grids
 
 A hexagon grid is defined in a very similar way - alternate rows of hexagons are offset
-to correctly tesselate the individual cells.
+to correctly tessellate the individual cells.
 
 ```{code-cell} ipython3
 hex_grid = Grid(grid_type="hexagon", cell_area=100, cell_nx=9, cell_ny=11)

docs/source/using_the_ve/getting_started.md

@@ -31,7 +31,7 @@ For most users the best way to get started with the Virtual Ecosystem package is
 first [install Python](https://www.python.org/downloads/). To use the Virtual Ecosystem
 you will need Python 3.10, 3.11, or 3.12.
 
-Afer installing Python, open a terminal window and use the following command to install
+After installing Python, open a terminal window and use the following command to install
 the Virtual Ecosystem using the `pip` package installer.
 
 ```sh
@@ -103,7 +103,7 @@ ve_run C:\path\ve_example\config `
 
 The [Virtual Ecosystem in use](virtual_ecosystem_in_use.md) page provides a walkthrough
 of this process, showing the typical outputs of the model run process, and also provides
-some simple plots of model inputs and ouputs.
+some simple plots of model inputs and outputs.
 
 Once you want to start digging into the structure of the model and inputs, the [example
 data](./example_data.md) pages provides a detailed description of the  contents of the

docs/source/virtual_ecosystem/implementation/core_components_overview.md

@@ -43,7 +43,7 @@ When a simulation starts, the Virtual Ecosystem:
 * Loads the user-provided configuration files and checks the file formats are valid.
 * Collates the configuration settings into a single unified configuration.
 * Loads the model schemas for the core and requested science models and uses this to
-  validate the congfiguration.
+  validate the configuration.
 * The validation process populates any missing options from the default values.
 * The configuration validation will fail if:
   * Any options are duplicated within the configuration.

docs/source/virtual_ecosystem/implementation/hydrology_implementation.md

@@ -200,7 +200,7 @@ $LAI$ is the total leaf area index.
 
 ### Infiltration
 
-Infiltration is currently handeled in a very simplistic way: the water that 'fits in the
+Infiltration is currently handled in a very simplistic way: the water that 'fits in the
 topsoil bucket' is added to the topsoil layer. We aim to implement a more realistic
 process that accounts for soil type specific infiltration capacities.
 
@@ -377,7 +377,7 @@ data["elevation"] = elevation
 ```
 
 The initialisation step of the hydrology model finds all the neighbours for each grid
-cell and determine which neigbour has the lowest elevation. The code below returns the
+cell and determine which neighbour has the lowest elevation. The code below returns the
 neighbours of the grid cell with `cell_id = 56` as an example.
 
 ```{code-cell} ipython3

docs/source/virtual_ecosystem/theory/microclimate_theory.md

@@ -59,8 +59,8 @@ temporally {cite}`bramer_chapter_2018`.
 
 ## Factors affecting microclimate
 
-Microclimates are mediated by macroclimate, topography, vegetation tye and structure, and
-soil. Many of these factors can be affected by human cativities, for example through
+Microclimates are mediated by macroclimate, topography, vegetation type and structure,
+and soil. Many of these factors can be affected by human cativities, for example through
 deforestation and other land use changes.
 
 ### Macroclimate
@@ -288,7 +288,7 @@ migration, or phenotypic plasticity to cope with microclimatic variability.
 ## Methods for microclimate science
 
 This section gives a broad overview over common methods and models in microclimate
-research. Recent advances in data aquisition for microclimate research and microclimate
+research. Recent advances in data acquisition for microclimate research and microclimate
 modelling are provided in a comprehensive review by {cite:t}`kemppinen_microclimate_2024`.
 
 ### Microclimate data collection
@@ -340,7 +340,7 @@ complex and unpredictable nature. However, these events can have disproportionat
 on ecosystem dynamics and in particular mortality rates.
 * **Integration with other models**: Combining microclimate models with broader
 ecological or hydrological models involves addressing compatibility and consistency issues.
-This includes for example interconnected processes happing at different time scales.
+This includes for example interconnected processes happening at different time scales.
 * **Human impacts**: Incorporating the effects of human activities (e.g. urbanization,
 land use changes, conservation actions) into microclimate models adds another layer of
 complexity.