Some explanation in the overview of part 3

Author: klust

docs/2022-CSC_and_LO/1_02_Lmod.md

@@ -73,12 +73,54 @@ to a hierarchy with 3 levels:
 3.  The ``MPI`` level, containing libraries and applications that depend on the compiler used and the MPI
     implementation.
 
+??? Example "A simple Lmod hierarchy with a single compiler"
+
+    Here is a simple example of such a 3-level module hierarchy
+    (that almost could have been generated by EasyBuild):
+
+    <div align="center"><img src="../../img/hmns.png" width="60%"/></div>
+
+    In this example the ``Core`` level only includes a single module `GCC/9.3.0`,
+    while  the ``Compiler`` level includes two modules: `OpenMPI/4.0.3` and `MPICH/3.3.2`.
+    In the ``MPI `` level, three modules are available: one for `FFTW`, one for `ScaLAPACK`, 
+    and one for `HDF5`.
+
+    Initially only the modules on the top level of a module hierarchy are available for loading.
+    If you run "`module avail`", the command that is used to view all modules that are available
+    for loading, with this example module hierarchy, you will only see the `GCC/9.3.0` module.
+
+    Some modules in the top level of the hierarchy act as a "gateway" to modules in the
+    next level below.
+    To make additional modules available for loading one of these gateway modules has to be loaded. 
+    In our example, loading the `GCC/9.3.0` module results in two additional modules coming into
+    view from the ``Compiler`` level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. 
+    These correspond to installations of `OpenMPI`
+    and `MPICH` that were built using `GCC/9.3.0`.
+
+    Similarly, the `OpenMPI/4.0.3` module serves as a gateway to the three modules in the ``MPI`` level. 
+    Only by loading the `OpenMPI` module will these additional three modules become
+    available for loading. They correspond to software installations built using the ``GCC/9.3.0``
+    compiler with ``OpenMPI/4.0.3``. 
+
 Now assume that we have two compilers in the hierarchy, Compiler_A and Compiler_B. Their modules would reside
-at the ``Core`` level. Both copilers provide the same MPI implementation, MPI_C. So there would be two modules
+at the ``Core`` level. Both compilers provide the same MPI implementation, MPI_C. So there would be two modules
 for ``MPI_C`` in two different subdirectories at the ``Compiler`` level. And further assume that we have an
 application, Appl_E, compiled with both Compiler_A and Compiler_B and using MPI_C. For that application there would
 also be two module files at the ``MPI`` level,  one in a subdirectory corresponding ao Compiler_A and MPI_C and one
-in a subdirectory corresponding to Compiler_B and MPI_C. To be able to load the module for Appl_E, a user should
+in a subdirectory corresponding to Compiler_B and MPI_C. 
+
+```mermaid
+graph TD;
+A[Compiler_A] --> AC[MPI_C];
+A --> AD[MPI_D]
+B[Compiler_B] --> BC[MPI_C];
+AC --> ACE[Appl_E];
+AD --> ADE[Appl_E]
+BC --> BCE[Appl_E];
+```
+
+
+To be able to load the module for Appl_E, a user should
 first load Compiler_A, then load MPI_C and only then is it possible to load the module for Appl_E:
 
 ```bash
@@ -102,6 +144,23 @@ and depending on those adapt the path to the binaries, several very simple modul
 logic, and one could add an Appl_E module for a different compiler or MPI implementation without touching any of the already
 existing module files for that application.
 
+Similarly, if after
+
+```bash
+module load Compiler_A MPI_C Appl_E
+```
+
+one does 
+
+```bash
+module load MPI_D
+```
+
+thent MPI_C gets unloaded, Lmod notices that it also has to unload/deactivate Appl_E, then will load MPI_D for Compiler_A and
+finally will notice that there is an equivalent Appl_E module available again, and Lmod will load that one also. However,
+now loading Compiler_B will cause a warning that MPI_D and Appl_E have been deactivated as there is no module name MPI_D in
+any version for Compiler_B.
+
 
 ### Building blocks
 
@@ -126,8 +185,9 @@ Some mechanisms in Lmod make implementing a hierarchy fairly easy (though there
 
 ### Implementation details
 
-The above example could be implemented using 6 module files: One for each compiler, two for the MPI module and 
-two for the application module.
+The above example could be implemented using 8 module files: One for each compiler, three for the MPI modules
+(two for MPI_C and one for MPI_D) and 
+three for the application modules.
 
 ```
 moduleroot
@@ -139,17 +199,23 @@ moduleroot
 ├── Compiler
 │   ├── Compiler_A
 │   │   └── version_A
-│   │       └── MPI_C
-│   │           └── version_C.lua
+│   │       ├── MPI_C
+│   │       │   └── version_C.lua
+│   │       └── MPI_D
+│   │           └── version_D.lua
 │   └── Compiler_B
 │       └── version_B
 │           └── MPI_C
 │               └── version_C.lua
 └── MPI
     ├── Compiler_A
     │   └── version_A
-    │       └── MPI_C
-    │           └── version_C
+    │       ├── MPI_C
+    │       │   └── version_C
+    │       │       └── Appl_E
+    │       │           └── version_E.lua
+    │       └── MPI_D
+    │           └── version_D
     │               └── Appl_E
     │                   └── version_E.lua
     └── Compiler_B

docs/2022-CSC_and_LO/3_00_part3_advanced.md

@@ -2,6 +2,12 @@
 
 *[[back to start page]](index.md)*
 
+In this section we mostly cover "good to know that they exist" features as they are not used
+on LUMI, or not really accessible to regular user installations that are performed with the
+LUMI ``EasyBuild-user`` module. Hooks are used on LUMI, but it is not really advised to
+overwrite the centrally defined hooks with a local file. And the whole structure of the 
+EasyBuild integration is also set up to make use of the GitHub integration in the future.
+
 * [Using EasyBuild as a library](3_01_easybuild_library.md) *(hands-on)*
 * [Using hooks to customise EasyBuild](3_02_hooks.md) *(hands-on)*
 * [Submitting installations as Slurm jobs](3_03_slurm_jobs.md) *(hands-on)*