OpenHPC - Revision history

Pysdlb: /* Various parts of the software stack are seeing an upgrade: */ corrected a link

2022-11-10T11:00:21Z

‎Various parts of the software stack are seeing an upgrade:: corrected a link

Pysdlb at 10:59, 10 November 2022

2022-11-10T10:59:55Z

Chris.collins at 10:55, 10 November 2022

2022-11-10T10:55:01Z

Chris.collins: Chris.collins moved page Highlights to OpenHPC without leaving a redirect

2022-11-10T10:44:45Z

Chris.collins moved page Highlights to OpenHPC without leaving a redirect

Chris.collins: /* Job Emails */

2022-11-10T10:41:32Z

‎Job Emails

Chris.collins: /* Introduction */

2022-11-10T10:23:29Z

‎Introduction

Chris.collins: /* Introduction */

2022-01-11T09:14:43Z

‎Introduction

Chris.collins: /* Introduction */

2022-01-07T14:17:37Z

‎Introduction

Chris.collins: /* Using Containers */

2022-01-06T21:10:28Z

‎Using Containers

Chris.collins: /* Introduction */

2022-01-06T21:05:34Z

‎Introduction

@@ Line 15: / Line 15: @@
 === Various parts of the software stack are seeing an upgrade: ===
-* Operating System is being upgraded from CentOS 7.2 to CentOS 7.9. This is an important update to ensure maximum security and support but will also allow improved functionality (e.g. [[Highlights#Using_Containers|Using Containers]])
+* Operating System is being upgraded from CentOS 7.2 to CentOS 7.9. This is an important update to ensure maximum security and support but will also allow improved functionality (e.g. [[#Using Containers|Using Containers]])
 * Slurm is having a version upgrade to provide functionality, stability and security improvements
 * While the existing Viper application stack will remain available, going forward a new application stack will supplement and eventually replace many of the applications, tools and libraries with new optimised and more up to date versions.

@@ Line 1: / Line 1: @@
 __TOC__
 == Introduction ==
-As part of the Viper upgrade, we are introducing a range of hardware and software updates to refresh Viper and enhance functionality. This upgrade is based on a migration from the existing Operating Systems and software stack to a new build based on up to date Operating System and the OpenHPC software stack. More features and improvements will come when the stack is rolled out on to the production service, but some initial key details, highlights and changes are detailed below.
+As part of the Viper upgrade, we are introducing a range of hardware and software updates to refresh Viper and enhance functionality. This upgrade is based on a migration from the existing Operating Systems and software stack to a new build based on up to date Operating System and the OpenHPC software stack. More features and improvements will come when the stack is rolled out onto the production service, but some initial key details, highlights and changes are detailed below.
 === Familiar environment: ===
@@ Line 24: / Line 24: @@
 == Resource Requirements ==
-In order to reduce issues with tasks using more resource (CPU or RAM) than they should, Slurm will now uses Linux cgroups to more closely monitor resource use of tasks and will limit (CPU) or terminate (RAM) tasks exceeding what they should use. In particular this means it is important to request the correct amount of  RAM needed for a task.
+In order to reduce issues with tasks using more resource (CPU or RAM) than they should, Slurm will now use Linux cgroups to more closely monitor resource use of tasks and will limit (CPU) or terminate (RAM) tasks exceeding what they should use. In particular, this means it is important to request the correct amount of  RAM needed for a task.
 {| class="wikitable"
@@ Line 57: / Line 57: @@
 * ALL (equivalent to BEGIN, END, FAIL, INVALID_DEPEND, REQUEUE, and STAGE_OUT)
 * INVALID_DEPEND (dependency never satisfied)
-* TIME_LIMIT, TIME_LIMIT_90 (reached 90 percent of time limit), TIME_LIMIT_80 (reached 80 percent of time limit), TIME_LIMIT_50 (reached 50 percent of time limit) * ARRAY_TASKS (sends emails for each array task otherwise job BEGIN, END and FAIL apply to a job array as a whole rather than generating individual email messages for each task in the job array).
+* TIME_LIMIT, TIME_LIMIT_90 (reached 90 per cent of the time limit), TIME_LIMIT_80 (reached 80 per cent of the time limit), TIME_LIMIT_50 (reached 50 per cent of the time limit) * ARRAY_TASKS (sends emails for each array task otherwise job BEGIN, END and FAIL apply to a job array as a whole rather than generating individual email messages for each task in the job array).
 The user to be notified is indicated with --mail-user, however '''only @hull.ac.uk email addresses are valid.'''
-If you want to be alerted when your task completes, if it advised to use '''#SBATCH --mail-type=END,FAIL''' to catch if a job finishes cleanly or if it finishes due to an error.
+If you want to be alerted when your task completes, it is advised to use '''#SBATCH --mail-type=END,FAIL''' to catch if a job finishes cleanly or if it finishes due to an error.
 An example of a completion email is shown below:
@@ Line 91: / Line 91: @@
 Viper now supports the use of Containers, via Apptainer (previously called [https://www.linuxfoundation.org/press-release/new-linux-foundation-project-accelerates-collaboration-on-container-systems-between-enterprise-and-high-performance-computing-environments/ Singularity]).
-Containers can be built to contain everything needed to run an application or code, independent of the Operating System. This means application/code, libraries, scripts or even data. This makes them ideal for reproducible science as experiment and data can be distributed as a single file. Generally there is a negligible if any performance impact when running containers over bare metal. Containers are becoming an increasingly popular way of distributing applications and workflows.
+Containers can be built to contain everything needed to run an application or code, independent of the Operating System. This means application/code, libraries, scripts or even data. This makes them ideal for reproducible science as experiments and data can be distributed as a single file. Generally, there is a negligible if any performance impact when running containers over bare metal. Containers are becoming an increasingly popular way of distributing applications and workflows.
-Docker is perhaps the most well known form of containers, but Docker has security implications that mean it isn’t suitable for a shared user environment like HPC. Apptainer doesn't have the same security issues, indeed "''[Singularity] is optimized for compute focused enterprise and HPC workloads, allowing untrusted users to run untrusted containers in a trusted way''”. However, containers are built from a recipe files which include all the required components to support the workflow, and the recipe file can be based off an existing Docker container, allowing many existing Docker containers to be used with Singularity.
+Docker is perhaps the most well known form of containers, but Docker has security implications that mean it isn’t suitable for a shared user environment like HPC. Apptainer doesn't have the same security issues, indeed "''[Singularity] is optimized for compute focused enterprise and HPC workloads, allowing untrusted users to run untrusted containers in a trusted way''”. However, containers are built from a recipe files which include all the required components to support the workflow, and the recipe file can be based on an existing Docker container, allowing many existing Docker containers to be used with Singularity.
 <pre style="background-color: black; color: white; border: 2px solid black; font-family: monospace, sans-serif;">
@@ Line 122: / Line 122: @@
 |-
 | mono MaxQuant/bin/MaxQuantCmd.exe mqpar.xml
-| Run the command, in this case the command is mono, with the dotnet application MaxQuantCmd.exe and with experiment configuration file mqpar.xml
+| Run the command, in this case, the command is mono, with the dotnet application MaxQuantCmd.exe and with experiment configuration file mqpar.xml
 |}
 While most existing workflows are expected to work as usual or with minimal modifications following the upgrade from CentOS 7.2 to CentOS 7.9, we are aiming to provide an Apptainer container based on Viper's previous CentOS 7.2 compute node image, which should provide a platform for any workflows that do display issues.

@@ Line 1: / Line 1: @@
 __TOC__
-= Introduction =
+== Introduction ==
-As part of the Viper upgrade, we are introducing a range of hardware and software updates to refresh Viper and
+As part of the Viper upgrade, we are introducing a range of hardware and software updates to refresh Viper and enhance functionality. This upgrade is based on a migration from the existing Operating Systems and software stack to a new build based on up to date Operating System and the OpenHPC software stack. More features and improvements will come when the stack is rolled out on to the production service, but some initial key details, highlights and changes are detailed below.
-Key hardware updates:
+=== Familiar environment: ===
 * Introduction of ten new compute nodes, each with 56 cores and 384GB of RAM. This will become part of a new queue of enhanced compute nodes available in addition to the standard compute nodes.
 * New NVidia A40 GPU card in each of the GPU nodes. The upgraded GPU node offers more than double the single precision performance and the same GPU memory and number of CUDA cores in a single card as the existing GPU node did with 4x K40M cards in place, yet being a single card is a simpler platform to make use of all the resource. The new cards are also considerably more energy efficient.
-Various parts of the software stack are seeing an upgrade:
+=== Various parts of the software stack are seeing an upgrade: ===
 * Operating System is being upgraded from CentOS 7.2 to CentOS 7.9. This is an important update to ensure maximum security and support but will also allow improved functionality (e.g. [[Highlights#Using_Containers|Using Containers]])
@@ Line 14: / Line 19: @@
 * While the existing Viper application stack will remain available, going forward a new application stack will supplement and eventually replace many of the applications, tools and libraries with new optimised and more up to date versions.
 * Updated and improved cluster management stack, allowing us to provide more efficient and responsive updates and support.
 == Resource Requirements ==

@@ Line 51: / Line 51: @@
 * TIME_LIMIT, TIME_LIMIT_90 (reached 90 percent of time limit), TIME_LIMIT_80 (reached 80 percent of time limit), TIME_LIMIT_50 (reached 50 percent of time limit) * ARRAY_TASKS (sends emails for each array task otherwise job BEGIN, END and FAIL apply to a job array as a whole rather than generating individual email messages for each task in the job array).
-The user to be notified is indicated with --mail-user, however only @hull.ac.uk email addresses are valid.
+The user to be notified is indicated with --mail-user, however '''only @hull.ac.uk email addresses are valid.'''
 If you want to be alerted when your task completes, if it advised to use '''#SBATCH --mail-type=END,FAIL''' to catch if a job finishes cleanly or if it finishes due to an error.

@@ Line 6: / Line 6: @@
 * Introduction of ten new compute nodes, each with 56 cores and 384GB of RAM. This will become part of a new queue of enhanced compute nodes available in addition to the standard compute nodes.
-* New NVidia A40 GPU card, replacing one of the existing GPU nodes. The upgraded GPU node offers more than double the single precision performance and the same GPU memory and number of CUDA cores in a single card as the existing GPU node did with 4x K40M cards in place, yet being a single card is a simpler platform to make use of all the resource.
+* New NVidia A40 GPU card in each of the GPU nodes. The upgraded GPU node offers more than double the single precision performance and the same GPU memory and number of CUDA cores in a single card as the existing GPU node did with 4x K40M cards in place, yet being a single card is a simpler platform to make use of all the resource. The new cards are also considerably more energy efficient.
 Various parts of the software stack are seeing an upgrade:

← Older revision	Revision as of 10:44, 10 November 2022
(No difference)

← Older revision		Revision as of 21:10, 6 January 2022
Line 107:		Line 107:
	\| Run the command, in this case the command is mono, with the dotnet application MaxQuantCmd.exe and with experiment configuration file mqpar.xml		\| Run the command, in this case the command is mono, with the dotnet application MaxQuantCmd.exe and with experiment configuration file mqpar.xml
	\|}		\|}
		+
		+	While most existing workflows are expected to work as usual or with minimal modifications following the upgrade from CentOS 7.2 to CentOS 7.9, we are aiming to provide an Apptainer container based on Viper's previous CentOS 7.2 compute node image, which should provide a platform for any workflows that do display issues.

@@ Line 3: / Line 3: @@
 As part of the Viper upgrade, various parts of the software stack are seeing an upgrade:
-* Operating System is being upgraded, which will provide improvements in terms of security but will also allow improved functionality (e.g. [[Highlights#Using_Containers]]
+* Operating System is being upgraded, which will provide improvements in terms of security but will also allow improved functionality (e.g. [[Highlights#Using_Containers|Using Containers]])
 * Slurm is having a version upgrade to provide functionality, stability and security improvements