Rechenressourcen

Partitionen und deren Laufzeit-Grenzen

Zur Vereinfachung und zur Vermeidung von Fehlern gibt es eine weitgehende Automatik für die Auswahl der richtigen Slurm-Partition.

^{Ausgenommen hiervon sind lediglich einige Spezialfälle wie beispielsweise Lehrveranstaltungen (Kurse). In diesen Fällen werden Sie gesondert darüber informiert, wie Partition, Reservierung oder Projekt-Account in Jobscripts angegeben werden müssen.}

Je nach angegebener maximaler Laufzeit (-t oder --time=) werden Jobs in unterschiedliche Partitionen verteilt. Partitionen für Jobs längerer Laufzeit haben weniger Ressourcen (Rechenknoten), und darum kann die Wartezeit solcher Jobs länger sein.

Job runtime requirement ^{(-t / --time=…)}	Partition Name		Nodes assigned
Job runtime requirement ^{(-t / --time=…)}	MPI	Accelerators
≦ 30'	`deflt_short`		1206 ^{all + 7 exclusive}
≦ 30'		`acc_short`	13 ^{all accelerator nodes}
> 30' ≦ 24h	`deflt`		1199 ^{7 less than all}
	`mem`		5
		`acc`	13 ^{all accelerator nodes}
> 24h ≦ 7d	`long`		607
	`mem_long`		2
		`acc_long`	9 ^{4 less than all accelerator nodes}
_{Jobs with a continuous runtime longer than 7d are only possible after coordination with the HPC team and with the use of a special reservation. However, there is a trick for using non-continuous runtime > 7d .}

Konfiguration der Batchjobs für unterschiedliche Hardware

Standardmäßig werden Jobs auf dem gesamten Cluster und somit auf allen Arten von Knoten aller Phasen (Ausbaustufen) ausgeführt.

Damit Ihr Job auf einer bestimmten oder speziellen Hardware (-Ausstattung) bzw. Knotentyp zur Ausführung kommt, müssen Sie spezielle Ressourcen anfordern – wir unterscheiden grundsätzlich nach Prozessor-Typ und nach Beschleuniger-Typ , aber auch nach Ausbaustufen oder Sektionen, wie in der nachfolgenden Tabelle aufgeführt.

Alle anderen Eigenschaften Ihrer Jobs wie Laufzeit und Speicherverbrauch werden automatisch so ausgewertet, dass die Jobs auf die passenden Knoten-Typen bzw. Sektionen des Clusters verteilt werden.

Expansion Stage / CPU Type
Resource	Section	Node Hostnames	Details
i01	all	`mpsc` `mpqc` `gvqc` `gaqc` `gaoc`	LB 2 phase I
i02	all	`mpsd` `mpqd` `mpzd` `ghqd` `gpqd` `gaod`	LB 2 phase II
avx512	MPI	`mpsc` `mpsd`	MPI section, LB 2 phase I+II
	ACC	`gvqc` `gaqc` `ghqd`	ACC section, LB 2 phase I+II
	MEM	`mpqc` `mpqd` `mpzd`	MEM section, LB 2 phase I+II
avx2 (or dgx)	ACC	`gaoc`	ACC section, LB 2 phase I, DGX A100
_______________________________________________
Accelerator Type ^{(selected by „Generic Resources“ instead of by „constraint/feature“)}
GRes	Accelerator	Node Hostnames	Details
--gres=gpu	Nvidia (all)	`gvqc` `gaqc` `ghqd`	ACC section (all)
--gres=gpu:v100	Nvidia Volta 100	`gvqc`	ACC section, LB 2 phase I
--gres=gpu:a100	Nvidia Ampere 100	`gaqc`	ACC section, LB 2 phase I
--gres=gpu:h100	Nvidia Hopper 100	`ghqd`	ACC section, LB 2 phase II
--gres=gpu:pvc128g	Intel Data Center GPU Max 1550 „Ponte Vecchio“	`gpqd`	ACC section, LB 2 phase II *still experimental*
_______________________________________________
Sections
Resource	Section Name	Node Hostnames	Details
mpi	MPI	`mpsc`	MPI section (all)
mpi	MPI	`mpsd`	MPI section (all)
mem1536g	MEM	`mpqc`	MEM section, LB 2 phase I
mem2048g		`mpqd`	MEM section, LB 2 phase II
mem6144g		`mpzd`	MEM section, LB 2 phase II

All diese speziellen „Features“ (außer Beschleuniger/GPUs) können mit der Option -C (für „constraint“) angefordert und ausgewählt werden.

Entweder gibt man die Option direkt auf der Kommandozeile an: „sbatch -C ressource meinJobScript“ (nicht empfohlen), oder im Batch/Job-Script als weiteres Pragma (empfohlen):

#SBATCH -C ressource

Mehrere Feature-Anforderungen können über ein & (logisches UND) bzw. ein | (logisches ODER) verknüpft werden (siehe Beispiele weiter unten).

GPU-Beschleuniger jedoch werden nicht mehr einfach nur per „feature“, sondern mittels GRes angefordert:

--gres=Klasse:Typ:# Beschleuniger-Anforderung, z.B. GPUs
(wenn nicht angegeben: Typ=any und #=1)

--gres=gpu
^{fordert 1 GPU beliebigen Typs an (nicht empfohlen – könnte sowohl Nvidia als auch PVC sein!)}
--gres=gpu:v100
^{fordert 1 NVidia „Volta 100“-Karte an}
--gres=gpu:a100:3
^{fordert 3 NVidia „Ampere 100“-Karten an}
--gres=gpu:pvc128g:2
^{fordert 2 Intel „Ponte Vecchio“-Karten mit je 128 GByte G-RAM an (Infos zur Nutzung der PVC (wird in neuem Tab geöffnet)
)}

^{Um Ihre Job-Scripts nicht immer für wechselnde Anzahlen an GPUs doppelt umschreiben zu müssen, können Sie überall dort, wo Ihre Programme die Zahl der zu nutzenden GPUs erwarten, die Variable $SLURM_GPUS_ON_NODE verwenden.
Beispiel: „myCUDAprogram --num-devices=$SLURM_GPUS_ON_NODE“.}

Wenn Sie für verteiltes Machine/Deep Learning mehrere GPU-Nodes benötigen (z.B. mit „horovod“), müssen Sie mit -N # (und dann -n >=#) explizit mehrere Nodes anfordern (wobei # = 2-8 gilt).
Da „GRes“ immer pro Node gelten, darf --gres=gpu:4 nur im Fall der DGX (8 GPUs) überschritten werden, selbst wenn mehrere 4-GPU-Knoten angefordert werden.

Beispiele

-C avx512

Fordert Knoten mit „Advanced Vector Extension (512 Bit)“-Architektur an.

-C "avx512&mem1536g"

Fordert Knoten mit AVX512-Architektur UND 1.5 TByte RAM an.

-C avx512
--gres=gpu:v100:2

Fordert Knoten mit AVX512-Architektur und 2 GPUs vom Typ „Volta 100“ an.

Partitionen und deren Laufzeit-Grenzen

Konfiguration der Batchjobs für unterschiedliche Hardware

Beschleuniger (GPUs) über GRes

Beispiele