Fix typos in comments and docs (#4471)

* Fix typos and spelling

* More typos

* Typos 2023 Nov 27

* 2023 Nov 30 Update

* Docs typos

* Fix "arbitrary"

* 2023 Dec 01 typos

* Particles

* ablastr - FieldSolver

* Filter

* Fluids

* Docs + Tools

* Change back to "lamda"

* Fix typo

Co-authored-by: Roelof Groenewald <40245517+roelof-groenewald@users.noreply.github.com>

* Fix cylindrical

---------

Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
Co-authored-by: Roelof Groenewald <40245517+roelof-groenewald@users.noreply.github.com>

Author: 3 people

CONTRIBUTING.rst

@@ -117,7 +117,7 @@ A typical format is:
 
    This is a short, 40-character title
 
-   After a newline, you can write arbitray paragraphs. You
+   After a newline, you can write arbitrary paragraphs. You
    usually limit the lines to 70 characters, but if you don't, then
    nothing bad will happen.
 

Docs/source/developers/checksum.rst

@@ -9,7 +9,7 @@ The checksum module is located in ``Regression/Checksum/``, and the benchmarks a
 
 For more details on the implementation, the Python files in ``Regression/Checksum/`` should be well documented.
 
-From a user point of view, you should only need to use ``checksumAPI.py``. It contains Python functions that can be imported and used from an analysis Python script. It can also be executed directly as a Python script. Here are recipies for the main tasks related to checksum regression tests in WarpX CI.
+From a user point of view, you should only need to use ``checksumAPI.py``. It contains Python functions that can be imported and used from an analysis Python script. It can also be executed directly as a Python script. Here are recipes for the main tasks related to checksum regression tests in WarpX CI.
 
 Include a checksum regression test in an analysis Python script
 ---------------------------------------------------------------

Docs/source/developers/profiling.rst

@@ -247,7 +247,7 @@ node, or without a workload management system.
 .. note::
 
     To collect full statistics, Nsight-Compute reruns kernels,
-    temporarilly saving device memory in host memory. This makes it
+    temporarily saving device memory in host memory. This makes it
     slower than Nsight-Systems, so the provided script profiles only a single
     step of a single process. This is generally enough to extract relevant
     information.

Docs/source/developers/python.rst

@@ -56,10 +56,10 @@ This is part of the standard - each of the PICMI classes call the method ``handl
 The main purpose is to process application specific keyword arguments (those that start with ``warpx_`` for example).
 These are then passed into the ``init`` methods.
 In the WarpX implementation, in the ``init``, each of the WarpX specific arguments are saved as attributes of the implementation
-class instancles.
+class instances.
 
 It is in the second method, ``initialize_inputs``, where the PICMI input parameters are translated into WarpX input parameters.
-This method is called later during the intialization.
+This method is called later during the initialization.
 The prefix instances described above are all accessible in the implementation classes (via the ``pywarpx`` module).
 For each PICMI input quantity, the appropriate WarpX input parameters are set in the prefix classes.
 As needed, for example in the ``Species`` class, the dynamic prefix instances are created and the attributes set.

Docs/source/developers/repo_organization.rst

@@ -41,7 +41,7 @@ All WarpX header files need to be specified relative to the ``Source/`` director
 By default, in a ``MyName.cpp`` source file we do not include headers already included in ``MyName.H``. Besides this exception, if a function or a class
 is used in a source file, the header file containing its declaration must be included, unless the inclusion of a facade header is more appropriate. This is
 sometimes the case for AMReX headers. For instance ``AMReX_GpuLaunch.H`` is a façade header for ``AMReX_GpuLaunchFunctsC.H`` and ``AMReX_GpuLaunchFunctsG.H``, which
-contain respectively the CPU and the GPU implemetation of some methods, and which should not be included directly.
+contain respectively the CPU and the GPU implementation of some methods, and which should not be included directly.
 Whenever possible, forward declarations headers are included instead of the actual headers, in order to save compilation time (see dedicated section below). In WarpX forward
 declaration headers have the suffix ``*_fwd.H``, while in AMReX they have the suffix ``*Fwd.H``.
 The include order (see `PR #874 <https://github.com/ECP-WarpX/WarpX/pull/874#issuecomment-607038803>`__ and `PR #1947 <https://github.com/ECP-WarpX/WarpX/pull/1947>`__) and `proper quotation marks <https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html>`__ are:

Docs/source/developers/testing.rst

@@ -25,7 +25,7 @@ For example, if you like to change the compiler to compilation to build on Nvidi
    branch = development
    cmakeSetupOpts = -DAMReX_ASSERTIONS=ON -DAMReX_TESTING=ON -DWarpX_COMPUTE=CUDA
 
-We also support changing compilation options via the usual :ref:`build enviroment variables <building-cmake-envvars>`.
+We also support changing compilation options via the usual :ref:`build environment variables <building-cmake-envvars>`.
 For instance, compiling with ``clang++ -Werror`` would be:
 
 .. code-block:: sh

Docs/source/developers/warning_logger.rst

@@ -47,15 +47,15 @@ Each entry of warning list respects the following format:
 .. code-block:: sh
 
    * --> [PRIORITY] [TOPIC] [raised COUNTER]
-   *     MULTILINE MESSAGGE
-   *     MULTILINE MESSAGGE
+   *     MULTILINE MESSAGE
+   *     MULTILINE MESSAGE
    *     @ Raised by: WHICH_RANKS
 
 where:
 
 * ``[PRIORITY]`` can be ``[!  ]`` (low priority), ``[!! ]`` (medium priority) or ``[!!!]`` (high priority). It indicates the importance of the warning.
 * ``[TOPIC]`` indicates which part of the code is concerned by the warning (e.g., particles, laser, parallelization...)
-* ``MULTILINE MESSAGGE`` is an arbitrary text message. It can span multiple-lines. Text is wrapped automatically.
+* ``MULTILINE MESSAGE`` is an arbitrary text message. It can span multiple-lines. Text is wrapped automatically.
 * ``COUNTER`` indicates the number of times the warning was raised **across all the MPI ranks**. This means that if we run WarpX with 2048 MPI ranks and each rank raises the same warning once, the displayed message will be ``[raised 2048 times]``. Possible values are ``once``, ``twice``, ``XX times``
 * ``WHICH_RANKS`` can be either ``ALL`` or a sequence of rank IDs. It is the list of the MPI ranks which have raised the warning message.
 

Docs/source/glossary.rst

@@ -17,7 +17,7 @@ Abbreviations
 * **AMR:** adaptive mesh-refinement
 * **BC:** boundary condition (of a simulation)
 * **BCK:** `Benkler-Chavannes-Kuster <https://ieeexplore.ieee.org/document/1638381>`__ method, a stabilization technique for small cells in the electromagnetic solver
-* **BTD:** backtransformed diagnosics, a method to collect data for analysis from a *boosted frame* simulation
+* **BTD:** backtransformed diagnostics, a method to collect data for analysis from a *boosted frame* simulation
 * **CEX:** charge-exchange collisions
 * **CFL:** the Courant-Friedrichs-Lewy condition, a numerical parameter for the numerical convergence of PDE solvers
 * **CI:** continuous integration, automated tests that we perform before a proposed code-change is accepted; see PR

Docs/source/install/hpc/fugaku.rst

@@ -24,7 +24,7 @@ Use the following commands to download the WarpX source code and switch to the c
    git clone https://github.com/ECP-WarpX/WarpX.git $HOME/src/warpx
 
 
-Compiling WarpX on Fugaku is more pratical on a compute node. Use the following commands to acquire a compute node for one hour:
+Compiling WarpX on Fugaku is more practical on a compute node. Use the following commands to acquire a compute node for one hour:
 
 .. code-block:: bash
 

Docs/source/install/hpc/karolina.rst

@@ -17,7 +17,7 @@ If you are new to this system, **please see the following resources**:
 * `Filesystems <https://docs.it4i.cz/karolina/storage/>`__:
 
   * ``$HOME``: per-user directory, use only for inputs, source and scripts; backed up (25GB default quota)
-  * ``/scatch/``: `production directory <https://docs.it4i.cz/karolina/storage/#scratch-file-system>`__; very fast for parallel jobs (20TB default)
+  * ``/scratch/``: `production directory <https://docs.it4i.cz/karolina/storage/#scratch-file-system>`__; very fast for parallel jobs (20TB default)
 
 
 .. _building-karolina-preparation:
@@ -143,7 +143,7 @@ Use the following :ref:`cmake commands <building-cmake>` to compile the applicat
 
 Now, you can :ref:`submit Karolina compute jobs <running-cpp-karolina>` for WarpX :ref:`Python (PICMI) scripts <usage-picmi>` (:ref:`example scripts <usage-examples>`).
 Or, you can use the WarpX executables to submit Karolina jobs (:ref:`example inputs <usage-examples>`).
-For executables, you can reference their location in your :ref:`job script <running-cpp-karolina>` or copy them to a location in ``/scatch/``.
+For executables, you can reference their location in your :ref:`job script <running-cpp-karolina>` or copy them to a location in ``/scratch/``.
 
 
 .. _building-karolina-update:

Docs/source/latex_theory/AMR/AMR.tex

@@ -53,7 +53,7 @@ \subsection{Electrostatic}
 %  \caption{Snapshot from a 3D self-consistent simulation of the injector in the High Current Experiment shows the beam emerging from the source at low energy (blue) and being accelerated (green-yellow-orange) and transported in a four quadrupole front end. The automatic layout of the mesh refinement patches from a 2D axisymmetric simulation of the source area shows 2 levels of refinement, concentrating the finer meshes around the emitter (white curve surface) and the beam edge (dark blue).}
 %  \label{fig:ESHCX}
 %\end{figure}
-%Automatic remeshing has been implemented in WarpX following the procedure described in \cite{Vaynim2005}, refining on criteria based on measures of local charge density magnitude and gradients. AMR WarpX simulations were applied to the modeling of the front end injector of the High Current Experiment (HCX) \cite{Prostprstab2005}, and provided the first numerically converged estimates of phase space beam distorsions, which directly affects beam quality \cite{Vaypop04}. Fig.~\ref{fig:ESHCX} shows snapshots from 2D axisymmetric simulation of the souce area illustrating the automatic placement of refined patches, and 3D simulation of the full injector showing the beam generation, acceleration and transport.
+%Automatic remeshing has been implemented in WarpX following the procedure described in \cite{Vaynim2005}, refining on criteria based on measures of local charge density magnitude and gradients. AMR WarpX simulations were applied to the modeling of the front end injector of the High Current Experiment (HCX) \cite{Prostprstab2005}, and provided the first numerically converged estimates of phase space beam distorsions, which directly affects beam quality \cite{Vaypop04}. Fig.~\ref{fig:ESHCX} shows snapshots from 2D axisymmetric simulation of the source area illustrating the automatic placement of refined patches, and 3D simulation of the full injector showing the beam generation, acceleration and transport.
 
 \subsection{Electromagnetic}
 The method that is used for electrostatic mesh refinement is not directly applicable to electromagnetic calculations. As was shown in section 3.4 of \cite{Vayjcp01}, refinement schemes relying solely on interpolation between coarse and fine patches lead to the reflection with amplification of the short wavelength modes that fall below the cutoff of the Nyquist frequency of the coarse grid. Unless these modes are damped heavily or prevented from occurring at their source, they may affect particle motion and their effect can escalate if trapped within a patch, via multiple successive reflections with amplification.

Docs/source/theory/cold_fluid_model.rst

@@ -95,7 +95,7 @@ Step 5: **Current and Charge Deposition**
 
    Mesh refinement is not supported for the fluids.
 
-   The implemented MUSCL scheme has a simplifed slope averaging, see the extended writeup for details.
+   The implemented MUSCL scheme has a simplified slope averaging, see the extended writeup for details.
 
    More details on the precise implementation are available here, `WarpX_Cold_Rel_Fluids.pdf`_.
 .. _WarpX_Cold_Rel_Fluids.pdf: https://github.com/ECP-WarpX/WarpX/files/12886437/WarpX_Cold_Rel_Fluids.pdf

Docs/source/theory/kinetic_fluid_hybrid_model.rst

@@ -134,7 +134,7 @@ Extrapolation step
 
 Obtaining the E-field at timestep :math:`t=t_{n+1}` is a well documented issue for
 the hybrid model. Currently the approach in WarpX is to simply extrapolate
-:math:`\vec{J}_i` foward in time, using
+:math:`\vec{J}_i` forward in time, using
 
     .. math::
 

Docs/source/usage/how_to_run.rst

@@ -25,7 +25,7 @@ Where ``<run_directory>`` by the actual path to the run directory.
 -------------
 
 If you installed warpX with a :ref:`package manager <install-users>`, a ``warpx``-prefixed executable will be available as a regular system command to you.
-Depending on the choosen build options, the name is suffixed with more details.
+Depending on the chosen build options, the name is suffixed with more details.
 Try it like this:
 
 .. code-block:: bash

Docs/source/usage/parameters.rst

@@ -155,7 +155,7 @@ Overall simulation parameters
     This only applies when warpx.do_electrostatic = labframe.
 
 * ``warpx.self_fields_verbosity`` (`integer`, default: 2)
-    The vebosity used for MLMG solver for space-charge fields calculation. Currently
+    The verbosity used for MLMG solver for space-charge fields calculation. Currently
     MLMG solver looks for verbosity levels from 0-5. A higher number results in more
     verbose output.
 
@@ -369,7 +369,7 @@ Domain Boundary Conditions
 
     * ``Absorbing``: Particles leaving the boundary will be deleted.
 
-    * ``Periodic``: Particles leaving the boundary will re-enter from the opposite boundary. The field boundary condition must be consistenly set to periodic and both lower and upper boundaries must be periodic.
+    * ``Periodic``: Particles leaving the boundary will re-enter from the opposite boundary. The field boundary condition must be consistently set to periodic and both lower and upper boundaries must be periodic.
 
     * ``Reflecting``: Particles leaving the boundary are reflected from the boundary back into the domain.
       When ``boundary.reflect_all_velocities`` is false, the sign of only the normal velocity is changed, otherwise the sign of all velocities are changed.
@@ -861,7 +861,7 @@ Particle initialization
       ``<species_name>.ux``, ``<species_name>.uy`` and ``<species_name>.uz``, the normalized
       momenta in the x, y and z direction respectively, which are all ``0.`` by default.
 
-    * ``uniform``: uniform probability distribution between a minumum and a maximum value.
+    * ``uniform``: uniform probability distribution between a minimum and a maximum value.
       The x, y and z directions are sampled independently and the final momentum space is a cuboid.
       The parameters that control the minimum and maximum domain of the distribution
       are ``<species_name>.u<x,y,z>_min`` and ``<species_name>.u<x,y,z>_max`` in each
@@ -1190,7 +1190,7 @@ Cold Relativistic Fluid initialization
 * ``fluids.species_names`` (`strings`, separated by spaces)
     Defines the names of each fluid species. It is a required input to create and evolve fluid species using the cold relativistic fluid equations.
     Most of the parameters described in the section "Particle initialization" can also be used to initialize fluid properties (e.g. initial density distribution).
-    For fluid-specific inputs we use `<fluid_pecies_name>` as a placeholder. Also see external fields
+    For fluid-specific inputs we use `<fluid_species_name>` as a placeholder. Also see external fields
     for how to specify these for fluids as the function names differ.
 
 .. _running-cpp-parameters-laser:
@@ -1726,7 +1726,7 @@ WarpX provides several particle collision models, using varying degrees of appro
     total number of physical particle remains the same). This can improve
     the statistics of the simulation, in the case where fusion reactions are very rare.
     More specifically, in a fusion reaction between two macroparticles with weight ``w_1`` and ``w_2``,
-    the weight of the product macroparticles will be ``min(w_1,w_2)/fusion_multipler``.
+    the weight of the product macroparticles will be ``min(w_1,w_2)/fusion_multiplier``.
     (And the weights of the reactant macroparticles are reduced correspondingly after the reaction.)
     See `Higginson et al. (JCP 388, 439-453, 2019) <https://doi.org/10.1016/j.jcp.2019.03.020>`__
     for more details. The default value of ``fusion_multiplier`` is 1.
@@ -2299,7 +2299,7 @@ Additional parameters
 
 * ``warpx.shared_tilesize`` (list of `int`) optional (default `6 6 8` in 3D; `14 14` in 2D; `1s` otherwise)
      Used to tune performance when ``do_shared_mem_current_deposition`` or
-     ``do_shared_mem_charge_depostion`` is enabled. ``shared_tilesize`` is the
+     ``do_shared_mem_charge_deposition`` is enabled. ``shared_tilesize`` is the
      size of the temporary buffer allocated in shared memory for a threadblock.
      A larger tilesize requires more shared memory, but gives more work to each
      threadblock, which can lead to higher occupancy, and allows for more

Examples/Physics_applications/laser_acceleration/analysis_1d_fluids.py

@@ -90,7 +90,7 @@ def odefcn(phi, xi, kp, a0, c, tau, xi_0, lambda_laser):
 # Remove the ions
 rho_th = rho_th - e*n0
 
-# Dicate which region to compare solutions over
+# Dictate which region to compare solutions over
 # (Currently this is the full domain)
 min_i = 0
 max_i = 10240

Examples/Physics_applications/laser_acceleration/analysis_1d_fluids_boosted.py

@@ -90,7 +90,7 @@ def odefcn(phi, xi, kp, a0, c, tau, xi_0, lambda_laser):
 # Remove the ions
 rho_th = rho_th - e*n0
 
-# Dicate which region to compare solutions over (cuttoff 0's from BTD extra)
+# Dictate which region to compare solutions over (cuttoff 0's from BTD extra)
 min_i = 200
 max_i = 4864
 

Examples/Physics_applications/laser_acceleration/analysis_refined_injection.py

@@ -43,7 +43,7 @@
 n_move = 192
 
 # ref ratio = 2 1
-# Refined only transversly. Longitudinal spacing between particles in each stream is the same in both coarse and fine regions
+# Refined only transversely. Longitudinal spacing between particles in each stream is the same in both coarse and fine regions
 rr_longitudinal = 1
 
 np_expected = (n_coarse + n_fine*rr_longitudinal)*(n_0 + n_move)

Examples/Tests/field_probe/analysis_field_probe.py

@@ -9,9 +9,9 @@
 """
 This script tests the accuracy of the FieldProbe diagnostic by observing a plane
 wave undergoing single slit diffraction. The input file inputs_2d is used. This
-file defines the simulation box, laser pulse, embeded boundary with single slit,
+file defines the simulation box, laser pulse, embedded boundary with single slit,
 and line of detector points. The plane wave initializes near the negative Z end
-of the simulation box. The wave interacts with the embeded boundary at Z=0. The
+of the simulation box. The wave interacts with the embedded boundary at Z=0. The
 wave undergoes diffraction at the slit. The electromagnetic flux is calculated
 at the line detector which is placed perpendicular to Z beyond the slit. This
 test will check if the detected EM flux matches expected values,
@@ -39,7 +39,7 @@ def I_envelope (x, lam = 0.2e-6, a = 0.3e-6, D = 1.7e-6):
     arg = np.pi * a / lam * np.sin(np.arctan(x / D))
     return np.sinc( arg / np.pi )**2
 
-# Count non-outlyer values away from simulation boundaries
+# Count non-outlier values away from simulation boundaries
 counter = np.arange(60, 140, 2)
 
 # Count average error from expected values

Examples/Tests/flux_injection/analysis_flux_injection_3d.py

@@ -17,7 +17,7 @@
 
 After the particles are emitted with flux injection, this script produces
 histograms of the velocity distribution and compares it with the expected
-velocity distibution (Gaussian or Gaussian-flux depending on the direction
+velocity distribution (Gaussian or Gaussian-flux depending on the direction
 of space)
 """
 import os

Examples/Tests/ion_stopping/analysis_ion_stopping.py

@@ -73,7 +73,7 @@ def stopping_from_ions(dt, ni, Ti, mi, Zi, Zb, ion_mass, ion_energy):
     ion_energy = (f1)**(2./3.)/e
     return ion_energy
 
-# Fetch background parameters and inital particle data
+# Fetch background parameters and initial particle data
 ds0 = yt.load(f'{prefix}{len(last_it)*"0"}')
 ad0 = ds0.all_data()
 

Examples/Tests/nuclear_fusion/analysis_proton_boron_fusion.py

@@ -521,7 +521,7 @@ def check_initial_energy2(data):
 
     # Loop over all slices (i.e. cells in the z direction)
     for slice_number in range(1, size_z):
-        ## For simplicity, all the calculations in this functino are done nonrelativistically
+        ## For simplicity, all the calculations in this function are done nonrelativistically
         ## Proton kinetic energy in the lab frame before fusion
         E_proton_nonrelativistic = Energy_step*slice_number**2
         ## Corresponding square norm of proton momentum

Examples/Tests/ohm_solver_ion_Landau_damping/PICMI_inputs.py

@@ -2,7 +2,7 @@
 #
 # --- Test script for the kinetic-fluid hybrid model in WarpX wherein ions are
 # --- treated as kinetic particles and electrons as an isothermal, inertialess
-# --- background fluid. The script simulates ion Landau damping as descibed
+# --- background fluid. The script simulates ion Landau damping as described
 # --- in section 4.5 of Munoz et al. (2018).
 
 import argparse