#986 Adjust CPU and memory limits for cm4_std partition Pull request opened by amitfenn # Flux Resource Discovery Issue with SLURM on LRZ CM4 ## Summary When running Nextflow with Flux executor under SLURM allocations on LRZ CM4, Flux discovers only half the allocated CPUs due to hwloc reporting physical cores while SLURM allocates logical CPUs (hyperthreads). ## Environment • System: LRZ CM4 cluster • Nextflow: 24.10.0 • Executor: Flux • SLURM Partitions: cm4_tiny, cm4_std • Node Configuration: 56 physical cores × 2 hyperthreads = 112 logical CPUs per node ## Issue Details Observed Behavior:

SLURM allocation: 18 CPUs (--cpus-per-task=18)
Flux resource list: 9 cores available
Result: Tasks requesting >9 CPUs fail

Root Cause: Flux uses hwloc for resource discovery, which honors SLURM's cpuset binding and discovers physical cores only. SLURM's

--cpus-per-task

allocates logical CPUs (including hyperthreads), creating a 2:1 mismatch. ## Test Results # SLURM Environment SLURM_CPUS_ON_NODE: 18 SLURM_JOB_PARTITION: cm4_tiny # Flux Resource View flux resource list: STATE NNODES NCORES NODELIST free 1 9 cm4r15c01s05 # Nextflow Process Results Process with cpus=4: ✅ Success Process with cpus=16: ❌ Failed (exceeds Flux limit) ## Temp Solution for Nextflow Configs Adjust

resourceLimits

to account for the hyperthread→physical core conversion: cpus: System.getenv("SLURM_JOB_PARTITION") == 'cm4_std' ? 112 * System.getenv('SLURM_NNODES').toInteger() / 2 : (System.getenv("SLURM_CPUS_ON_NODE") ? System.getenv("SLURM_CPUS_ON_NODE").toInteger() / 2 : 64), Explanation: • cm4_std: 112 logical CPUs per node → 56 physical cores per node • cm4_tiny: Uses

SLURM_CPUS_ON_NODE

/ 2 for shared allocations • Default fallback: 32 physical cores ## Possible Alternative Solutions 1. Investigate SLURM binding: Check if

--hint=nomultithread

affects Flux's hwloc discovery 2. Flux hwloc configuration: May require custom topology XML (not tested) nf-core/configs