Memory Policy

GRAVITON manages memory allocation automatically based on the selected QOS and the resulting partition. Users are not allowed to manually specify memory using directives like --mem or --mem-per-cpu. Instead, memory is assigned implicitly according to a predefined policy:

Default Memory Allocation

  • Serial Partition (QOS: s6h, s24h):

    • 3.8 GB per core

  • Parallel Partition (QOS: mpi):

    • 4.3 GB per core

This means that, for example, a job requesting 20 cores with --qos=s6h will receive approximately 76 GB of total memory.

Important

Although it may seem advantageous to submit jobs under the mpi QoS — since it assigns more memory per core (4.3 GB instead of 3.8 GB) — this QoS automatically routes your job to the parallel partition.

However, nodes somcosmoXX, which are significantly more powerful than the standard grwnXX nodes, are not included in the parallel partition.

In contrast, all other QoS options (s6h, s24h) send jobs to the serial partition, which prioritizes somcosmoXX for job allocation.

Therefore, using mpi automatically exclude your job from accessing the most performant nodes available in GRAVITON.

Requesting Double Memory

If your job requires double the default memory per core, you can request it by adding the following constraint to your job script:

#SBATCH --constraint=double_mem

This constraint applies to both partitions, and will result in:

  • 7.6 GB per core in the serial partition

  • 8.6 GB per core in the parallel partition

Important Notes

  • There is no need to manually request memory with --mem or similar options — doing so will result in job rejection.

  • Use the double_mem constraint only when justified, as it reduces node availability and may delay your job.

  • You can use the grstatus command to inspect memory allocation across nodes.