Installing Your Own Software
Individuals and research groups may install third party applications and libraries for their own use in the following locations:
Packages built for personal use only should be installed in $HOME.
/usr/local/unsupported directory is intended to host user-installed and maintained software packages and datasets that are shared with a group of users on the system. Users who add content to
/usr/local/unsupported are fully responsible for the maintenance of the files and software versions. Please read the
/usr/local/unsupported/README.RCS file for more information.
To request a new subdirectory within
/usr/local/unsupported, please contact RCS with the following information:
- The name of the requested subdirectory, which can be your project's name (e.g., UAFCLMIT) or the type of software you intend to install in the directory (e.g., "ClimateModels")
- A general description of what you intend to install
- A rough estimate of the amount of storage you will need (e.g., 100 MB)
Using The Software Stack
Chinook already has builds of many third-party software packages (see below for a listing). There are often multiple builds of a particular software package - different versions, different compilers used to build the software, different compile-time flags, et cetera. To avoid conflicts between these many disparate package builds, Chinook employs an environment module system you can use to load and unload different combinations of software packages into your environment.
What are Environment Modules?
The environment modules found on Chinook (often referred to simply as "modules") are Tcl script files that are used to update shell environment variables such as
LD_LIBRARY_PATH. These variables allow your shell to discover the particular application or library as specified by the module. Some environment modules set additional variables (such as
PERL5LIB), while others simply load a suite of other modules.
Common module commands
||list all available modules|
||list all available modules beginning with the string pkg|
||load a module named pkg|
||attempt to replace loaded module named old with one named new|
||unload a module named pkg|
||list all currently-loaded modules|
||unload all modules|
||summarize environment changes made by module named pkg (sometimes incomplete)|
Searching for modules
module avail will search for the provided string only at the beginning of a module's fully-qualified name, it can be difficult to use
module avail to search for modules nested in any kind of hierarchy. This is the case on Chinook - modules are categorized, then named. Here are some examples:
To find modules for GCC using a pure
module avail command, you would need to run
module avail compiler/GCC. This is difficult, because you must already know that the module is in the compiler category.
To make things more complicated,
module avail is also case-sensitive. Running
module avail devel/cmake will not find the module named
Better module searching
One workaround for these impediments is to combine
module avail output with
grep's full-text case-insensitive string matching ability. The example below additionally uses Bash file descriptor redirection syntax to redirect stderr to stdout because
module avail outputs to stderr.
module avail --terse 2>&1 | grep -i pkg
replacing pkg with the string you are searching for.
RCS is currently evaluating Lmod as a replacement for Chinook's current environment modules framework. Lmod has many desirable features, including but not limited to a more user-friendly
module avail behavior.
For more information on Chinook's module framework, please visit http://modules.sourceforge.net/index.html.
Compiler toolchains are modules that bundle together a set of compiler, MPI, and numerical library modules. To use a compiler toolchain, load the compiler toolchain module and all the submodules will be loaded. This will set variables such as PATH, CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, and others. Other variable conventions such as CC and CXX are not automatically defined.
Since Chinook is an Intel-based HPC cluster, RCS defaults to compiling software using Intel-based compiler toolchains.
|foss||2016b||GNU Compiler Collection 5.4.0, Penguin-modified OpenMPI 1.10.2, OpenBLAS 0.2.18, FFTW 3.3.4, ScaLAPACK 2.0.2|
|pic-intel||2016b||Intel Compiler Collection 2016.3.210 (2016 update 3), Penguin-modified OpenMPI 1.10.6, Intel Math Kernel Library (MKL) 18.104.22.168|
RCS defaults to compiling software against OpenMPI.
|MPICH2||1.5||✓||✓||Provided by Scyld ClusterWare|
|MVAPICH2||2.2||✓||✓||Provided by Scyld ClusterWare|
|MVAPICH2-PSM||2.2||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||1.10.3||✓||✓||Included in pic-intel, pic-foss compiler toolchains|
|OpenMPI||1.6.5||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||1.7.5||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||1.8.8||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||1.10.7||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||2.0.3||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||2.1.2||✓||✓||Provided by Scyld ClusterWare|
|OpenMPI||3.0.0||✓||✓||Provided by Scyld ClusterWare|
Maintained Software Installations
As of 2016-10-19.
|binutils||2.26||✓||Included in pic-foss compiler toolchain|
|CUDA||9.1.85||Includes nvcc compiler|
|FFTW||3.3.4||✓||Included in pic-foss compiler toolchain|
|GCC||5.4.0||Included in pic-foss compiler toolchain|
|icc||2016.3.210||Included in pic-intel compiler toolchain|
|ifort||2016.3.210||Included in pic-intel compiler toolchain|
|imkl||22.214.171.124||✓||Included in pic-intel compiler toolchain|
|OpenBLAS||0.2.18||✓||Included in pic-foss compiler toolchain|
|ScaLAPACK||2.0.2||✓||Included in pic-foss compiler toolchain|
RCS evaluates third-party software installation requests for widely-used HPC software on a case-by-case basis. Some factors that affect request eligibility are:
- Applicability to multiple research groups
- Complexity of the installation process
- Software licensing
If a third-party software installation request is found to be a viable candidate for installation, RCS may elect to install the software through one of several means:
- Binary (pre-built) distribution
- Source build
If an application or library is available through standard RPM repositories (Penguin Computing, CentOS, EPEL, ...) then the RPM may be installed. Users should test the installed software to determine if it meets requirements. If the RPM version does not meet needs, please contact RCS to have alternate installation methods evaluated.
Software that is not installed as an RPM will be installed in a publicly-available location and be accessible via Linux environment modules. If the software is built from source, then RCS will default to using the Intel compiler suite.