Skip to content

Software on BlueBEAR

This page provides an overview of the options for accessing and using software on BlueBEAR.

BEAR Applications modules

The primary method for accessing software on BlueBEAR is by using our centrally installed BEAR Applications modules.
The website lists all the applications, along with their respective versions, that are available on BlueBEAR. These applications are grouped into BEAR Application Versions (e.g. 2022a) that are built with the same versions of standard libraries and are therefore compatible with each other.

Requesting new or updated software

Where the application/version that you wish to run isn’t available you can request the installation of software on BlueBEAR by submitting a Request New BEAR Software ticket. The Research Software Group will then make the application available centrally (which allows all users to use it) and will ensure that it is suitably optimised for BEAR’s facilities.


Some software may only be available via containers. On BlueBEAR we provide Apptainer, which enables the running of Apptainer, Singularity, and Docker containers.

Self-installing Software for BlueBEAR


Please be aware that self-installed software may not function in BEAR Portal and may therefore be restricted running in batch jobs or interactive jobs.

There are situations where users would prefer to self-install, for example where the code is under active development by the user or another developer.
We provide specific documentation for self-installing:

Implications of Node Type Differences on Building Software

Heterogeneous HPCs

BlueBEAR is a heterogeneous HPC system. This means that it is made-up from a variety of different node types.
This presents challenges when compiling and installing software.

The applications maintained by the Research Software Group make node-differences transparent to the user by ensuring that when an application module is loaded it provides the correct binary-executable(s) for the given node type.
If you are installing software yourself then you will need to manage this process manually and if your installation doesn’t distinguish between these node types then you may run into issues.
For example, if you install a package on an older CPU node, it will work on the newer CPUs but with suboptimal performance, i.e. it won’t be able to take advantage of the node’s newer CPU features.
In contrast, if you build an application on a newer CPU node, then try to run it on a older CPU node then it may work or may generate an error and fail. Error messages resulting from these compilation issues will likely be convoluted but often include the phrase Illegal Instruction.