Submission Evaluation Logic (Lua-based)

This section outlines the internal logic used in GRAVITON to validate and configure submitted jobs. A custom Lua script is integrated into SLURM’s job submission pipeline, enforcing site policies such as partition selection, memory allocation, and input validation.

This system ensures that all jobs conform to the resource management model of GRAVITON and provides a predictable, fair scheduling environment for all users.

Key Rules Enforced

  • Only users with a valid Accounting group (SOM, COM, or EXT) are allowed to submit jobs.

  • The following SBATCH directives are not allowed and will result in rejection:

    • --partition

    • --nodes

    • --mem

    • --mem-per-cpu

  • Partition assignment is automatic, based on the selected QoS:

    • --qos=lattice → assigned to the parallel partition

    • Any other valid QoS → assigned to the serial partition

  • Memory per core is assigned automatically according to the partition:

    • serial partition: 3.8 GB per core

    • parallel partition: 4.3 GB per core

  • If the job includes --constraint=double_mem, memory per core is doubled accordingly.

Important

Although it may seem advantageous to submit jobs under the lattice 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 somcosmo01 and somcosmo02, which are significantly more powerful than the standard grwn[01-21] nodes, are not included in the parallel partition.

In contrast, all other QoS options (hep, cosmo, std) send jobs to the serial partition, which prioritizes somcosmo01 and somcosmo02 for job allocation.

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

Job Submission Flow Diagram

        graph TD
  A[Job submitted]
  B{Accounting group?}
  B1[Prio = 10]
  B2[Prio = 10]
  B3[Prio = 2]
  C{Past Member?}
  D{--mem? <br> --partition? <br> --nodes?}
  H{QoS?}
  I[Assign partition = parallel]
  J[Assign partition = serial]
  K1[Mem = 4.3 GB x CPU]
  K2[Mem = 3.8 GB  x CPU]
  L{--constraint=double_mem?}
  M[Mem = Mem x 2]
  N[Job accepted ✔]

  A --> B
  B -->|SOM| B1 --> C
  B -->|COM| B2 --> C
  B -->|EXT| B3 --> C
  B -->|NO| Z1[Reject ❌]
  C -- Yes --> Z2[Reject ❌]
  C -- No --> D
  D -- Yes --> Z2[Reject ❌]
  D -- No --> H
  H --> |lattice| I --> K1 --> L
  H --> |hep| J
  H --> |cosmo| J
  H --> |std| J
  J --> K2 --> L
  L -- Yes --> M --> N
  L -- No --> N

The diagram below illustrates the complete decision process that SLURM applies to submitted jobs via Lua scripting.