38,760
edits
Standard software environments/en: Difference between revisions
Updating to match new version of source page
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
| Line 3: | Line 3: | ||
For questions about migration to different standard environments, please see [[Migration to the new standard environment]]. | For questions about migration to different standard environments, please see [[Migration to the new standard environment]]. | ||
= What are standard software environments? = | == What are standard software environments? == | ||
Our software environments are provided through a set of [[Utiliser_des_modules/en|modules]] which allow you to switch between different versions of software packages. These modules are organized in a tree structure with the trunk made up of typical utilities provided by any Linux environment. Branches are compiler versions and sub-branches are versions of MPI or CUDA. | Our software environments are provided through a set of [[Utiliser_des_modules/en|modules]] which allow you to switch between different versions of software packages. These modules are organized in a tree structure with the trunk made up of typical utilities provided by any Linux environment. Branches are compiler versions and sub-branches are versions of MPI or CUDA. | ||
| Line 14: | Line 14: | ||
In general, new versions of software packages will get installed with the newest software environment. | In general, new versions of software packages will get installed with the newest software environment. | ||
== <code>StdEnv/2023</code> == | === <code>StdEnv/2023</code> === | ||
This is the most recent iteration of our software environment. It uses GCC 12.3.0, Intel 2023.1, and Open MPI 4.1.5 as defaults. | This is the most recent iteration of our software environment. It uses GCC 12.3.0, Intel 2023.1, and Open MPI 4.1.5 as defaults. | ||
| Line 20: | Line 20: | ||
{{Command|module load StdEnv/2023}} | {{Command|module load StdEnv/2023}} | ||
=== Performance improvements === | ==== Performance improvements ==== | ||
The minimum CPU instruction set supported by this environment is AVX2, or more generally, <tt>x86-64-v3</tt>. Even the compatibility layer which provides basic Linux commands is compiled with optimisations for this instruction set. | The minimum CPU instruction set supported by this environment is AVX2, or more generally, <tt>x86-64-v3</tt>. Even the compatibility layer which provides basic Linux commands is compiled with optimisations for this instruction set. | ||
=== Changes of default modules === | ==== Changes of default modules ==== | ||
GCC becomes the default compiler, instead of Intel. We compile with Intel only software which have been known to offer better performance using Intel. CUDA becomes an add-on to OpenMPI, rather than the other way around, i.e. CUDA-aware MPI is loaded at run time if CUDA is loaded. This allows to share a lot of MPI libraries across CUDA and non-CUDA branches. | GCC becomes the default compiler, instead of Intel. We compile with Intel only software which have been known to offer better performance using Intel. CUDA becomes an add-on to OpenMPI, rather than the other way around, i.e. CUDA-aware MPI is loaded at run time if CUDA is loaded. This allows to share a lot of MPI libraries across CUDA and non-CUDA branches. | ||
| Line 33: | Line 33: | ||
* CUDA 11 => CUDA 12 | * CUDA 11 => CUDA 12 | ||
== <code>StdEnv/2020</code> == | === <code>StdEnv/2020</code> === | ||
This is the most recent iteration of our software environment with the most changes so far. It uses GCC 9.3.0, Intel 2020.1, and Open MPI 4.0.3 as defaults. | This is the most recent iteration of our software environment with the most changes so far. It uses GCC 9.3.0, Intel 2020.1, and Open MPI 4.0.3 as defaults. | ||
| Line 39: | Line 39: | ||
{{Command|module load StdEnv/2020}} | {{Command|module load StdEnv/2020}} | ||
=== Performance improvements === | ==== Performance improvements ==== | ||
Binaries compiled with the Intel compiler now automatically support both AVX2 and AVX512 instruction sets. In technical terms, we call them ''multi-architecture binaries'', also known as [https://en.wikipedia.org/wiki/Fat_binary fat binaries]. This means that when running on a cluster such as Cedar and Graham which has multiple generations of processors, you don't have to manually load one of the <tt>arch</tt> modules if you use software packages generated by the Intel compiler. | Binaries compiled with the Intel compiler now automatically support both AVX2 and AVX512 instruction sets. In technical terms, we call them ''multi-architecture binaries'', also known as [https://en.wikipedia.org/wiki/Fat_binary fat binaries]. This means that when running on a cluster such as Cedar and Graham which has multiple generations of processors, you don't have to manually load one of the <tt>arch</tt> modules if you use software packages generated by the Intel compiler. | ||
| Line 46: | Line 46: | ||
We also installed a more recent version of the [https://en.wikipedia.org/wiki/GNU_C_Library GNU C Library], which introduces optimizations in some mathematical functions. This has increased the requirement on the version of the Linux Kernel (see below). | We also installed a more recent version of the [https://en.wikipedia.org/wiki/GNU_C_Library GNU C Library], which introduces optimizations in some mathematical functions. This has increased the requirement on the version of the Linux Kernel (see below). | ||
=== Change in the compatibility layer === | ==== Change in the compatibility layer ==== | ||
Another enhancement for the 2020 release was a change in tools for our compatibility layer. The compatibility layer is between the operating system and all other software packages. This layer is designed to ensure that compilers and scientific applications will work whether they run on CentOS, Ubuntu, or Fedora. For the 2016.4 and 2018.3 versions, we used the [https://en.wikipedia.org/wiki/Nix_package_manager Nix package manager], while for the 2020 version, we used [https://wiki.gentoo.org/wiki/Project:Prefix Gentoo Prefix]. | Another enhancement for the 2020 release was a change in tools for our compatibility layer. The compatibility layer is between the operating system and all other software packages. This layer is designed to ensure that compilers and scientific applications will work whether they run on CentOS, Ubuntu, or Fedora. For the 2016.4 and 2018.3 versions, we used the [https://en.wikipedia.org/wiki/Nix_package_manager Nix package manager], while for the 2020 version, we used [https://wiki.gentoo.org/wiki/Project:Prefix Gentoo Prefix]. | ||
=== Change in kernel requirement === | ==== Change in kernel requirement ==== | ||
Versions 2016.4 and 2018.3 required a Linux kernel version 2.6.32 or more recent. This supported CentOS versions starting at CentOS 6. With the 2020 version, we require a Linux kernel 3.10 or better. This means it no longer supports CentOS 6, but requires CentOS 7 instead. Other distributions usually have kernels which are much more recent, so you probably don't need to change your distribution if you are using this standard environment on something other than CentOS. | Versions 2016.4 and 2018.3 required a Linux kernel version 2.6.32 or more recent. This supported CentOS versions starting at CentOS 6. With the 2020 version, we require a Linux kernel 3.10 or better. This means it no longer supports CentOS 6, but requires CentOS 7 instead. Other distributions usually have kernels which are much more recent, so you probably don't need to change your distribution if you are using this standard environment on something other than CentOS. | ||
=== Module extensions === | ==== Module extensions ==== | ||
With the 2020 environment, we started installing more Python extensions inside of their corresponding core modules. For example, we installed <tt>PyQt5</tt> inside of the <tt>qt/5.12.8</tt> module so that it supports multiple versions of Python. The module system has also been adjusted so you can find such extensions. For example, if you run | With the 2020 environment, we started installing more Python extensions inside of their corresponding core modules. For example, we installed <tt>PyQt5</tt> inside of the <tt>qt/5.12.8</tt> module so that it supports multiple versions of Python. The module system has also been adjusted so you can find such extensions. For example, if you run | ||
{{Command|module spider pyqt5}} | {{Command|module spider pyqt5}} | ||
it will tell you that you can get this by loading the <tt>qt/5.12.8</tt> module. | it will tell you that you can get this by loading the <tt>qt/5.12.8</tt> module. | ||
== <code>StdEnv/2018.3</code> == | === <code>StdEnv/2018.3</code> === | ||
{{Template:Warning | {{Template:Warning | ||
|title=Deprecated | |title=Deprecated | ||
| Line 66: | Line 66: | ||
{{Command|module load StdEnv/2018.3}} | {{Command|module load StdEnv/2018.3}} | ||
== <code>StdEnv/2016.4</code> == | === <code>StdEnv/2016.4</code> === | ||
{{Template:Warning | {{Template:Warning | ||
|title=Deprecated | |title=Deprecated | ||