Nexus - Revision history

Mbaney at 18:04, 30 April 2026

2026-04-30T18:04:52Z

← Older revision		Revision as of 18:04, 30 April 2026
Line 4:		Line 4:

	= Getting Started =		= Getting Started =
	All accounts in UMIACS are sponsored. If you don't already have a UMIACS account, please see [[Accounts]] for information on getting one. You need a full UMIACS account (not a [[Accounts/Collaborator \| collaborator account]]) in order to access Nexus.		All accounts in UMIACS are sponsored. If you don't already have a UMIACS account, please see [[Accounts]] for information on getting one. You need a full UMIACS account - not a [[Accounts/Collaborator \| collaborator account]] - in order to access Nexus.

	== Access ==		== Access ==
	Your access to submission nodes (alternatively called login nodes) for Nexus computational resources is determined by your account sponsor's department, center, or lab affiliation. You can log into the [https://intranet.umiacs.umd.edu/directory/cr/ UMIACS Directory CR application] and select the Computational Resource (CR) in the list that has the prefix <code>nexus</code>. The Hosts section lists your available submission nodes - generally a pair of nodes of the format <tt>nexus<department, lab, or center abbreviation>[00,01]</tt>, e.g., <tt>nexusgroup00</tt> and <tt>nexusgroup01</tt>.		Your access to submission nodes (alternatively called login nodes) for Nexus computational resources is determined by your account sponsor's department, center, or lab affiliation. You can log into the [https://intranet.umiacs.umd.edu/directory/cr/ UMIACS Directory CR application] and select the Computational Resource (CR) in the list that has the prefix <code>nexus</code>. The Hosts section lists your available submission nodes - generally a pair of nodes with hostnames of the format <tt>nexus<department, lab, or center abbreviation>[00,01]</tt>, e.g., <tt>nexusgroup00</tt> and <tt>nexusgroup01</tt>.

	Once you have identified your submission nodes, you can [[SSH]] into them [https://itsupport.umd.edu/itsupport?id=kb_article_view&sysparm_article=KB0016076 after connecting to UMD's GlobalProtect VPN]. From there, you are able to submit to the cluster via our [[SLURM]] workload manager. You need to make sure that your submitted jobs have the correct account, partition, and qos.		Once you have identified your submission nodes, you can [[SSH]] into them [https://itsupport.umd.edu/itsupport?id=kb_article_view&sysparm_article=KB0016076 after connecting to UMD's GlobalProtect VPN]. From there, you are able to submit to the cluster via our [[SLURM]] workload manager. You need to make sure that your submitted jobs have the correct account, partition, and qos.

Mbaney at 17:23, 27 April 2026

2026-04-27T17:23:45Z

← Older revision		Revision as of 17:23, 27 April 2026
Line 1:		Line 1:
	{{Note\|UMIACS Technical Staff will begin the process of upgrading the operating system version on all Nexus cluster nodes ~~beginning~~ in Summer 2026. Please see [[Nexus/ClusterOSUpgrade]] for more information.}}		{{Note\|UMIACS Technical Staff will begin the process of upgrading the operating system version on all Nexus cluster nodes in Summer 2026. Please see [[Nexus/ClusterOSUpgrade]] for more information.}}

	The Nexus is the combined scheduler of resources in UMIACS. The resource manager for Nexus is [[SLURM]]. Resources are arranged into partitions where users are able to schedule computational jobs. Users are arranged into a number of SLURM accounts based on faculty, lab, or center investments.		The Nexus is the combined scheduler of resources in UMIACS. The resource manager for Nexus is [[SLURM]]. Resources are arranged into partitions where users are able to schedule computational jobs. Users are arranged into a number of SLURM accounts based on faculty, lab, or center investments.

Mbaney at 17:05, 27 April 2026

2026-04-27T17:05:35Z

← Older revision		Revision as of 17:05, 27 April 2026
Line 1:		Line 1:
			{{Note\|UMIACS Technical Staff will begin the process of upgrading the operating system version on all Nexus cluster nodes beginning in Summer 2026. Please see [[Nexus/ClusterOSUpgrade]] for more information.}}

	The Nexus is the combined scheduler of resources in UMIACS. The resource manager for Nexus is [[SLURM]]. Resources are arranged into partitions where users are able to schedule computational jobs. Users are arranged into a number of SLURM accounts based on faculty, lab, or center investments.		The Nexus is the combined scheduler of resources in UMIACS. The resource manager for Nexus is [[SLURM]]. Resources are arranged into partitions where users are able to schedule computational jobs. Users are arranged into a number of SLURM accounts based on faculty, lab, or center investments.

Seide: /* Access */ Link to "Nexus/Submission Node Policy"

2026-03-05T21:24:29Z

Access: Link to "Nexus/Submission Node Policy"

← Older revision		Revision as of 21:24, 5 March 2026
Line 8:		Line 8:

	Once you have identified your submission nodes, you can [[SSH]] into them [https://itsupport.umd.edu/itsupport?id=kb_article_view&sysparm_article=KB0016076 after connecting to UMD's GlobalProtect VPN]. From there, you are able to submit to the cluster via our [[SLURM]] workload manager. You need to make sure that your submitted jobs have the correct account, partition, and qos.		Once you have identified your submission nodes, you can [[SSH]] into them [https://itsupport.umd.edu/itsupport?id=kb_article_view&sysparm_article=KB0016076 after connecting to UMD's GlobalProtect VPN]. From there, you are able to submit to the cluster via our [[SLURM]] workload manager. You need to make sure that your submitted jobs have the correct account, partition, and qos.

			Please read our [[Nexus/Submission_Node_Policy\|Submission Node Policy]] for guidance on appropriate usage of a submission node. If a submission node becomes unresponsive due to disregarding this policy, <b>we may kill user processes on these nodes to resolve the issue</b>. We reserve the right to take action on users who repeatedly cause issues on submission nodes.

	== Jobs ==		== Jobs ==

Mbaney at 19:36, 20 February 2026

2026-02-20T19:36:39Z

← Older revision		Revision as of 19:36, 20 February 2026
Line 86:		Line 86:
	</pre>		</pre>

	If you want to see information for all of the partitions, you can use the <code>show_partitions --all</code> command.		If you want to see information for all of the partitions, including those that you do not have access to, you can use the <code>show_partitions --all</code> command.

	<pre>		<pre>
Line 193:		Line 193:
	</pre>		</pre>

	If you want to see all partition QoS, including those that you do not have access to, you can use the <code>~~-a/~~--all</code> ~~argument~~.		If you want to see all partition QoS, including those that you do not have access to, you can use the <code>show_partition_qos --all</code> command.

	<pre>		<pre>
	$ show_partition_qos -a		$ show_partition_qos --all
	Name MaxSubmitPU MaxTRESPU GrpTRES		Name MaxSubmitPU MaxTRESPU GrpTRES
	------------------------- ----------- -------------------------------- --------------------		------------------------- ----------- -------------------------------- --------------------

Mbaney: /* Job QoS */

2026-02-20T19:34:23Z

Job QoS

← Older revision		Revision as of 19:34, 20 February 2026
Line 116:		Line 116:
	* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.		* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.
	* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.		* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.
	* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% ~~of all~~ of the resources in the partition ~~are~~ permitted simultaneously across all of your jobs running with this job QoS, enforced via the corresponding partition QoS (below) for the scavenger partition. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.		* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of the total resources available for each trackable resource type in the partition (CPUs/GPUs/RAM) is permitted simultaneously across all of your jobs running with this job QoS, enforced via the corresponding partition QoS (below) for the scavenger partition. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.
	* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.		* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.

Mbaney: /* Partitions */

2026-01-13T19:36:36Z

Partitions

← Older revision		Revision as of 19:36, 13 January 2026
Line 49:		Line 49:

	'''Partitions usable by [[ClassAccounts]]:'''		'''Partitions usable by [[ClassAccounts]]:'''
	* [[ClassAccounts \| Class]] - Pool of resources available to class accounts sponsored by either UMIACS or CSD faculty.		* [[ClassAccounts#Cluster_Usage \| Class]] - Pool of resources available to class accounts sponsored by either UMIACS or CSD faculty.

	'''Partitions usable by specific lab/center users:'''		'''Partitions usable by specific lab/center users:'''

Mbaney: /* Partition QoS */

2026-01-07T15:57:31Z

Partition QoS

← Older revision		Revision as of 15:57, 7 January 2026
Line 246:		Line 246:
	while [[ "$(sbatch example_inner.sh 2>&1)" =~ "QOSMaxSubmitJobPerUserLimit" ]]		while [[ "$(sbatch example_inner.sh 2>&1)" =~ "QOSMaxSubmitJobPerUserLimit" ]]
	do		do
	echo "Currently at maximum job submissions allowed."		echo "Currently at maximum job submissions allowed for this QoS."
	echo "Waiting for 5 minutes before trying to submit more jobs."		echo "Waiting for 5 minutes before trying to submit more jobs."
	sleep 300		sleep 300

Mbaney: /* Quality of Service (QoS) */

2026-01-07T15:55:59Z

Quality of Service (QoS)

← Older revision		Revision as of 15:55, 7 January 2026
Line 116:		Line 116:
	* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.		* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.
	* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.		* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.
	* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of all of the resources in the partition are permitted simultaneously across all of your jobs running with this job QoS. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.		* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of all of the resources in the partition are permitted simultaneously across all of your jobs running with this job QoS, enforced via the corresponding partition QoS (below) for the scavenger partition. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.
	* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.		* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.

Mbaney: /* Job QoS */

2026-01-07T15:54:44Z

Job QoS

← Older revision		Revision as of 15:54, 7 January 2026
Line 116:		Line 116:
	* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.		* medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.
	* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.		* high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.
	* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of all of the resources in the partition are permitted simultaneously across all of your jobs running with this job QoS. This job QoS is paired 1-1 with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.		* scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of all of the resources in the partition are permitted simultaneously across all of your jobs running with this job QoS. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include <code>--partition=scavenger</code> and <code>--account=scavenger</code> in your submission arguments. Do not include any job QoS argument other than <code>--qos=scavenger</code> (optional) or submission will fail.
	* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired 1-1 with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.		* scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include <code>--partition=scavenger-aarch64</code>, <code>--account=scavenger</code>, and <code>--qos=scavenger-aarch64</code> in your submission arguments.

	You can display these job QoS from the command line using the <code>show_qos</code> command. By default, the command will only show job QoS that you can access. The above five job QoS are the ones that everyone can access.		You can display these job QoS from the command line using the <code>show_qos</code> command. By default, the command will only show job QoS that you can access. The above five job QoS are the ones that everyone can access.