Third-Party Software

Installing Your Own Software

Individuals and research groups may install third party applications and libraries for their own use in the following locations:

  • $HOME
  • /usr/local/unsupported

Packages built for personal use only should be installed in $HOME.

The /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 PATH, MANPATH, and 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 PYTHONPATH or PERL5LIB), while others simply load a suite of other modules.

Common module commands

Command Result
module avail list all available modules
module avail pkg list all available modules beginning with the string pkg
module load pkg load a module named pkg
module swap old new attempt to replace loaded module named old with one named new
module unload pkg unload a module named pkg
module list list all currently-loaded modules
module purge unload all modules
module show pkg summarize environment changes made by module named pkg (sometimes incomplete)

Searching for modules

Because 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:

  • compiler/GCC/version
  • devel/CMake/version
  • math/GMP/version

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 devel/CMake/version.

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

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.

Toolchain Name Version Comprises
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) 11.3.3.210




MPI Libraries

RCS defaults to compiling software against OpenMPI.

Name Version Compiled by Notes
Intel GCC
MPICH2 1.5
MVAPICH2 2.1
MVAPICH2-PSM 2.1
OpenMPI 1.10.2 Included in pic-intel, pic-foss compiler toolchains
OpenMPI 1.6.5
OpenMPI 1.7.5
OpenMPI 1.8.8




Maintained Software Installations

As of 2016-10-19.

Name Version Compiled by Notes
Intel GCC
Anaconda 2 4.0.0
Anaconda 3 2.5.0
Autoconf 2.69
Automake 1.15
Autotools 20150215
BamTools 2.4.0
BayeScan 2.1
BCFtools 1.3.1
binutils 2.26 Included in pic-foss compiler toolchain
Bison 3.0.4
Boost 1.61.0
BWA 0.7.15
bzip2 1.0.6
cairo 1.14.6
CMake 3.5.2
cURL 7.49.1
Doxygen 1.8.11
ESMF 7.0.0
expat 2.2.0
FASTX-Toolkit 0.0.14
FFTW 3.3.4 Included in pic-foss compiler toolchain
flex 2.6.0
fontconfig 2.12.1
freetype 2.6.5
g2clib 1.4.0
g2lib 1.4.0
GCC 5.4.0 Included in pic-foss compiler toolchain
GDAL 2.1.0
gettext 0.19.8
GLib 2.49.5
GMP 6.1.1
GSL 2.1
gzip 1.6
HDF 4.2.11
HDF5 1.8.17
HTSlib 1.3.1
icc 2016.3.210 Included in pic-intel compiler toolchain
idl 8.4.1
ifort 2016.3.210 Included in pic-intel compiler toolchain
imkl 11.3.3.210 Included in pic-intel compiler toolchain
JasPer 1.900.1
libffi 3.2.1
libgtextutils 0.7
libjpeg-turbo 1.5.0
libpng 1.6.24
libreadline 6.3
libtool 2.4.6
libxml2 2.9.4
M4 1.4.17
makedepend 1.0.5
MATLAB R2015a
MATLAB R2015b
MATLAB R2016a
Mothur 1.38.1.1
NASM 2.12.02
NCL 6.3.0 Binary distribution
ncurses 6.0
netCDF 4.4.1
netCDF-C++4 4.3.0
netCDF-Fortran 4.4.4
OpenBLAS 0.2.18 Included in pic-foss compiler toolchain
PCRE 8.39
Perl 5.22.1
pixman 0.34.0
pkg-config 0.29.1
Python 2.7.12
Rosetta 3.8
SAMtools 1.3.1
ScaLAPACK 2.0.2 Included in pic-foss compiler toolchain
Singularity 2.2
SQLite 3.13.0
Szip 2.1
Tcl 8.6.5
Tk 8.6.5
UDUNITS 2.2.20
VCFtools 0.1.14
X11 20160819
XZ 5.2.2
zlib 1.2.8




Software requests

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:

  • RPM
  • 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.