HPC

General/Modules

From HPC
Revision as of 11:45, 7 February 2017 by Chris.collins (talk | contribs) (→‎Module command)

Jump to: navigation , search

Introduction

Viper uses a module environment to provide access to applications, tools and libraries. Modules allow us to provide multiple versions of applications and libraries without causing conflicts. By loading a module, your environment is configured to allow you to use your chosen application by setting required paths and environment variables. Modules can be loaded and unloaded dynamically, giving you full control over your working environment.

Module command

The following commands allow you to find out what modules are available on Viper, find out more information about them and control which modules you load.

module avail

To see a full list of applications and libraries that are available to use on Viper, you should run module avail as shown below (with just some of the hundreds of modules that are available): 

[username@login01 ~]$ module avail

------------------------------ /usr/share/Modules/modulefiles ------------------------------
dot         module-git  module-info modules     null        use.own

------------------------------ /trinity/clustervision/CentOS/7/modulefiles ------------------------------
abyss/1.5.2/gcc-4.9.3                   idl/8.4                                 openhu/3.1.0
anaconda/4.0                            insighttoolkit/4.4.2                    openmpi/1.10.5/gcc-5.2.0
ansys/v170                              intel/2016                              openmpi/1.10.5/gcc-6.3.0
ansys/v172                              intel/2017                              openmpi/1.10.5/intel-2017

If you want to use a specific application, you can find which versions are available by running module avail modulename, e.g.: 

[username@login01 ~]$ module avail gcc

------------------------------ /trinity/clustervision/CentOS/7/modulefiles ------------------------------
gcc/4.9.3(default) gcc/5.2.0          gcc/6.3.0          gcc/legacy

In this case the (default) indicates that gcc/4.9.3 is the default GCC module.

module show

To find out what a module file does, run module show modulename. This will show you brief information about what the module will do (this information is being updated for existing modules to show more relevant information), along with how the module will update your environment: 

[username@login01 ~]$ module show abyss/1.5.2/gcc-4.9.3
-------------------------------------------------------------------
/trinity/clustervision/CentOS/7/modulefiles/abyss/1.5.2/gcc-4.9.3:

module-whatis    ABySS is a de novo sequence assembler intended for short paired-end reads and large genomes
prepend-path     PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/bin
prepend-path     LD_LIBRARY_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/lib
prepend-path     C_INCLUDE_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/include
prepend-path     PKG_CONFIG_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/lib/pkgconfig
-------------------------------------------------------------------

module load

To load a module you use module load modulename. In most cases, running this command will not display anything and will just return you back to the Linux command prompt. 

[username@login01 ~]$ module load gcc

If you want to load a specific version of a module then you should include the version number, for example: 

[username@login01 ~]$ module load gcc/5.2.0

Without putting a version in, you will either load the highest alphanumeric version, or the default if one is set Note: module load and module add are the same

module list

To see what modules you have loaded, run module list 

[username@login01 ~]$ module list
Currently Loaded Modulefiles:
  1) gcc/4.9.3

module delete

To remove a loaded module and all environment configurations that module has set, run module delete modulename. Running this command will not display anything and will just return you back to the Linux command prompt

Note: module delete, module unload, module del and module rm are the same

module purge

To remove all loaded modules and return your environment to are vanilla state, run module purge. Running this command will not display anything and will just return you back to the Linux command prompt

module whatis

To find out what modules are available with information about what each application does, run module whatis, for example (selected output): 

[username@login01 ~]$ module whatis
STAR/2016-10-27      : Spliced Transcripts Alignment to a Reference
abyss/1.5.2/gcc-4.9.3: ABySS is a de novo sequence assembler intended for short paired-end reads and large genomes
crop/1.33/gcc-6.3.0  : Crop clustering approach to find common taxonomic units in large datasets
discovardenovo/52488 : DISCOVAR de novo – large genome assembler
expat/gcc/2.2.0      : Expat XML parser
ssw/2016-08-08       : SSW (NASA SolarSoft)
test-modules         : Adds modules under development to your module avail list

Note: This information is currently being updated for existing modules.

Modulefiles

Modulefile actions

Typically modulefiles instruct the module command to alter or set shell environment variables such as paths and flags. 

[username@login01 ~]$ module show abyss/1.5.2/gcc-4.9.3
-------------------------------------------------------------------
/trinity/clustervision/CentOS/7/modulefiles/abyss/1.5.2/gcc-4.9.3:

module-whatis    ABySS is a de novo sequence assembler intended for short paired-end reads and large genomes
prepend-path     PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/bin
prepend-path     LD_LIBRARY_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/lib
prepend-path     C_INCLUDE_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/include
prepend-path     PKG_CONFIG_PATH /trinity/clustervision/CentOS/7/apps/abyss/1.5.2/gcc-4.9.3/lib/pkgconfig
-------------------------------------------------------------------

Other common options set in a modulefile include:

  • Paths such as LIBRARY_PATH, CPATH, LD_RUN_PATH
  • Compiler flags such as CFLAGS, CPPFLAGS, FCFLAGS and LDFLAGS
  • Manual page location via the MANPATH
  • Other modules to load to meet dependencies
  • Any conflicting modules that can't be loaded together
  • License file locations, for example for Intel Compiler

Modulefile naming convention

Most modulefiles take the form applicationname/version, for example gcc/4.9.3 for the Gnu Compiler Collection version 4.9.3. There are also other versions of GCC, for example gcc/5.2.0 and gcc/6.3.0. A similar example is matlab/2016a

However, due to the specific combinations of some of the tools required to build certain applications which may be relevant to those using the application, a new naming convention is being introduced. These modulefiles will take the form application/version/ followed by information about the compiler module used to build the application (and possibly the version of MPI), for example:

  • openmpi/1.10.5/gcc-5.2.0
  • openmpi/1.10.5/gcc-6.3.0
  • openmpi/1.10.5/intel-2017
  • openblas/0.2.19/gcc-4.9.3


If a piece of software doesn't have a specific version number, for example when retrieved from github, then the version will often be replaced by the date the application was built, for example sparsehash/2016-12-21/gcc-4.9.3

Test modulefiles

While applications are being installed and tested, they may be put in a test area and not directly available to users. This is to stop people using modules which may not be correctly configured or are subject to change while we are testing the installations. To see the modules that are in testing you need to run module load test-modules before running module avail

Retrieved from ‘http://hpc.mediawiki.hull.ac.uk/index.php?title=General/Modules&oldid=560’