---
title: Slurm merlin7 Configuration
#tags:
keywords: configuration, partitions, node definition
#last_updated: 24 Mai 2023
summary: "This document describes a summary of the Merlin7 Slurm CPU-based configuration."
sidebar: merlin7_sidebar
permalink: /merlin7/slurm-configuration.html
---

This documentation shows basic Slurm configuration and options needed to run jobs in the Merlin7 cluster.

## Public partitions configuration summary

### CPU public partitions

| PartitionName      |  DefaultTime  | MaxTime     | Priority | Account          | Per Job Limits     | Per User Limits    | 
| -----------------: |  -----------: | ----------: | -------: | ---------------: | -----------------: | -----------------: |
| **<u>general</u>** |  1-00:00:00   | 7-00:00:00  | Low      | <u>merlin</u>    | cpu=1024,mem=1920G | cpu=1024,mem=1920G |
| **daily**          |  0-01:00:00   | 1-00:00:00  | Medium   | <u>merlin</u>    | cpu=1024,mem=1920G | cpu=2048,mem=3840G |
| **hourly**         |  0-00:30:00   | 0-01:00:00  | High     | <u>merlin</u>    | cpu=2048,mem=3840G |   cpu=8192,mem=15T |

### GPU public partitions

#### A100 nodes

| PartitionName        | DefaultTime  | MaxTime     | Priority   | Account        | Per Job Limits                   | Per User Limits                  |
| -------------------: | -----------: | ----------: | ---------: | -------------: | -------------------------------: | -------------------------------: |
| **a100-general**     | 1-00:00:00   | 7-00:00:00  | Low        | <u>merlin</u>  | gres/gpu=4                       | gres/gpu=8                       |
| **a100-daily**       | 0-01:00:00   | 1-00:00:00  | Medium     | <u>merlin</u>  | gres/gpu=8                       | gres/gpu=8                       |
| **a100-hourly**      | 0-00:30:00   | 0-01:00:00  | High       | <u>merlin</u>  | gres/gpu=8                       | gres/gpu=8                       |
| **a100-interactive** | 0-01:00:00   | 0-12:00:00  | Very High  | <u>merlin</u>  | cpu=16,gres/gpu=1,mem=60G,node=1 | cpu=16,gres/gpu=1,mem=60G,node=1 |
                                                                                   
#### Grace-Hopper nodes

| PartitionName        | DefaultTime  | MaxTime     | Priority   | Account        | Per Job Limits                   | Per User Limits                  |
| -------------------: | -----------: | ----------: | ---------: | -------------: | -------------------------------: | -------------------------------: |
| **gh-general**       |  1-00:00:00   | 7-00:00:00 | Low        | <u>merlin</u>  | gres/gpu=4                       | gres/gpu=8                       |
| **gh-daily**         |  0-01:00:00   | 1-00:00:00 | Medium     | <u>merlin</u>  | gres/gpu=8                       | gres/gpu=8                       |
| **gh-hourly**        |  0-00:30:00   | 0-01:00:00 | High       | <u>merlin</u>  | gres/gpu=8                       | gres/gpu=8                       |
| **gh-interactive**   |  0-01:00:00   | 0-12:00:00 | Very High  | <u>merlin</u>  | cpu=16,gres/gpu=1,mem=46G,node=1 | cpu=16,gres/gpu=1,mem=46G,node=1 |

## CPU cluster: merlin7

**By default, jobs will be submitted to `merlin7`**, as it is the primary cluster configured on the login nodes.
Specifying the cluster name is typically unnecessary unless you have defined environment variables that could override the default cluster name.
However, when necessary, one can specify the cluster as follows:
```bash
#SBATCH --cluster=merlin7
```

### CPU general configuration

The **Merlin7 CPU cluster** is configured with the **`CR_CORE_MEMORY`** and **`CR_ONE_TASK_PER_CORE`** options.
* This configuration treats both cores and memory as consumable resources.
* Since the nodes are running with **hyper-threading** enabled, each core thread is counted as a CPU 
  to fulfill a job's resource requirements.

By default, Slurm will allocate one task per core, which means:
* Each task will consume 2 **CPUs**, regardless of whether both threads are actively used by the job.

This behavior ensures consistent resource allocation but may result in underutilization of hyper-threading in some cases.

### CPU nodes definition

The table below provides an overview of the Slurm configuration for the different node types in the Merlin7 cluster.
This information is essential for understanding how resources are allocated, enabling users to tailor their submission
scripts accordingly.

| Nodes                | Sockets  | CoresPerSocket  | Cores  | ThreadsPerCore   | CPUs  | MaxMemPerNode | DefMemPerCPU | Features      |
| --------------------:| -------: | --------------: | -----: | --------------:  | ----: | ------------: | -----------: | ------------: |
| login[001-002]       | 2        | 64              | 128    | 2                | 256   | 480G          | 1920M        | AMD_EPYC_7713 |
| cn[001-077]          | 2        | 64              | 128    | 2                | 256   | 480G          | 1920M        | AMD_EPYC_7713 |

Notes on memory configuration:
* **Memory allocation options:** To request additional memory, use the following options in your submission script:
   * **`--mem=<mem_in_MB>`**: Allocates memory per node.
   * **`--mem-per-cpu=<mem_in_MB>`**: Allocates memory per CPU (equivalent to a core thread).

  The total memory requested cannot exceed the **`MaxMemPerNode`** value.
* **Impact of disabling Hyper-Threading:** Using the **`--hint=nomultithread`** option disables one thread per core, 
effectively halving the number of available CPUs. Consequently, memory allocation will also be halved unless explicitly
adjusted.

  For MPI-based jobs, where performance generally improves with single-threaded CPUs, this option is recommended. 
  In such cases, you should double the **`--mem-per-cpu`** value to account for the reduced number of threads.

{{site.data.alerts.tip}}
Always verify the Slurm <b>'/var/spool/slurmd/conf-cache/slurm.conf'</b> configuration file for potential changes.
{{site.data.alerts.end}}

### User and job limits with QoS

In the `merlin7` CPU cluster, we enforce certain limits on jobs and users to ensure fair resource usage and prevent
overuse by a single user or job. These limits aim to balance resource availability while maintaining overall cluster
efficiency. However, applying limits can occasionally impact the cluster’s utilization. For example, user-specific 
limits may result in pending jobs even when many nodes are idle due to low activity.

On the other hand, these limits also enhance cluster efficiency by preventing scenarios such as a single job monopolizing
all available resources, which could block other jobs from running. Without job size limits, for instance, a large job 
might drain the entire cluster to satisfy its resource request, a situation that is generally undesirable.

Thus, setting appropriate limits is essential to maintain fair resource usage while optimizing cluster efficiency. These 
limits should allow for a mix of jobs of varying sizes and types, including single-core and parallel jobs, to coexist 
effectively.

To implement these limits, **we utilize Quality of Service (QoS)**. Different QoS policies are defined and applied 
**to specific partitions** in line with the established resource allocation policies. The table below outlines the 
various QoS definitions applicable to the merlin7 CPU-based cluster. Here:
* `MaxTRES` specifies resource limits per job.
* `MaxTRESPU` specifies resource limits per user.

|        Name     |            MaxTRES |          MaxTRESPU | Scope                  |
| --------------: | -----------------: | -----------------: | ---------------------: |
|      **normal** |                    |                    | partition              |
| **cpu_general** | cpu=1024,mem=1920G | cpu=1024,mem=1920G | <u>user</u>, partition |
|   **cpu_daily** | cpu=1024,mem=1920G | cpu=2048,mem=3840G | partition              |
|  **cpu_hourly** | cpu=2048,mem=3840G |   cpu=8192,mem=15T | partition              |

Where:
* **`normal` QoS:** This QoS has no limits and is typically applied to partitions that do not require user or job 
  restrictions.
* **`cpu_general` QoS:** This is the **default QoS** for `merlin7` _users_. It limits the total resources available to each
  user. Additionally, this QoS is applied to the `general` partition, enforcing restrictions at the partition level and
  overriding user-level QoS.
* **`cpu_daily` QoS:** Guarantees increased resources for the `daily` partition, accommodating shorter-duration jobs
  with higher resource needs.
* **`cpu_hourly` QoS:** Offers the least constraints, allowing more resources to be used for the `hourly` partition,
  which caters to very short-duration jobs.

For additional details, refer to the [CPU partitions](/merlin7/slurm-configuration.html#CPU-partitions) section.

{{site.data.alerts.tip}}
Always verify QoS definitions for potential changes using the  <b>'sacctmgr show qos format="Name%22,MaxTRESPU%35,MaxTRES%35"'</b> command.
{{site.data.alerts.end}}

### CPU partitions

This section provides a summary of the partitions available in the `merlin7` CPU cluster.

Key concepts:
* **`PriorityJobFactor`**: This value is added to a job’s priority (visible in the `PARTITION` column of the `sprio -l` command).
  Jobs submitted to partitions with higher `PriorityJobFactor` values generally run sooner. However, other factors like *job age*
  and especially *fair share* can also influence scheduling.
* **`PriorityTier`**: Jobs submitted to partitions with higher `PriorityTier` values take precedence over pending jobs in partitions
  with lower `PriorityTier` values. Additionally, jobs from higher `PriorityTier` partitions can preempt running jobs in lower-tier
  partitions, where applicable.
* **`QoS`**: Specifies the quality of service associated with a partition. It is used to control and restrict resource availability
  for specific partitions, ensuring that resource allocation aligns with intended usage policies. Detailed explanations of the various
  QoS settings can be found in the [User and job limits with QoS](/merlin7/slurm-configuration.html#user-and-job-limits-with-qos) section.

{{site.data.alerts.tip}}
Always verify partition configurations for potential changes using the  <b>'scontrol show partition'</b> command.
{{site.data.alerts.end}}

#### CPU public partitions

| PartitionName      |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS         | AllowAccounts  |
| -----------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | ----------: | -------------: |
| **<u>general</u>** |  1-00:00:00   | 7-00:00:00  | 50         | 1                 | 1            | cpu_general | <u>merlin</u>  |
| **daily**          |  0-01:00:00   | 1-00:00:00  | 62         | 500               | 1            | cpu_daily   | <u>merlin</u>  |
| **hourly**         |  0-00:30:00   | 0-01:00:00  | 77         | 1000              | 1            | cpu_hourly  | <u>merlin</u>  |

All Merlin users are part of the `merlin` account, which is used as the *default account* when submitting jobs.
Similarly, if no partition is specified, jobs are automatically submitted to the `general` partition by default.

{{site.data.alerts.tip}}
For jobs running less than one day, submit them to the <b>daily</b> partition.
For jobs running less than one hour, use the <b>hourly</b> partition.
These partitions provide higher priority and ensure quicker scheduling compared to <b>general</b>, which has limited node availability.
{{site.data.alerts.end}}

The **`hourly`** partition may include private nodes as an additional buffer. However, the current Slurm partition configuration, governed 
by **`PriorityTier`**, ensures that jobs submitted to private partitions are prioritized and processed first. As a result, access to the 
**`hourly`** partition might experience delays in such scenarios.

#### CPU private partitions

##### CAS / ASA

| PartitionName      |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS         | AllowAccounts  |
| -----------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | ----------: | -------------: |
| **asa**            |  0-01:00:00   | 14-00:00:00 | 10         | 1                 | 2            | normal      | asa            |

##### CNM / Mu3e

| PartitionName      |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS         | AllowAccounts  |
| -----------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | ----------: | -------------: |
| **mu3e**           |  1-00:00:00   | 7-00:00:00  | 4          | 1                 | 2            | normal      | mu3e, meg      |

##### CNM / MeG

| PartitionName      |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS         | AllowAccounts  |
| -----------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | ----------: | -------------: |
| **meg-short**      |  0-01:00:00   | 0-01:00:00  | unlimited | 1000               | 2            | normal      | meg            |
| **meg-long**       |  1-00:00:00   | 5-00:00:00  | unlimited | 1                  | 2            | normal      | meg            |
| **meg-prod**       |  1-00:00:00   | 5-00:00:00  | unlimited | 1000               | 4            | normal      | meg            |

## GPU cluster: gmerlin7

As mentioned in previous sections, by default, jobs will be submitted to `merlin7`, as it is the primary cluster configured on the login nodes.
For submittng jobs to the GPU cluster, **the cluster name `gmerlin7` must be specified**, as follows:
```bash
#SBATCH --cluster=gmerlin7
```

### GPU general configuration

The **Merlin7 GPU cluster** is configured with the **`CR_CORE_MEMORY`**, **`CR_ONE_TASK_PER_CORE`**, and **`ENFORCE_BINDING_GRES`** options.
* This configuration treats both cores and memory as consumable resources.
* Since the nodes are running with **hyper-threading** enabled, each core thread is counted as a CPU 
  to fulfill a job's resource requirements.
* Slurm will allocate the CPUs to the selected GPU.

By default, Slurm will allocate one task per core, which means:
* For hyper-threaded nodes (NVIDIA A100-based nodes), each task will consume 2 **CPUs**, regardless of whether both threads are actively used by the job.
* For the NVIDIA GraceHopper-based nodes, each task will consume 1 **CPU**.

This behavior ensures consistent resource allocation but may result in underutilization of hyper-threading in some cases.

### GPU nodes definition

The table below provides an overview of the Slurm configuration for the different node types in the Merlin7 cluster.
This information is essential for understanding how resources are allocated, enabling users to tailor their submission
scripts accordingly.

| Nodes                | Sockets  | CoresPerSocket  | Cores  | ThreadsPerCore  | CPUs  | MaxMemPerNode | DefMemPerCPU | Gres                        | Features               |
| --------------------:| -------: | --------------: | -----: | --------------: | ----: | ------------: | -----------: | --------------------------: | ---------------------: |
| gpu[001-007]         | 4        | 72              | 288    | 1               | 288   | 828G          | 2944M        | gpu:gh200:4                 | AMD_EPYC_7713, NV_A100 |
| gpu[101-105]         | 1        | 64              | 64     | 2               | 128   | 480G          | 3840M        | gpu:nvidia_a100-sxm4-80gb:4 | GH200, NV_H100         |

Notes on memory configuration:
* **Memory allocation options:** To request additional memory, use the following options in your submission script:
   * **`--mem=<mem_in_MB>`**: Allocates memory per node.
   * **`--mem-per-cpu=<mem_in_MB>`**: Allocates memory per CPU (equivalent to a core thread).

  The total memory requested cannot exceed the **`MaxMemPerNode`** value.
* **Impact of disabling Hyper-Threading:** Using the **`--hint=nomultithread`** option disables one thread per core, 
effectively halving the number of available CPUs. Consequently, memory allocation will also be halved unless explicitly
adjusted.

  For MPI-based jobs, where performance generally improves with single-threaded CPUs, this option is recommended. 
  In such cases, you should double the **`--mem-per-cpu`** value to account for the reduced number of threads.

{{site.data.alerts.tip}}
Always verify the Slurm <b>'/var/spool/slurmd/conf-cache/slurm.conf'</b> configuration file for potential changes.
{{site.data.alerts.end}}

### User and job limits with QoS

In the `gmerlin7` CPU cluster, we enforce certain limits on jobs and users to ensure fair resource usage and prevent
overuse by a single user or job. These limits aim to balance resource availability while maintaining overall cluster
efficiency. However, applying limits can occasionally impact the cluster’s utilization. For example, user-specific 
limits may result in pending jobs even when many nodes are idle due to low activity.

On the other hand, these limits also enhance cluster efficiency by preventing scenarios such as a single job monopolizing
all available resources, which could block other jobs from running. Without job size limits, for instance, a large job 
might drain the entire cluster to satisfy its resource request, a situation that is generally undesirable.

Thus, setting appropriate limits is essential to maintain fair resource usage while optimizing cluster efficiency. These 
limits should allow for a mix of jobs of varying sizes and types, including single-core and parallel jobs, to coexist 
effectively.

To implement these limits, **we utilize Quality of Service (QoS)**. Different QoS policies are defined and applied 
**to specific partitions** in line with the established resource allocation policies. The table below outlines the 
various QoS definitions applicable to the merlin7 CPU-based cluster. Here:
* `MaxTRES` specifies resource limits per job.
* `MaxTRESPU` specifies resource limits per user.

|        Name              |            MaxTRES               |          MaxTRESPU              | Scope                  |
| -----------------------: | -------------------------------: | ------------------------------: | ---------------------: |
|      **normal**          |                                  |                                 | partition              |
| **gpu_general**          | gres/gpu=4                       |                      gres/gpu=8 | <u>user</u>, partition |
|   **gpu_daily**          | gres/gpu=8                       |                      gres/gpu=8 | partition              |
|  **gpu_hourly**          | gres/gpu=8                       |                      gres/gpu=8 | partition              |
| **gpu_gh_interactive**   | cpu=16,gres/gpu=1,mem=46G,node=1 |cpu=16,gres/gpu=1,mem=46G,node=1 | partition              |
| **gpu_a100_interactive** | cpu=16,gres/gpu=1,mem=60G,node=1 |cpu=16,gres/gpu=1,mem=60G,node=1 | partition              |

Where:
* **`normal` QoS:** This QoS has no limits and is typically applied to partitions that do not require user or job 
  restrictions.
* **`gpu_general` QoS:** This is the **default QoS** for `gmerlin7` _users_. It limits the total resources available to each
  user. Additionally, this QoS is applied to the `[a100|gh]-general` partitions, enforcing restrictions at the partition level and
  overriding user-level QoS.
* **`gpu_daily` QoS:** Guarantees increased resources for the `[a100|gh]-daily` partitions, accommodating shorter-duration jobs
  with higher resource needs.
* **`gpu_hourly` QoS:** Offers the least constraints, allowing more resources to be used for the `[a100|gh]-hourly` partitions,
  which caters to very short-duration jobs.
* **`gpu_a100_interactive` & `gpu_gh_interactive` QoS:** Guarantee interactive access to GPU nodes for software compilation and
  small testing.

For additional details, refer to the [GPU partitions](/merlin7/slurm-configuration.html#GPU-partitions) section.

{{site.data.alerts.tip}}
Always verify QoS definitions for potential changes using the  <b>'sacctmgr show qos format="Name%22,MaxTRESPU%35,MaxTRES%35"'</b> command.
{{site.data.alerts.end}}

### GPU partitions

This section provides a summary of the partitions available in the `merlin7` CPU cluster.

Key concepts:
* **`PriorityJobFactor`**: This value is added to a job’s priority (visible in the `PARTITION` column of the `sprio -l` command).
  Jobs submitted to partitions with higher `PriorityJobFactor` values generally run sooner. However, other factors like *job age*
  and especially *fair share* can also influence scheduling.
* **`PriorityTier`**: Jobs submitted to partitions with higher `PriorityTier` values take precedence over pending jobs in partitions
  with lower `PriorityTier` values. Additionally, jobs from higher `PriorityTier` partitions can preempt running jobs in lower-tier
  partitions, where applicable.
* **`QoS`**: Specifies the quality of service associated with a partition. It is used to control and restrict resource availability
  for specific partitions, ensuring that resource allocation aligns with intended usage policies. Detailed explanations of the various
  QoS settings can be found in the [User and job limits with QoS](/merlin7/slurm-configuration.html#user-and-job-limits-with-qos) section.

{{site.data.alerts.tip}}
Always verify partition configurations for potential changes using the  <b>'scontrol show partition'</b> command.
{{site.data.alerts.end}}

#### A100-based partitions

| PartitionName        |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS                  | AllowAccounts  |
| -------------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | -------------------: | -------------: |
| **a100-general**     |  1-00:00:00   | 7-00:00:00  | 3          | 1                 | 1            | gpu_general          | <u>merlin</u>  |
| **a100-daily**       |  0-01:00:00   | 1-00:00:00  | 4          | 500               | 1            | gpu_daily            | <u>merlin</u>  |
| **a100-hourly**      |  0-00:30:00   | 0-01:00:00  | 5          | 1000              | 1            | gpu_hourly           | <u>merlin</u>  |
| **a100-interactive** |  0-01:00:00   | 0-12:00:00  | 5          | 1                 | 2            | gpu_a100_interactive | <u>merlin</u>  |

All Merlin users are part of the `merlin` account, which is used as the *default account* when submitting jobs.
Similarly, if no partition is specified, jobs are automatically submitted to the `general` partition by default.

{{site.data.alerts.tip}}
For jobs running less than one day, submit them to the <b>a100-daily</b> partition.
For jobs running less than one hour, use the <b>a100-hourly</b> partition.
These partitions provide higher priority and ensure quicker scheduling compared to <b>a100-general</b>, which has limited node availability.
{{site.data.alerts.end}}

#### GH-based partitions

| PartitionName        |  DefaultTime  | MaxTime     | TotalNodes | PriorityJobFactor | PriorityTier | QoS                  | AllowAccounts  |
| -------------------: |  -----------: | ----------: | --------:  | ----------------: | -----------: | -------------------: | -------------: |
| **gh-general**       |  1-00:00:00   | 7-00:00:00  | 5          | 1                 | 1            | gpu_general          | <u>merlin</u>  |
| **gh-daily**         |  0-01:00:00   | 1-00:00:00  | 6          | 500               | 1            | gpu_daily            | <u>merlin</u>  |
| **gh-hourly**        |  0-00:30:00   | 0-01:00:00  | 7          | 1000              | 1            | gpu_hourly           | <u>merlin</u>  |
| **gh-interactive**   |  0-01:00:00   | 0-12:00:00  | 7          | 1                 | 2            | gpu_gh_interactive   | <u>merlin</u>  |

All Merlin users are part of the `merlin` account, which is used as the *default account* when submitting jobs.
Similarly, if no partition is specified, jobs are automatically submitted to the `general` partition by default.

{{site.data.alerts.tip}}
For jobs running less than one day, submit them to the <b>gh-daily</b> partition.
For jobs running less than one hour, use the <b>gh-hourly</b> partition.
These partitions provide higher priority and ensure quicker scheduling compared to <b>gh-general</b>, which has limited node availability.
{{site.data.alerts.end}}
