BwUniCluster3.0/Batch Queues - Revision history

P Schuhmacher: /* Regular Queues */

2025-08-13T12:37:00Z

Regular Queues

← Older revision		Revision as of 14:37, 13 August 2025
Line 92:		Line 92:
	\| mem-per-gpu=127500mb<br/>cpus-per-gpu=16		\| mem-per-gpu=127500mb<br/>cpus-per-gpu=16
	\|		\|
	\| time=72:00:00, nodes=9(A100)/nodes=5(H100), mem=510000mb, ntasks-per-node=64, (threads-per-core=2)		\| time=48:00:00, nodes=9(A100)/nodes=5(H100), mem=510000mb, ntasks-per-node=64, (threads-per-core=2)
	\|}		\|}
	Table 1: Regular Queues		Table 1: Regular Queues

P Schuhmacher: /* Regular Queues */

2025-08-13T12:36:25Z

Regular Queues

← Older revision		Revision as of 14:36, 13 August 2025
Line 92:		Line 92:
	\| mem-per-gpu=127500mb<br/>cpus-per-gpu=16		\| mem-per-gpu=127500mb<br/>cpus-per-gpu=16
	\|		\|
	\| time=72:00:00, nodes=9, mem=510000mb, ntasks-per-node=64, (threads-per-core=2)		\| time=72:00:00, nodes=9(A100)/nodes=5(H100), mem=510000mb, ntasks-per-node=64, (threads-per-core=2)
	\|}		\|}
	Table 1: Regular Queues		Table 1: Regular Queues

P Schuhmacher: /* Interactive Jobs: salloc */

2025-03-31T07:10:53Z

Interactive Jobs: salloc

← Older revision		Revision as of 09:10, 31 March 2025
Line 156:		Line 156:

	<pre>		<pre>
	$ salloc -p ~~single~~ -n 1 -t 120 --mem=5000		$ salloc -p cpu -n 1 -t 120 --mem=5000
	</pre>		</pre>

Line 180:		Line 180:

	<pre>		<pre>
	$ salloc -p ~~multiple~~ -N 5 --ntasks-per-node=40 -t 01:00:00 --mem=50gb		$ salloc -p cpu -N 5 --ntasks-per-node=40 -t 01:00:00 --mem=50gb
	</pre>		</pre>

P Schuhmacher: /* Queue class examples */

2025-03-31T07:10:28Z

Queue class examples

← Older revision		Revision as of 09:10, 31 March 2025
Line 144:		Line 144:
	=== Queue class examples ===		=== Queue class examples ===

	To run your batch job on one of the ~~thin~~ nodes, please use:		To run your batch job on one of the cpu nodes, please use:

	<pre>		<pre>
	$ sbatch --partition=~~dev_multiple~~		$ sbatch --partition=dev_cpu
	or
	$ sbatch -p dev_multiple
	</pre>		</pre>
	<br>		<br>

S Braun at 16:33, 23 January 2025

2025-01-23T16:33:50Z

← Older revision		Revision as of 18:33, 23 January 2025
Line 1:		Line 1:
			{\|style="background:#FEF4AB; width:100%;"
	__TOC__
			\|style="padding:5px; background:#FEF4AB; text-align:left"\|
			This page is work in progress.
			\|}


	== Partitions, Queues and Jobs==		== Partitions, Queues and Jobs==

S Braun: /* Jobs */

2025-01-23T14:45:30Z

Jobs

← Older revision		Revision as of 16:45, 23 January 2025
Line 31:		Line 31:

	Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.		Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.
	Submitting a batch job means, that all steps of a compute project are defined in a ~~bash~~ script. This Bash script is queued and executed as soon as the compute resources are available and allocated. Jobs are enqueued with the ''sbatch'' command.		Submitting a batch job means, that all steps of a compute project are defined in a Bash script. This Bash script is queued and executed as soon as the compute resources are available and allocated. Jobs are enqueued with the ''sbatch'' command.

	For interactive jobs, the resources are requested with the ''salloc'' command. As soon as the computing resources are available and allocated, a command line prompt is returned on a computing node and the user can freely dispose of the resources now available to him.		For interactive jobs, the resources are requested with the ''salloc'' command. As soon as the computing resources are available and allocated, a command line prompt is returned on a computing node and the user can freely dispose of the resources now available to him.

S Braun: /* Jobs */

2025-01-23T14:45:19Z

Jobs

← Older revision		Revision as of 16:45, 23 January 2025
Line 31:		Line 31:

	Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.		Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.
	Submitting a batch job means, that all steps of a compute project are defined in a bash script. This ~~bash~~ script is queued and executed as soon as the compute resources are available and allocated. Jobs are enqueued with the ''sbatch'' command.		Submitting a batch job means, that all steps of a compute project are defined in a bash script. This Bash script is queued and executed as soon as the compute resources are available and allocated. Jobs are enqueued with the ''sbatch'' command.

	For interactive jobs, the resources are requested with the ''salloc'' command. As soon as the computing resources are available and allocated, a command line prompt is returned on a computing node and the user can freely dispose of the resources now available to him.		For interactive jobs, the resources are requested with the ''salloc'' command. As soon as the computing resources are available and allocated, a command line prompt is returned on a computing node and the user can freely dispose of the resources now available to him.

S Braun: /* Partitions, Queues and Jobs */

2025-01-23T14:43:54Z

Partitions, Queues and Jobs

← Older revision		Revision as of 16:43, 23 January 2025
Line 2:		Line 2:

	== Partitions, Queues and Jobs==		== Partitions, Queues and Jobs==

			=== Partitions ===
	Slurm manages job queues for different '''partitions'''. Partitions are used to group similar node types (e.g. nodes with and without accelerators) and to enforce different access policies and resource limits.		Slurm manages job queues for different '''partitions'''. Partitions are used to group similar node types (e.g. nodes with and without accelerators) and to enforce different access policies and resource limits.

Line 12:		Line 14:
	** 2-socket nodes with 4x NVIDIA A100 or 4x NVIDIA H100 GPUs		** 2-socket nodes with 4x NVIDIA A100 or 4x NVIDIA H100 GPUs
	** 4-socket node with 4x AMD Instinct accelerator		** 4-socket node with 4x AMD Instinct accelerator

			=== Queues ===

	Job '''queues''' are used to manage jobs that request access to shared but limited computing resources of a certain kind (partition).		Job '''queues''' are used to manage jobs that request access to shared but limited computing resources of a certain kind (partition).
Line 23:		Line 27:

	Requested compute resources such as (wall-)time, number of nodes and amount of memory are restricted and must fit into the boundaries imposed by the queues. The request for compute resources on the bwUniCluster 3.0 <font color=red>requires at least the specification of the '''queue''' and the '''time'''</font>.		Requested compute resources such as (wall-)time, number of nodes and amount of memory are restricted and must fit into the boundaries imposed by the queues. The request for compute resources on the bwUniCluster 3.0 <font color=red>requires at least the specification of the '''queue''' and the '''time'''</font>.

			=== Jobs ===

	Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.		Jobs can be run non-interactively as '''batch jobs''' or as '''interactive jobs'''.

S Braun at 14:41, 23 January 2025

2025-01-23T14:41:08Z

← Older revision		Revision as of 16:41, 23 January 2025
Line 17:		Line 17:
	On bwUniCluster 3.0 there are different main types of queues:		On bwUniCluster 3.0 there are different main types of queues:
	* Regular queues		* Regular queues
	** ~~single~~: Jobs that request at ~~most~~ ~~one~~ ~~node~~ or ~~even~~ ~~only~~ ~~single~~ ~~cores of a node~~.		** cpu: Jobs that request nodes without GPUs. Normal or very high memory capacity.
	** multiple: Jobs that request more than one node.
	** gpu: Jobs that request GPU accelerators on one or more than one node.		** gpu: Jobs that request GPU accelerators on one or more than one node.
	* Development queues (dev)		* Development queues (dev)
Line 34:		Line 33:
	\|style="padding:5px; background:#cef2e0; text-align:left"\|		\|style="padding:5px; background:#cef2e0; text-align:left"\|
	'''Please remember:'''		'''Please remember:'''
	* Heavy computations are not allowed on the login nodes.<br>Use a developement or a regular job queue instead! Please refer to [[BwUniCluster2.0/Login#Allowed_Activities_on_Login_Nodes\|Allowed Activities on Login Nodes]].		* '''Heavy computations are not allowed on the login nodes'''.<br>Use a developement or a regular job queue instead! Please refer to [[BwUniCluster2.0/Login#Allowed_Activities_on_Login_Nodes\|Allowed Activities on Login Nodes]].
	* Development queues are meant for development tasks.<br>Do not misuse this queue for regular, short-running jobs or chain jobs! Only one running job at a time is enabled.		* '''Development queues''' are meant for '''development tasks'''.<br>Do not misuse this queue for regular, short-running jobs or chain jobs! Only one running job at a time is enabled. Maximum queue length is reduced to 3.
	\|}		\|}

S Braun: /* Partitions, Queues and Jobs */

2025-01-23T14:32:47Z

Partitions, Queues and Jobs

← Older revision		Revision as of 16:32, 23 January 2025
Line 4:		Line 4:
	Slurm manages job queues for different '''partitions'''. Partitions are used to group similar node types (e.g. nodes with and without accelerators) and to enforce different access policies and resource limits.		Slurm manages job queues for different '''partitions'''. Partitions are used to group similar node types (e.g. nodes with and without accelerators) and to enforce different access policies and resource limits.

	On bwUniCluster 3.0 there different partitions:		On bwUniCluster 3.0 there are different partitions:

	* CPU-only nodes		* CPU-only nodes
Line 15:		Line 15:
	Job '''queues''' are used to manage jobs that request access to shared but limited computing resources of a certain kind (partition).		Job '''queues''' are used to manage jobs that request access to shared but limited computing resources of a certain kind (partition).

	On bwUniCluster 3.0 there different main types of queues:		On bwUniCluster 3.0 there are different main types of queues:
	* Regular queues		* Regular queues
	** single: Jobs that request at most one node or even only single cores of a node.		** single: Jobs that request at most one node or even only single cores of a node.