More typos and whitelist

Author: msimberg

.github/actions/spelling/allow.txt

@@ -16,6 +16,7 @@ CXI
 Ceph
 Containerfile
 DNS
+Dockerfiles
 EDF
 EDFs
 EDFs
@@ -57,11 +58,9 @@ MFA
 MLP
 MNDO
 MPICH
-MPS
 MeteoSwiss
 NAMD
 NICs
-NVIDIA
 NVMe
 OTP
 OTPs
@@ -94,6 +93,8 @@ XDG
 aarch
 aarch64
 acl
+autodetection
+baremetal
 biomolecular
 bristen
 bytecode
@@ -104,33 +105,51 @@ concretizer
 containerised
 cpe
 cscs
+cuda
 customised
 diagonalisation
+dockerhub
+dotenv
 eiger
+epyc
 filesystems
+fontawesome
+gitlab
+gpu
 groundstate
 ijulia
 inodes
 iopsstor
+jfrog
 lexer
 libfabric
 miniconda
 mpi
+mps
 multitenancy
+netrc
 nsight
+numa
+nvidia
+octicons
+oom
 podman
+preinstalled
 prgenv
 prioritised
 proactively
+pyfirecrest
 pytorch
 quickstart
+rocm
 runtime
 runtimes
 santis
 sbatch
 screenshot
 slurm
 smartphone
+sphericart
 squashfs
 srun
 ssh

docs/running/slurm.md

@@ -68,7 +68,7 @@ $ sbatch --account=g123 ./job.sh
 !!! note
     The flags `--account` and `-Cmc` that were required on the old [Eiger][ref-cluster-eiger] cluster are no longer required.
 
-## Prioritization and scheduling
+## Prioritisation and scheduling
 
 Job priorities are determined based on each project's resource usage relative to its quarterly allocation, as well as in comparison to other projects.
 An aging factor is also applied to each job in the queue to ensure fairness over time.
@@ -219,7 +219,7 @@ The build generates the following executables:
 
     1. Test GPU affinity: note how all 4 ranks see the same 4 GPUs.
 
-    2. Test GPU affinity: note how the `--gpus-per-task=1` parameter assings a unique GPU to each rank.
+    2. Test GPU affinity: note how the `--gpus-per-task=1` parameter assigns a unique GPU to each rank.
 
 !!! info "Quick affinity checks"
 
@@ -491,7 +491,7 @@ rank   7 @ nid002199: thread 0 -> cores [112:127]
 In the above examples all threads on each -- we are effectively allowing the OS to schedule the threads on the available set of cores as it sees fit.
 This often gives the best performance, however sometimes it is beneficial to bind threads to explicit cores.
 
-The OpenMP threading runtime provides additional options for controlling the pinning of threads to the cores assinged to each MPI rank.
+The OpenMP threading runtime provides additional options for controlling the pinning of threads to the cores assigned to each MPI rank.
 
 Use the `--omp` flag with `affinity.mpi` to get more detailed information about OpenMP thread affinity.
 For example, four MPI ranks on one node with four cores and four OpenMP threads:

docs/services/cicd.md

@@ -718,7 +718,7 @@ Private projects will always get as notification a link to the CSCS pipeline ove
 To view the CSCS pipeline overview for a public project and restart / cancel jobs, follow these steps:
 
 * Copy the web link of the CSCS CI status of your project and remove the from the link the `type=gitlab`.
-* Alternativily, assemble the link yourself, it has the form `https://cicd-ext-mw.cscs.ch/ci/pipeline/results/<repository_id>/<project_id>/<pipeline_nb>` (the IDs can be found on the Gitlab page of your mirror project).
+* Alternatively, assemble the link yourself, it has the form `https://cicd-ext-mw.cscs.ch/ci/pipeline/results/<repository_id>/<project_id>/<pipeline_nb>` (the IDs can be found on the Gitlab page of your mirror project).
 * Click on `Login to restart jobs` at the bottom right and login with your CSCS credentials
 * Click `Cancel running` or `Restart jobs` or cancel individual jobs (button next to job's name)
 * Everybody that has at least *Manager* access can restart / cancel jobs (access level is managed on the CI setup page in the Admin section)
@@ -819,7 +819,7 @@ Accepted variables are documented at [Slurm's srun man page](https://slurm.sched
 
 !!! Warning "SLURM_TIMELIMIT"
     Special attention should go the variable `SLURM_TIMELIMIT`, which sets the maximum time of your Slurm job.
-    You will be billed the nodehours that your CI jobs are spending on the cluster, i.e. you want to set the `SLURM_TIMELIMIT` to the maximum time that you expect the job to run.
+    You will be billed the node hours that your CI jobs are spending on the cluster, i.e. you want to set the `SLURM_TIMELIMIT` to the maximum time that you expect the job to run.
     You should also pay attention to wrap the value in quotes, because the gitlab-runner interprets the time differently than Slurm, when it is not wrapped in quotes, i.e. This is correct:
     ```
     SLURM_TIMELIMIT: "00:30:00"
@@ -1323,7 +1323,7 @@ The easiest way to use the FirecREST scheduler of ReFrame is to use the configur
 In case you want to run ReFrame for a system that is not already available in this directory, please open a ticket to the Service Desk and we will add it or help you update one of the existing ones.
 
 Something you should be aware of when running with this scheduler is that ReFrame will not have direct access to the filesystem of the cluster so the stage directory will need to be kept in sync through FirecREST.
-It is recommended to try to clean the stage directory whenever possible with the [postrun_cmds](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postrun_cmds) and [postbuild_cmds](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postbuild_cmds) and to avoid [autodetection of the processor](https://reframe-hpc.readthedocs.io/en/stable/config_reference.html#config.systems.partitions.processor) in each run.
+It is recommended to try to clean the stage directory whenever possible with the [`postrun_cmds`](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postrun_cmds) and [`postbuild_cmds`](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postbuild_cmds) and to avoid [autodetection of the processor](https://reframe-hpc.readthedocs.io/en/stable/config_reference.html#config.systems.partitions.processor) in each run.
 Normally ReFrame stores these files in `~/.reframe/topology/{system}-{part}/processor.json`, but you get a "clean" runner every time.
 You could either add them in the configuration files or store the files in the first run and copy them to the right directory before ReFrame runs.