Corrected a number of spelling mistakes.

Author: klust

docs/2022-CSC_and_LO/1_Intro/1_02_Lmod.md

@@ -23,7 +23,7 @@ Unloading the environment module will restore the shell environment to its previ
 Environment module files are processed via a **modules tool**, of which there
 are several conceptually similar yet slightly different implementations.
 The oldest module tool still in use today is Environment Modules 3.2, implemented in C and 
-supporting module files written in Tcl. After a gap in developement, Xavier Delaruelle of CEA
+supporting module files written in Tcl. After a gap in development, Xavier Delaruelle of CEA
 developed [Environment Modules 4 and 5](https://sourceforge.net/projects/modules/) which is
 fully implemented on Tcl. An alternative module tool is [Lmod](https://lmod.readthedocs.io), 
 developed by Robert McLay at TACC and implemented in LUA. This tool supports natively LUA
@@ -39,7 +39,7 @@ Lmod also has some powerful features that are lacking in Environment Modules 3.2
     On LUMI, Lmod was selected as the module tool. One area where there are significant
     differences between Environment Modules 3.2 (and also the newer versions) and Lmod is
     in the commands for discovering modules on the system. If you are not familiar with Lmod 
-    and its commands for users, it is worthwile to read the 
+    and its commands for users, it is worthwhile to read the 
     [LUMI documentation page on Lmod](https://docs.lumi-supercomputer.eu/computing/Lmod_modules/).
     Some of those commands are also discussed on this page.
 
@@ -244,7 +244,7 @@ family('MPI')
 prepend_path('MODULEPATH', 'moduleroot/MPI/Compiler_A/version_A/MPI_C/version_C')
 ```
 
-Finally two vesions of the ``version_E.lua`` file are needed, one to prepare the environment for using the 
+Finally two versions of the ``version_E.lua`` file are needed, one to prepare the environment for using the 
 package with Compiler_A anmd MPI_C and one for using the package with Compiler_B and MPI_C. However, these
 are just regular modules and no additions are needed to work for the hierarchy.
 
@@ -375,7 +375,7 @@ e.g., NumPy and SciPy for Python. Installing all those packages as separate modu
 to make it easy to see if they are installed or not on a system would lead to an
 overload of modules on the system. 
 
-Similary, admins of a software stack may chose to bundle several libraries or tools
+Similarly, admins of a software stack may chose to bundle several libraries or tools
 that are often used together in a single module (and single installation directory),
 e.g., to reduce module clutter but also to reduce the length of the search paths for
 binaries, libraries or manual pages to speed up loading of applications.
@@ -550,7 +550,7 @@ indicated version.
 Lmod works by executing the module file. However, the actions of all Lmod-defined 
 functions will depend upon the mode in which Lmod is executing the module function,
 and the module file can also detect in which mode it is executing.
-Modes include "load", "unload"but also "spider".  E.g., when te mode is "load", the
+Modes include "load", "unload" but also "spider".  E.g., when the mode is "load", the
 ``setenv`` function will set an environment variable to the indicated value while in 
 "unload" mode that environment variable will be unset, and in "spider" mode the 
 environment variable is left untouched. The working of ``prepend_path``, a function 
@@ -564,7 +564,7 @@ in that PATH-style variable). When the mode is "spider", the function has specia
 if it is used to change the ``MODULEPATH``. It will then note the change and add that
 directory to the list of directories that has to be searched for module files.
 This makes ``module spider`` a very expensive command as it may have to traverse a lot
-of directories and has to execute all module files in there. Therefor Lmod will build
+of directories and has to execute all module files in there. Therefore Lmod will build
 a so-called spider cache which can be pre-built in the system for  certain directories
 and otherwise will be build in the user's home directory (in the ``.lmod.d/.cache``
 subdirectory). Our experience is that this cache tends to be rather fragile,
@@ -661,7 +661,7 @@ module load MyPythonPackage/1.0
 Because of the *"one name rule"* this will again trigger an unload followed by a load
 of the module. The problem is in the unload. One would expect that first unloading
 ``MyPythonPackage`` would remove the 2.7 directory from the ``PYTHON_PATH`` but it 
-will not. Lmod does not remeber that last time it loaded ``MyPythonPackage`` it added
+will not. Lmod does not remember that last time it loaded ``MyPythonPackage`` it added
 the 2.7 directory to ``PythonPath``. Instead it will execute the commands in the 
 modulefile and reverse certain commands. Since ``PYTHON_API_VERSION`` has now the value
 ``3.6``, it will try to remove the directory for version ``3.6`` which is not in the

docs/2022-CSC_and_LO/1_Intro/1_03_CPE.md

@@ -6,9 +6,9 @@
 
 On LUMI, the main programming environment is the HPE Cray Programming Environment (further abbreviated
 as Cray PE). The environment provides several tools, including compilers, communication libraries, 
-optmized math libraries and various other libraries, analyzers and debuggers.
+optimised math libraries and various other libraries, analyzers and debuggers.
 
-The Cray PE is made available through *environment modules* tha allow to select particular versions of 
+The Cray PE is made available through *environment modules* that allow to select particular versions of 
 tools and to configure the environment in a flexible way.
 
 ---
@@ -145,7 +145,7 @@ These libraries satisfy dependencies for many commonly used applications on Cray
 When the module for a CSML package (such as `cray-libsci` or `cray-fftw`) is loaded, 
 all relevant headers and libraries for these packages are added to the compile 
 and link lines of the `cc`, `ftn`, and `CC` compiler wrappers, so linking with them is
-completely transparant (to the extent that users wonder where the libraries are).
+completely transparent (to the extent that users wonder where the libraries are).
 
 The CSML collection contains the following Scientific Libraries:
 
@@ -326,7 +326,7 @@ can be set through target modules:
     ``craype-network-ucx`` module.
 
 -   The ``craype-hugepages*`` modules enable Cray Huge Pages support. To fully enable this support they have to
-    be used at link-time and at run-time. At link time, support is compiled into the binary wile at run-time they
+    be used at link-time and at run-time. At link time, support is compiled into the binary while at run-time they
     are used to set the actual size of the huge pages. 
 
     The ``craype-hugepages*`` modules are not supported by all compilers. E.g., the AOCC compiler does not support
@@ -375,7 +375,7 @@ is loaded first.
 
 ## Some unexpected behaviour of the Cray PE
 
-On Cray EX systems, dynamic linking is the preferred way of linking applications. Whith that comes some
+On Cray EX systems, dynamic linking is the preferred way of linking applications. With that comes some
 unexpected behaviour of the Cray modules. EasyBuild users expect that at run time the versions of the 
 libraries that are used, are the ones from the modules that are loaded. This is not always the case
 for the runtime libraries of the Cray PE. By default the Cray PE will use a default set of libraries

docs/2022-CSC_and_LO/1_Intro/1_04_LUMI_software_stack.md

@@ -5,7 +5,7 @@
 ---
 
 The user-facing documentation on how to use the LUMI software stacks is
-avialable in [the LUMI documentation](https://docs.lumi-supercomputer.eu/computing/softwarestacks/).
+available in [the LUMI documentation](https://docs.lumi-supercomputer.eu/computing/softwarestacks/).
 On this page we focus more on the technical implementation behind it.
 
 ---

docs/2022-CSC_and_LO/1_Intro/1_07_configuration.md

@@ -14,7 +14,7 @@ and to configure EasyBuild according to your preferences and the system on which
 
 !!! Note "EasyBuild configuration on LUMI"
 
-    On LUMI serveral configurations of EasyBuild are already available.
+    On LUMI several configurations of EasyBuild are already available.
 
     The ``EasyBuild-user`` module is the most important one. It will configure EasyBuild
     to install software in either a default location in the user's home directory 
@@ -104,7 +104,7 @@ and the default `software` and `modules/all` names for the subdirectories are us
 
     This makes it slightly easier to organise the module tree with user-friendly labeling, but above
     all also makes the synchronisation process of the 4 instances of the software directory more robust
-    as it is now easy to synchonise all modules in the last step, which is a much quicker process than
+    as it is now easy to synchronise all modules in the last step, which is a much quicker process than
     syncrhonising the software installations.
 
     We also use short paths for software installations (to avoid overrunning the maximum length of a

docs/2022-CSC_and_LO/1_Intro/1_08_basic_usage.md

@@ -524,7 +524,7 @@ Dry run: printing build status of easyconfigs and dependencies
 == Temporary directory /run/user/10012026/easybuild/tmp/eb-wm_bk3j6 has been removed.
 ``` 
 
-and now instal the library:
+and now install the library:
 
 ```shell
 $ eb libdap-3.20.9-cpeGNU-21.12.eb
@@ -782,7 +782,7 @@ sourcepath            (E) = /users/XXXXXXXX/LUMI-user/sources:/appl/lumi/sources
 ...
 ```
 
-This is sligthly different from the default EasyBuild setup, where the modules, software,
+This is slightly different from the default EasyBuild setup, where the modules, software,
 repository and sources would be installed in respectively the subdirectories `modules`,
 `software`, `ebfiles_repo` and `sources` of the directory pointed to by the `installpath` 
 line. 
@@ -932,7 +932,7 @@ Currently Loaded Modules:
    S:  Module is Sticky, requires --force to unload or purge
 ```
 
-Runnin `module --force purge` instead will remove all modules, including the `init-lumi` 
+Running `module --force purge` instead will remove all modules, including the `init-lumi` 
 module which does part of the initialisation. You will not be able to use the software
 stacks completely as before without first loading `init-lumi` in its most recent (or default)
 version again!

docs/2022-CSC_and_LO/2_Using/2_02_creating_easyconfig_files.md

@@ -318,7 +318,7 @@ specific parameter is less useful on LUMI as we currently try to build on top of
 
 The `buildtools` build dependency shows that there is a fourth parameter specifying the toolchain 
 used for that dependency and is needed if that toolchain is different from the one used in the example.
-As it is not possible to load several Cray toolchains together (they are not in a hierachical relation)
+As it is not possible to load several Cray toolchains together (they are not in a hierarchical relation)
 the only useful value on LUMI is `True` which tells that `buildtools` is build with the `SYSTEM` 
 toolchain. Here also we use a template, `%(toolchain_version)s` which - as its name suggests - expands
 to the version of the toolchain, as we version our `buildtools` modules after the version of the Cray
@@ -569,7 +569,7 @@ homepage = 'https://easybuilders.github.io/easybuild-tutorial'
 whatis = [ 'Description: EasyBuild tutorial example']
 
 description = """
-This is a short C++ example program that can be buid using CMake.
+This is a short C++ example program that can be build using CMake.
 """
 ```
 
@@ -582,7 +582,7 @@ ERROR: Failed to process easyconfig /pfs/lustrep4/users/XXXXXXXX/easybuild-tutor
 No software-specific easyblock 'EB_eb_minus_tutorial' found for eb-tutorial
 ```
 
-It is not mandatory to specify an easyblock in the easyconfig. However, in the absense of that
+It is not mandatory to specify an easyblock in the easyconfig. However, in the absence of that
 specification, EasyBuild goes looking for an application-specific easyblock with the standard name,
 in this case `EB_eb_minus_tutorial`, which it does not have. Does that mean we have to implement an easyblock?
 

docs/2022-CSC_and_LO/2_Using/2_04_implementing_easyblocks.md

@@ -107,7 +107,7 @@ module location for a particular software name or easyblock class name. For exam
 ```
 
 The location of the Python module is determined by whether the easyblock is generic or software-specific.
-Generic easyblocks are located in the ``easybuid.easyblocks.generic`` namespace, while software-specific easyblocks
+Generic easyblocks are located in the ``easybuild.easyblocks.generic`` namespace, while software-specific easyblocks
 live in the ``easybuild.easyblocks`` namespace directly.
 
 To keep things organised, the actual Python module files
@@ -661,7 +661,7 @@ Your easyblock should:
     whatis = [ 'Description: EasyBuild tutorial example']
 
     description = """
-    This is a short C++ example program that can be buid using CMake.
+    This is a short C++ example program that can be build using CMake.
     """
 
     toolchain = {'name': 'cpeCray', 'version': '21.12'}

docs/2022-CSC_and_LO/3_Advanced/3_03_slurm_jobs.md

@@ -21,7 +21,7 @@ It is important to be aware of some details before you start using this, which w
     temporary files and build directory. Those have to be made by hand. 
 
     Due to the setup of the central software stack, this feature is currently useless to install
-    the central stack. For user installations, there are also limitations as the enviornment
+    the central stack. For user installations, there are also limitations as the environment
     on the compute nodes is different from the login nodes so, e.g., different locations for
     temporary files are being used. These would only be refreshed if the EasyBuild configuration
     modules are reloaded on the compute nodes which cannot be done currently in the way Slurm
@@ -178,7 +178,7 @@ To remedy this, there are a couple of EasyBuild configuration options you can us
 The build directory of course also suffers from the problem of being no longer accessible if the
 installation fails, but there it is not so easy to find a solution. Building on a shared file system
 is not only much slower, but in particular on parallel file systems like GPFS/SpectrumScale, Lustre
-or BeeGFS buiding sometimes fails in strange ways. One thing you can consider if you cannot do the
+or BeeGFS building sometimes fails in strange ways. One thing you can consider if you cannot do the
 build on a login node (e.g., because the code is not suitable for cross-compiling or the configure
 system does tests that would fail on the login node), is to rety the installation in an
 interactive job,  so you can inspect the build directory after the installation fails.

docs/2022-CSC_and_LO/3_Advanced/3_04_module_naming_schemes.md

@@ -49,7 +49,7 @@ module naming schemes, which are characterized by:
 
 In contrast, a *hierarchical* module naming scheme
 consists of a *hierarchy* of module files. 
-A fairly typical 3-level schme (``Core``, ``Compiler`` and ``MPI``) has been
+A fairly typical 3-level scheme (``Core``, ``Compiler`` and ``MPI``) has been
 discussed in the [section on Lmod](../1_Intro/1_02_Lmod#lmod-hierarchy).
 This typical Lmod hierarcny would map very well on the EasyBuild common toolchains.
 
@@ -67,7 +67,7 @@ would be installed using the regular ``foss`` toolchain or the ``gompi`` toolcha
 On LUMI, where software is installed through the Cray Programming Environment with no real choice of
 MPI implementation, a two-level arrangement would still make a lot of sense, with at the ``Core`` level
 all software compiled with the SYSTEM toolchain while there could be a ``PrgEnv`` level for software
-compiled with a particula programming enviornment aka cepGNU/cpeCray/cpeAOCC toolchain. Such a scheme
+compiled with a particula programming environment aka cepGNU/cpeCray/cpeAOCC toolchain. Such a scheme
 is used on the Cray systems at CSCS.
 
 To recap, the characteristics of a module hierarchy are:
@@ -164,7 +164,7 @@ loaded on LUMI this was not possible to accomplish without losing other function
 
 Next to the module naming schemes that are included with EasyBuild,
 you can also define your own module naming scheme (MNS), and configure EasyBuild to use it
-(which is eactly what has been done on LUMI to remove a feature of the default ``EasyBuildMNS`` scheme
+(which is exactly what has been done on LUMI to remove a feature of the default ``EasyBuildMNS`` scheme
 that we do not use).
 
 ### Implementation
@@ -288,7 +288,7 @@ $ eb SciPy-bundle-2020.11-foss-2020b-Python-2.7.18.eb -D
 
 !!! Warning "Example not suitable for LUMI"
     **This exercise is meant for a system where the common toolchains can be used and requires an
-    indpendent EasyBuild installation in your personal file space**,
+    independent EasyBuild installation in your personal file space**,
     because EasyBuild will try to copy the installation log file to each installation directory.
 
 Now that we know more about hierarchical module naming schemes,

docs/2022-CSC_and_LO/4_00_additional_reading.md

@@ -11,7 +11,7 @@
     EasyBuild.
 -   [EasyBuild YouTube channel](https://www.youtube.com/c/EasyBuilders)
 -   This tutorial is an evolution of the 
-    [EasyBuild tutorial prepared for the LUMI User Suppport Team, spring '21](https://easybuilders.github.io/easybuild-tutorial/2021-lust/)
+    [EasyBuild tutorial prepared for the LUMI User Support Team, spring '21](https://easybuilders.github.io/easybuild-tutorial/2021-lust/)
     given by Kenneth Hoste (UGent, EasyBuild lead developer) and Luca Marsella (CSCS)
     -   [Recordings are available on YouTube](https://www.youtube.com/watch?v=JTRw8hqi6x0&list=PLhnGtSmEGEQh573bk3BeOj_KCRBBiA5OT)
 -   The EasyBuild setup on LUMI is partly insprired on the setup used at CSCS on their Cray systems