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: .. code-block:: bash #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.