More typos and whitelist

Author: msimberg

.github/actions/spelling/allow.txt

@@ -1,9 +1,9 @@
 ACLs
 ACR
 AMD
-AWS
 Alpstein
 Balfrin
+Besard
 Broyden
 CFLAGS
 CHARMM
@@ -17,17 +17,16 @@ Ceph
 Containerfile
 DNS
 Dockerfiles
-EDF
-EDFs
-EDFs
+Dufourspitze
 EMPA
 ETHZ
 Ehrenfest
 Errigal
 FFT
+Fawzi
 Fock
+Foket
 GAPW
-GCC
 GGA
 GPFS
 GPG
@@ -39,29 +38,41 @@ GTL
 Gaussian
 Google
 HDD
+HDDs
 HPC
 HPCP
 HPE
 HSN
 Hartree
+Invernizzi
 Jax
 Jira
 Keycloak
+Kwasniewski
 LAMMPS
+LAPACK
 LDA
+LLM
+LLMs
 LOCALID
 LUMI
 Libc
 Linaro
 Linux
+MDS
+MDSs
 MFA
 MLP
 MNDO
 MPICH
+Malvoisin
 MeteoSwiss
 NAMD
 NICs
 NVMe
+Nordend
+OSS
+OSSs
 OTP
 OTPs
 PASC
@@ -71,8 +82,10 @@ PID
 PMPI
 POSIX
 Parrinello
+Pintarelli
 Piz
 Plesset
+Podladchikov
 Pulay
 RCCL
 RDMA
@@ -83,22 +96,25 @@ Roothaan
 SSHService
 STMV
 Scopi
+Signalkuppe
 TOTP
 UANs
 UserLab
-VASP
-Waldur
 Wannier
 XDG
+Zumsteinspitz
 aarch
 aarch64
 acl
+artifactory
 autodetection
+aws
 baremetal
 biomolecular
 bristen
 bytecode
 capstor
+chatbot
 clariden
 concretise
 concretizer
@@ -112,47 +128,79 @@ diagonalisation
 dimms
 dockerhub
 dotenv
+dropbear
+edf
+edfs
 eiger
 epyc
+fftw
 filesystems
 fontawesome
+gcc
 gdrcopy
+github
 gitlab
+gpt
 gpu
 groundstate
+gsl
+hdf
+huggingface
+hwloc
+iframe
 ijulia
-julia
-linalg
-linux
-nccl
-osts
-quantumespresso
 inodes
 iopsstor
 jfrog
+jobreport
+juhpc
+julia
+juliaup
 jupyter
+kokkos
 lexer
 libfabric
+linalg
+linux
+matlab
+meteo
 miniconda
+mkl
 mpi
 mps
 multitenancy
 nanotron
+nccl
+netlib
 netrc
 nsight
 numa
+nvcr
 nvdashboard
 nvidia
+nwp
 octicons
+ofi
+omlin
+omp
 oom
+osts
+osu
+papi
+pme
+pmi
 podman
 preinstalled
+prerelease
+prereleases
 prgenv
 prioritisation
+prioritise
 prioritised
 proactively
 pyfirecrest
 pytorch
+quantumespresso
 quickstart
 rocm
 runtime
@@ -162,6 +210,7 @@ sbatch
 screenshot
 slurm
 smartphone
+sourced
 sphericart
 squashfs
 srun
@@ -188,24 +237,36 @@ torchaudio
 torchvision
 treesitter
 trilinos
+trl
 uarch
 uenv
 uenvs
 uids
+utkin
 vCluster
 vClusters
+valgrind
+vasp
+vboost
 venv
 versioned
 versioning
+waldur
+wandb
 webhooks
 webinar
 webpage
 website
 wikipedia
+wikitext
+wlcg
 workaround
 workflows
 xattr
 xattrs
+xcb
+xfer
+xname
+xpmem
 youtube
 zstd
-hdf

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

@@ -9,3 +9,7 @@
 # ignore indented code blocks
     ```
     ```
+
+# ignore embedded iframes
+<iframe
+</iframe>

.github/actions/spelling/patterns.txt

@@ -3,9 +3,10 @@
 FirecREST
 RESTful
 IPyParallel
+\`ENV\`ironment
 
 # markdown figure
- ^!\[.*\]\(.*\)$
+^!\[.*\]\(.*\)$
 
 # Most obvious URLs
 https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)

docs/accounts/account-create.md

@@ -16,7 +16,7 @@ Clicking the "Create a new account" button will lead the user to the second step
 
 After submitting personal information, users have to wait for CSCS to review and approve the submission.
 
-Once accepted, you will recieve an email with a link to set your password.
+Once accepted, you will receive an email with a link to set your password.
 
 ```title="Acceptance email"
 Dear John Doe,

docs/alps/hardware.md

@@ -65,7 +65,7 @@ There are 24 cabinets, in 4 rows with 6 cabinets per row, and each cabinet conta
 !!! info "Why 7 blades per chassis?"
     A chassis can contain up to 8 blades, however Alps' gh200 chassis are underpopulated so that we can increase the amount of power delivered to each GPU.
 
-Each node contains four Grace-Hopper modules and four corresponding network interface cards (NICS) per blade, as illustrated below:
+Each node contains four Grace-Hopper modules and four corresponding network interface cards (NICs) per blade, as illustrated below:
 
 ![](../images/alps/gh200-schematic.svg)
 

docs/guides/mlp_tutorials/index.md

@@ -4,7 +4,7 @@
 These tutorials solve simple MLP tasks using the [Container Engine][ref-container-engine] on the ML Platform.
 
 1. [LLM Inference][ref-mlp-llm-inference-tutorial]
-2. [LLM Finetuning][ref-mlp-llm-finetuning-tutorial]
+2. [LLM Fine-tuning][ref-mlp-llm-finetuning-tutorial]
 3. [Nanotron Training][ref-mlp-llm-nanotron-tutorial]
 
 

docs/guides/mlp_tutorials/llm-finetuning.md

@@ -1,8 +1,8 @@
 [](){#ref-mlp-llm-finetuning-tutorial}
 
-# LLM Finetuning Tutorial
+# LLM Fine-tuning Tutorial
 
-This tutorial will take the model from the [LLM Inference][ref-mlp-llm-inference-tutorial] tutorial and show you how to perform finetuning.
+This tutorial will take the model from the [LLM Inference][ref-mlp-llm-inference-tutorial] tutorial and show you how to perform fine-tuning.
 This means that we take the model and train it on some new custom data to change its behavior.
 
 To complete the tutorial, we set up some extra libraries that will help us to update the state of the machine learning model.
@@ -38,10 +38,10 @@ $ pip install -e ./trl   # install in editable mode
 
 When this step is complete, you can exit the shell by typing `exit`.
 
-### Finetune Gemma-7B
+### Fine-tune Gemma-7B
 
 t this point, we can set up a fine-tuning script and start training Gemma-7B.
-Use your favorite text editor to create the file `fine-tune-gemma.sh` just outside the trl and gemma-venv directories:
+Use your favorite text editor to create the file `fine-tune-gemma.sh` just outside the `trl` and `gemma-venv` directories:
 
 ```bash title="fine-tune-gemma.sh"
 #!/bin/bash
@@ -119,7 +119,7 @@ It should take about 10-15 minutes to fine-tune Gemma:
 $ sbatch --nodes=1 fine-tune-sft.sbatch
 ```
 
-### Compare finetuned Gemma against default Gemma
+### Compare fine-tuned Gemma against default Gemma
 
 We can reuse our python script from the first tutorial to do inference on the Gemma model that we just fine-tuned.
 Let's try out a different prompt in `gemma-inference.py`:

docs/guides/mlp_tutorials/llm-inference.md

@@ -12,7 +12,7 @@ The model we will be running is Google's [Gemma-7B](https://huggingface.co/googl
 
 ## Gemma-7B Inference using NGC PyTorch
 
-### Prequisites
+### Prerequisites
 
 This tutorial assumes you are able to access the cluster via SSH. To set up access to CSCS systems, follow the guide [here][ref-ssh], and read through the documentation about the [ML Platform][ref-platform-mlp].
 
@@ -39,7 +39,7 @@ RUN apt-get update && apt-get install -y python3.10-venv && apt-get clean && rm
 ```
 
 The first line specifies that we are working on top of an existing container.
-In this case we start `FROM`  an NGC PyTorch container.
+In this case we start `FROM` an NGC PyTorch container.
 Next, we set an `ENV`ironment variable that helps us run `apt-get` in the container.
 Finally, we `RUN` the package installer `apt-get` to install python virtual environments.
 This will let us install python packages later on without having to rebuild the container again and again.
@@ -76,14 +76,14 @@ $ enroot import -x mount -o pytorch-24.01-py3-venv.sqsh podman://pytorch:24.01-p
 
 where you should replace `<ACCOUNT>` with your project account ID.
 At this point, you can exit the Slurm allocation by typing `exit`.
-You should be able to see a new squashfile next to your Dockerfile:
+You should be able to see a new squashfs file next to your Dockerfile:
 
 ```console
 $ ls
 Dockerfile  pytorch-24.01-py3-ven.sqsh
 ```
 
-This squashfile is essentially a compressed container image, which can be run directly by the container engine.
+This squashfs file is essentially a compressed container image, which can be run directly by the container engine.
 We will use our freshly-built container `pytorch-24.01-py3-venv.sqsh` in the following steps to run a PyTorch script that loads the Google Gemma-7B model and performs some inference with it.
 
 ### Set up an EDF
@@ -109,7 +109,7 @@ Make sure to replace `<USER>` with your actual CSCS username.
 If you've decided to build the container somewhere else, make sure to supply the correct path to the `image` variable. 
 
 The `image` variable defines which container we want to load.
-This could either be a container from an online docker repository, like `nvcr.io/nvidia/pytorch:24.01-py3`, or in our case, a local squashfile which we built ourselves.
+This could either be a container from an online docker repository, like `nvcr.io/nvidia/pytorch:24.01-py3`, or in our case, a local squashfs file which we built ourselves.
 
 The `mounts` variable defines which directories we want to mount where in our container.
 In general, it's a good idea to use the scratch directory to store outputs from any scientific software.
@@ -278,7 +278,7 @@ Move on to the next tutorial or try the challenge.
 
 ### Challenge
 
-Using the same approach as in the latter half of step 4, use pip to install the package `nvitop`. This is a tool that shows you a concise real-time summary of GPU activity. Then, run Gemma and launch nvitop at the same time:
+Using the same approach as in the latter half of step 4, use pip to install the package `nvitop`. This is a tool that shows you a concise real-time summary of GPU activity. Then, run Gemma and launch `nvitop` at the same time:
 
 ```console
 (gemma-venv)$ python ./gemma-inference.py > ./gemma-output.log 2>&1 & nvitop
@@ -288,7 +288,7 @@ Note the use of bash `> ./gemma-output.log 2>&1` to hide any output from Python.
 Note also the use of the single ampersand `'&'` which backgrounds the first command and runs `nvitop` on top.
 
 After a moment, you will see your Python script spawn on all four GPUs, after which the GPU activity will increase a bit and then go back to idle.
-At this point, you can hit `q` to quite nvitop and you will find the output of your Python script in `./gemma-output.log`.
+At this point, you can hit `q` to quit `nvitop` and you will find the output of your Python script in `./gemma-output.log`.
 
 ### Collaborating in Git