clariden documentation (#35)

Author: bcumming

docs/alps/storage.md

@@ -16,16 +16,19 @@ These separate clusters are on the same Slingshot 11 network as the Alps.
 | IOPs         | 1.5M                   | 8.6M read, 24M write   | 200k read, 768k write |
 | file create/s| 374k                   | 214k                   | 97k                 |
 
+[](){#ref-alps-capstor}
 ## capstor
 
 Capstor is the largest file system, for storing large amounts of input and output data.
 It is used to provide SCRATCH and STORE for different clusters - the precise details are platform-specific.
 
+[](){#ref-alps-iopstor}
 ## iopstor
 
 !!! todo
     small text explaining what iopstor is designed to be used for.
 
+[](){#ref-alps-vast}
 ## vast
 
 The Vast storage is smaller capacity system that is designed for use as home folders.

docs/build-install/containers.md

@@ -1,3 +1,4 @@
+[](){#ref-build-containers}
 # Building container images on Alps
 
 Building OCI container images on Alps vClusters is supported through [Podman](https://podman.io/), an open-source container engine that adheres to OCI standards and supports rootless containers by leveraging Linux [user namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html).

docs/index.md

@@ -1,5 +1,12 @@
 # CSCS Documentation
 
+<div class="grid cards" markdown>
+-    Visit the CSCS status site for the status of Alps systems, and the latest announcements.
+
+
+    [:octicons-arrow-right-24: status.cscs.ch](https://status.cscs.ch/)
+</div>
+
 Start here to get access to CSCS services and Alps
 
 <div class="grid cards" markdown>

docs/policies/index.md

@@ -25,6 +25,6 @@ Furthermore, as soon as your project expires, the backup of the data belonging t
 [](){#ref-policies-fair-use}
 ## Fair Usage of Shared Resources
 
-The [Slurm][slurm] scheduling system is a shared resource that can handle a limited number of batch jobs and interactive commands simultaneously. Therefore users should not submit hundreds of Slurm jobs and commands at the same time, as doing so would infringe our fair usage policy.
+The [Slurm][ref-slurm] scheduling system is a shared resource that can handle a limited number of batch jobs and interactive commands simultaneously. Therefore users should not submit hundreds of Slurm jobs and commands at the same time, as doing so would infringe our fair usage policy.
 
 Let us also remind you that **running compute or memory intensive applications on the login nodes is forbidden**. Please submit batch jobs with the Slurm scheduler, in order to allocate and run your processes on compute nodes: compute or memory intensive processes affecting the performance of login nodes will be terminated without warning.

docs/software/sciapps/namd.md

@@ -131,7 +131,7 @@ The [NAMD] `uenv` provides all the dependencies required to build [NAMD] from so
         --with-fftw --with-fftw3 --fftw-prefix ${DEV_VIEW_PATH} \
         --cuda-gencode arch=compute_90,code=sm_90 --with-single-node-cuda --with-cuda --cuda-prefix ${DEV_VIEW_PATH}
     cd Linux-ARM64-g++.cuda && make -j 32
-    
+
     # The namd3 executable (GPU-accelerated) will be built in the Linux-ARM64-g++.cuda directory
     ```
 
@@ -153,7 +153,7 @@ The [NAMD] `uenv` provides all the dependencies required to build [NAMD] from so
         Do not use the CPU-only build for actual simulations as it will be slower than the GPU build.
 
     You can build a CPU-only version of NAMD as follows:
-    
+
     ```bash
     export DEV_VIEW_NAME="develop-single-node"
     export PATH_TO_NAMD_SOURCE=<PATH_TO_NAMD_SOURCE>
@@ -170,7 +170,7 @@ The [NAMD] `uenv` provides all the dependencies required to build [NAMD] from so
     !!! info "Action required"
         Modify the `<PATH_TO_NAMD_SOURCE>/arch/Linux-ARM64.tcl` file now.
         Change `-ltcl8.5` with `-ltcl8.6` in the definition of the `TCLLIB` variable.
-    
+
     ```bash
     # Build bundled Charm++
     tar -xvf charm-8.0.0.tar && cd charm-8.0.0

docs/storage/filesystems.md

@@ -6,22 +6,58 @@
 
 CSCS supports different file systems, whose specifications are summarized in the table below:
 
-|          | `$SCRATCH` | `$PROJECT` | `$STORE` | `$HOME` | `$PROJECT_ID` | `$SCRATCH_ID` | `$STORE_ID` |
-|----------|-----------|-----------|----------|--------|--------------|--------------|------------|
-| Access Speed | Fast | Fast | Fast | Slow | Fast | Medium | Slow |
-| Capacity | 8.8 PB | 91 PB | 1.9 PB | 160 TB | 91 PB | 6.0 PB | 7.6 PB |
-| Data Backup | None | None | None | 90 days | 90 days | 90 days | 90 days |
-| Expiration | 30 days | 30 days | 30 days | Account closure | End of the project/contract | End of the project | End of the contract |
-| Quota | Soft (1M files) | Soft (150 TB and 1M files) | None | 50GB/user and 500k files | 150 TB and 1M files | Maximum 50k files/TB | Maximum 50k files/TB |
-| Type | Lustre | Lustre | GPFS | GPFS | Lustre | GPFS | GPFS |
-
-To check your usage, please type the command `quota` on the front end Ela.
 
 Please build big software projects not fitting `$HOME` on `$PROJECT` instead.
 Since you should not run jobs from `$HOME` or `$PROJECT`, please copy the executables, libraries and data sets needed to run your simulations to `$SCRATCH` with the Slurm transfer queue.
 
 Users can also write temporary builds on `/dev/shm`, a filesystem using virtual memory rather than a persistent storage device: please note that files older than 24 hours will be deleted automatically.
 
+[](){#ref-storage-quota}
+## Quota
+
+You can check your storage quotas with the command quota on the front-end system ela (ela.cscs.ch) and the login nodes of [eiger][ref-cluster-eiger], [daint][ref-cluster-daint], [santis][ref-cluster-santis], and [clariden][ref-cluster-clariden].
+
+```bash
+$ quota
+Retrieving data ...
+
+User: testuser
+Usage data updated on: 2025-02-21 16:01:27
++------------------------------------+--------+-----+-------+----+-------------+----------+-----+---------+------+-------------+
+|                                    |  User quota  | Proj quota |             |   User files   |   Proj files   |             |
++------------------------------------+--------+-----+-------+----+-------------+----------+-----+---------+------+-------------+
+| Directory                          |   Used |   % |  Used |  % | Quota limit |     Used |   % |    Used |    % | Files limit |
++------------------------------------+--------+-----+-------+----+-------------+----------+-----+---------+------+-------------+
+| /iopsstor/scratch/cscs/testuser    |   4.0K |   - |     - |  - |           - |        1 |   - |       - |    - |           - |
+| /capstor/scratch/cscs/testuser     |   8.0K | 0.0 |     - |  - |      150.0T |        2 | 0.0 |       - |    - |     1000000 |
+| /users/testuser                    |  32.0K | 0.0 |     - |  - |       50.0G |       42 | 0.0 |       - |    - |      500000 |
++------------------------------------+--------+-----+-------+----+-------------+----------+-----+---------+------+-------------+
+```
+
+Quotas apply to the total size of stored data, and in some cases to the number of [inodes](https://en.wikipedia.org/wiki/Inode), to the filesystems on Alps.
+The command reports both disk space and the number of files for each filesystem/directory.
+
+??? note "what is an inode"
+    inodes are data structures that describe Linux file system objects like files and directories - every file and directory has a corresponding inode.
+
+    Large inode counts degrade file system performance in multiple ways.
+    For example, Lustre filesystems have separate metadata and data management.
+    Excessive inode usage can overwhelm the metadata servces, causing degradation across the filesystem.
+
+    !!! tip
+        Consider archiving folders with the tar command in order to keep low the number of files owned by users and groups.
+
+    !!! tip
+        Consider compressing directories full of many small input files as squashfs images - which pack many files into a single file that can be mounted to access the contents efficiently.
+
+!!! note
+    The size of the quota depends on the file system, platform and project.
+
+[](){#ref-storage-cleaning}
+
+## Cleaning Policy and Data Retention
+
+
 ## Scratch
 
 The scratch file system is designed for performance rather than reliability, as a fast workspace for temporary storage.

docs/storage/transfer.md

@@ -1,5 +1,7 @@
+[](){#ref-data-xfer}
 # Data Transfer
 
+[](){#ref-data-xfer-external}
 ## External Transfer
 
 CSCS currently offers the CSCS Globus online endpoint for uploading and downloading data from and to CSCS:
@@ -35,10 +37,11 @@ Currently Globus provide the following mount points at CSCS:
 | `/capstor/users/cscs` | Home directory for Bristen/Scopi/Errigal |
 | `/vast/users/cscs` | New Alps vclustewrs home directory  ( Alps Daint and others ) |
 
+[](){#ref-data-xfer-internal}
 ## Internal Transfer
 
-The Slurm queue `xfer` is available on Piz Daint (Cray XC) and daint.alps to address data transfers between internal CSCS file systems.
-The queue has been created to transfer files and folders from /users, /project, /store or /capstor/store to the /capstor/scratch and /scratch file systems (stage-in) and vice versa (stage-out).
+The Slurm queue `xfer` is available on Alps clusters to address data transfers between internal CSCS file systems.
+The queue has been created to transfer files and folders from `/users`, `/capstor/store` or `/iopstor/store` to the `/capstor/scratch` and `/iopstor/scratch` file systems (stage-in) and vice versa (stage-out).
 Currently the following commands are available on the cluster supporting the queue xfer:
 
 ```

docs/stylesheets/extra.css

@@ -1,8 +1,11 @@
 :root {
   --md-admonition-icon--alps: url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.4.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2023 Fonticons, Inc.--><path d="M256 32c12.5 0 24.1 6.4 30.8 17l216.6 345.4c5.6 8.9 8.6 19.2 8.6 29.7 0 30.9-25 55.9-55.9 55.9H55.9C25 480 0 455 0 424.1c0-10.5 3-20.8 8.6-29.7L225.2 49c6.6-10.6 18.3-17 30.8-17zm65 192-65-103.6-79.1 126.1 18.3 24.4c6.4 8.5 19.2 8.5 25.6 0l25.6-34.1c6-8.1 15.5-12.8 25.6-12.8h49z"/></svg>');
+--md-admonition-icon--digging: url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 576 512"><!--! Font Awesome Free 6.7.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M208 64a48 48 0 1 1 96 0 48 48 0 1 1-96 0M9.8 214.8c5.1-12.2 19.1-18 31.4-12.9l19.5 8.1 22.9-38.1C99.9 144.6 129.3 128 161 128c51.4 0 97 32.9 113.3 81.7l34.6 103.7 79.3 33.1 34.2-45.6c6.4-8.5 16.6-13.3 27.2-12.8s20.3 6.4 25.8 15.5l96 160c5.9 9.9 6.1 22.2.4 32.2S555.5 512 544 512H288c-11.1 0-21.4-5.7-27.2-15.2s-6.4-21.2-1.4-31.1l16-32c5.4-10.8 16.5-17.7 28.6-17.7h32l22.5-30L22.8 246.2c-12.2-5.1-18-19.1-12.9-31.4zm82.8 91.8 112 48c11.8 5 19.4 16.6 19.4 29.4v96c0 17.7-14.3 32-32 32s-32-14.3-32-32v-74.9l-60.6-26-37 111c-5.6 16.8-23.7 25.8-40.5 20.2s-25.8-23.7-20.3-40.4l48-144 11-33z"/></svg>');
   --base-border-radius: 0.2rem;
   --base-border-width: 0.05rem;
 }
+
+/* alps admonition */
 .md-typeset .admonition.alps,
 .md-typeset details.alps {
   border-color: rgb(255, 51, 51);
@@ -17,6 +20,8 @@
   -webkit-mask-image: var(--md-admonition-icon--alps);
           mask-image: var(--md-admonition-icon--alps);
 }
+
+/* change admonition */
 .md-typeset .admonition.change,
 .md-typeset details.change {
   border-color: rgb(43, 155, 70);
@@ -28,8 +33,8 @@
 .md-typeset .change > .admonition-title::before,
 .md-typeset .change > summary::before {
   background-color: rgb(43, 155, 70);
-  -webkit-mask-image: var(--md-admonition-icon--alps);
-          mask-image: var(--md-admonition-icon--alps);
+  -webkit-mask-image: var(--md-admonition-icon--digging);
+          mask-image: var(--md-admonition-icon--digging);
 }
 
 /* todo admonition */
@@ -87,7 +92,6 @@
 
 /* code hilighting */
 
-
 /* light mode:  pale yellow background, solid black foreground */
 [data-md-color-scheme="default"] {
   --md-code-bg-color: #fdfdfd;
@@ -103,11 +107,26 @@
 /* Light mode */
 [data-md-color-scheme="default"] .md-typeset pre {
   border: 2px solid #b4b4b4;
-  border-radius: 2px; /* slight rounding to corners */
+  border-radius: 2px;
+}
+
+[data-md-color-scheme="default"] .highlight span.filename {
+  border-left: 2px solid #b4b4b4;
+  border-right: 2px solid #b4b4b4;
+  border-top: 2px solid #b4b4b4;
+  border-radius: 2px;
 }
 
 /* Dark mode */
 [data-md-color-scheme="slate"] .md-typeset pre {
-  border: 2px solid #3f4013;
+  border: 2px solid #707070;
+  border-radius: 2px;
+}
+
+[data-md-color-scheme="slate"] .highlight span.filename {
+  border-left: 2px solid #707070;
+  border-right: 2px solid #707070;
+  border-top: 2px solid #707070;
   border-radius: 2px;
 }
+

docs/tools/container-engine.md

@@ -1,4 +1,4 @@
-[](){#container-engine}
+[](){#ref-container-engine}
 # Container Engine
 
 The Container Engine (CE) toolset is designed to enable computing jobs to seamlessly run inside Linux application containers, thus providing support for containerized user environments.

docs/tools/firecrest.md

@@ -1,3 +1,4 @@
+[](){#ref-firecrest}
 # FirecREST
 
 FirecREST is a RESTful API for managing High-Performance Computing resources, developed at CSCS.