You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

All HPC facilities, worldwide, provide software in a very different way to personal and corporate computing platforms.  JCU HPC uses environment modules to deliver multiple versions of software to researchers using our multi-user HPC cluster.  This approach is widely used for the following reasons:

  • Most operating systems weren't written to deal with having multiple versions of the same software available.  Even in cases where multiple versions are installed, e.g., java, it is left to a system administrator to set the version which everyone will use.
  • Using environment modules, Individual users or groups can determine which version of software they wish to use.
  • Loading of modules with version information maximizes your chance of being able reproduce your results upon demand.
  • In the corporate world, system administrators have to configure a default version of piece of software (e.g., java) that everyone will use.
  • Using environment modules also improves performance by reducing the length of your search path (executable of interest found sooner).  It  also reduces the chance of you having to deal with application name conflicts.

In 2021, HPC staff commenced a major project to replace all existing software (including conda environments) with containerized versions of the same software and/or environments.  The container delivery platform being using is Apptainer (singularity) which mirrors the approach that all other HPC facilities are using or moving toward using.  The move to containerized HPC is being driven by a requirement for all research to be done in a reproducible way.

For security reasons, all software installed as part of the OS must be kept up to date.

  • This has potential to impact your computational research results.
  • Most researchers would be unaware of the behind the scenes changes or what impacts they might have had.
  • It would be nigh on impossible for me to recreate the state of HPC cluster software at any nominated point in time.

Software installed using the traditional, compile from source, method comes with serious risks.

results in a software environment with a potentially very large number of unknown dependencies, again making it very difficult to reproduce at a later time.

This page house a "cheat sheet" style glance at some environment modules functionality.  You will need to replace any occurrence of <software-name> and/or <version> below with an appropriate name/value.

To list all available software

module avail

To list all versions of a given piece of software

module avail <software-name>

To display a brief summary for a given piece of software

module help <software-name>

To list environment modules that have already loaded

module list

To load the default version of a piece of software

module load <software-name>

The default version of a piece of software will usually be a safe (rather than latest) version.

To load a specific version of a piece of software

module load <software-name>/<software-version>

HPC staff recommend this approach as default versions may change with time.

To switch to another version of the same piece of software

module switch <software-name>/<software-version>

To list changes that would be (or have been) made to your environment from loading a specific module

module show <software-name>/<software-version>

To unload a module you have loaded

module unload <software-name>

Specification of a version shouldn't be required here.

To unload all of your currently loaded module

module purge

Information specific to JCU HPC configuration

Most module files, when loaded, will set an environment variable <SOFTWARE>_HOME which holds the installation home for the software.  For example, try

module load vcftools

The most common environment variable modified by the loading of an environment variable is PATH.  This has been done for convenience.

  • No labels