Fix more spelling, add more words to whitelist

Author: msimberg

.github/actions/spelling/allow.txt

@@ -109,28 +109,33 @@ cuda
 customised
 dcomex
 diagonalisation
+dimms
 dockerhub
 dotenv
 eiger
 epyc
 filesystems
 fontawesome
+gdrcopy
 gitlab
 gpu
 groundstate
 ijulia
 inodes
 iopsstor
 jfrog
+jupyter
 lexer
 libfabric
 miniconda
 mpi
 mps
 multitenancy
+nanotron
 netrc
 nsight
 numa
+nvdashboard
 nvidia
 octicons
 oom

.github/actions/spelling/block-delimiters.list

@@ -5,3 +5,7 @@
 # ignore code blocks
 ```
 ```
+
+# ignore indented code blocks
+    ```
+    ```

.github/actions/spelling/patterns.txt

@@ -1,18 +1,25 @@
-# Recognized as "Firec" and "REST" with the regular rules, so in patterns.txt
-# instead of allow.txt
+# Recognized as separate words (e.g. "Firec" and "REST") with the regular rules,
+# so in patterns.txt instead of allow.txt
 FirecREST
 RESTful
+IPyParallel
 
 # markdown figure
-^!\[.*\]\(.*\)$
+ ^!\[.*\]\(.*\)$
 
 # Most obvious URLs
 https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)
 
-# Markdown references (definition and use)
+# Markdown references and URLs (definition and use)
 ^\[\]\(\){#[a-z-]+}$
-\]\(#[a-z-]+\)
+\]\([^\s]+\)
 \]\[[a-z-]+\]
 
+# Markdown URLs
+
 # Inline code
 \`[^\`]+\`
+
+# kebab-case and snake_case words
+[a-z]+-[a-z-]+
+[a-z]+_[a-z_]+

docs/clusters/eiger.md

@@ -37,7 +37,7 @@ Eiger is an Alps cluster that provides compute nodes and file systems designed t
 Eiger consists of multicore [AMD Epyc Rome][ref-alps-zen2-node] compute nodes: please note that the total number of available compute nodes on the system might vary over time.
 See the [Slurm documentation][ref-slurm-partitions-nodecount] for information on how to check the number of nodes.
 
-Additionally, there are four login nodes with hostnames `eiger-ln00[1-4]`.
+Additionally, there are four login nodes with host names `eiger-ln00[1-4]`.
 
 ### Storage and file systems
 

docs/guides/storage.md

@@ -124,12 +124,12 @@ Its performance is roughly the same on [Capstor][ref-alps-capstor] and [Iopsstor
 This data is globally synchronized, which means Lustre is not well suited to handling many small files, see the discussion on [how to handle many small files][ref-guides-storage-small-files].
 
 The data itself is subdivided in blocks of size `<blocksize>` and is stored by Object Storage Servers (OSS) in one or more Object Storage Targets (OST).
-The blocksize and number of OSTs to use is defined by the striping settings, which are applied to a path, with new files and directories ihneriting them from their parent directory.
+The block size and number of OSTs to use is defined by the striping settings, which are applied to a path, with new files and directories ihneriting them from their parent directory.
 The `lfs getstripe <path>` command can be used to get information on the stripe settings of a path.
 For directories and empty files `lfs setstripe --stripe-count <count> --stripe-size <size> <directory/file>` can be used to set the layout.
 The simplest way to have the correct layout is to copy to a directory with the correct layout
 
-!!! tip "A blocksize of 4MB gives good throughput, without being overly big..."
+!!! tip "A block size of 4MB gives good throughput, without being overly big..."
     ... so it is a good choice when reading a file sequentially or in large chunks, but if one reads shorter chunks in random order it might be better to reduce the size, the performance will be smaller, but the performance of your application might actually increase.
     See the [Lustre documentation](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace) for more information.
 
@@ -149,7 +149,7 @@ With it it is possible to create a Progressive file layout switching `--stripe-c
 ### Iopsstor vs Capstor
 
 [Iopsstor][ref-alps-iopsstor] uses SSD as OST, thus random access is quick, and the performance of the single OST is high.
-[Capstor][ref-alps-capstor] on another hand uses harddisks, it has a larger capacity, and  it also have many more OSS, thus the total bandwidth is larger.
+[Capstor][ref-alps-capstor] on another hand uses hard disks, it has a larger capacity, and  it also have many more OSS, thus the total bandwidth is larger.
 See for example the [ML filesystem guide][ref-mlp-storage-suitability].
 
 [](){#ref-guides-storage-small-files}

docs/services/cicd.md

@@ -994,7 +994,7 @@ The default is `none`, and you must explicitly set it to `fetch`  or `clone`  to
 ##### `CSCS_CUDA_MPS`
 Optional variable, default is `NO`
 
-Enable running with nvidia-mps-server, which allows multiple ranks sharing the same GPU.
+Enable running with `nvidia-mps-server`, which allows multiple ranks sharing the same GPU.
 
 ##### `USE_MPI`
 Optional variable, default is `AUTO`
@@ -1202,7 +1202,7 @@ Loads the view of a uenv.
 ##### `CSCS_CUDA_MPS`
 Optional variable, default is `NO`
 
-Enable running with nvidia-mps-server, which allows multiple ranks sharing the same GPU.
+Enable running with `nvidia-mps-server`, which allows multiple ranks sharing the same GPU.
 
 #### Example jobs
 ```yaml
@@ -1405,8 +1405,7 @@ A couple of projects which use this CI setup.
 Please have a look there for more advanced usage:
 
 * [dcomex-framework](https://github.com/DComEX/dcomex-framework): entry point is `ci/prototype.yml`
-* [mars](https://bitbucket.org/zulianp/mars/src/development/): two pipelines, with entry points `ci/gitlab/cscs/gpu/gitlab-
-daint.yml` and `ci/gitlab/cscs/mc/gitlab-daint.yml`
+* [mars](https://bitbucket.org/zulianp/mars/src/development/): two pipelines, with entry points `ci/gitlab/cscs/gpu/gitlab-daint.yml` and `ci/gitlab/cscs/mc/gitlab-daint.yml`
 * [sparse_accumulation](https://github.com/lab-cosmo/sparse_accumulation): entry point is `ci/pipeline.yml`
 * [gt4py](https://github.com/GridTools/gt4py): entry point is `ci/cscs-ci.yml`
 * [SIRIUS](https://github.com/electronic-structure/SIRIUS): entry point is `ci/cscs-daint.yml`

docs/software/ml/pytorch.md

@@ -383,7 +383,7 @@ srun bash -c "
 6. Disable GPU support in MPICH, as it [can lead to deadlocks](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/mpi.html#inter-gpu-communication-with-cuda-aware-mpi) when using together with nccl.
 7. Avoid writing JITed binaries to the (distributed) file system, which could lead to performance issues.
 8. These variables should always be set for correctness and optimal performance when using NCCL, see [the detailed explanation][ref-communication-nccl].
-9. `RANK` and `LOCAL_RANK` are set per-process by the Slurmjob launcher.
+9. `RANK` and `LOCAL_RANK` are set per-process by the Slurm job launcher.
 10. Activate the virtual environment created on top of the uenv (if any).
    Please follow the guidelines for [python virtual environments with uenv][ref-guides-storage-venv] to enhance scalability and reduce load times. 
 

docs/storage/filesystems.md

@@ -124,7 +124,7 @@ Please ensure that you move important data to a file system with backups, for ex
 ## Store
 
 Store is a large, medium-performance, storage on the [Capstor][ref-alps-capstor] Lustre file system for sharing data within a project, and for medium term data storage.
-See the [Lustre guide][ref-guides-storage-lustre] for some hints on how to get the best preformance out of the filesystem.
+See the [Lustre guide][ref-guides-storage-lustre] for some hints on how to get the best performance out of the filesystem.
 
 Space on Store is allocated per-project, with a path created for each project.
 To accomodate the different customers and projects on Alps, the project paths are organised as follows: