Software on HPC

The HPC system has to serve many different users - in addition to being comprised of different kinds/sizes of nodes, it also has the capability to provide access to different software. There are two major ways to use software on the HPC system:

  1. Using the modules system
  2. Using contianers

The first option is the more traditional route. It allows the user to configure their environment to make certain software and libraries available, including R and some selected R packages. Subsequently, things like R packages can often (but not always) be installed in the usual way with install.packages.

The second option adds an additional layer of abstraction/complexity, but also provides enhanced flexibility. Containerization is a good technology to be familiar with in general, since it has become widespread across many industries.

Before we jump into containers, let’s focus on the more traditional approach.

Working with Modules

The Basics

There are many programs and libraries already pre-installed on the HPC systems. The HPC system uses modules to manage different versions of these applications, which might have different dependencies – potentially, this can become complicated, although for most people this will be pretty straightforward.

These modules are organized into dependency groups called “stacks”. At the time of this writing (2026-07-12), the most recent stack is stack/2022.2. You can load this stack via

module load stack/2022.2

Likely, you will also want to load R. At the time of this writing, the most recent version installed on argon is 4.2.2, which can be loaded via:

module load r/4.2.2_gcc-9.5.0

If you don’t want to load these modules every single time you log in to argon, you can save this configuration as your default via

module save

There are a few other module commands worth being aware of:

You can also have multiple configurations stored, if you wish. For example, suppose you occasionally do something that requires extra software to be loaded. You could load those modules, then

Note that if you leave off the name, module save and module restore overwrite and load the default configuration that you have set up.

To see what modules are available in your current software stack, use the command module avail. For example:

module avail ^r-

To see what modules are available across all software stacks, use module spider, which has the same syntax. Like many command line tools, the output of module spider can be searched by using the / key, followed by the string you want to search for. You can jump between matches with the n key.

Alternatively, you can look here at this argon software list to see a list of all the programs installed on the HPC.

Your R profile

Since you’ll likely be using R on Argon, and will likely have to install packages, it’s worth mentioning how to set up a local directory in which to install them (otherwise, R will ask you questions about it every time you run install.packages()).

You can put these R packages anywhere you want, although the “standard” place to put them would be in .local/lib. So, let’s make a subdirectory there for our R packages:

mkdir -p .local/lib/R

And then tell R to use that as your local library by adding this to your .Rprofile file (you may have to create this file first):

.libPaths("~/.local/lib/R")
options(repos = c(CRAN = "https://mirror.las.iastate.edu/CRAN"))

The second line is optional, but will stop R from asking you about what mirror you want to use every time you install a package.

Your profile

This is optional, but to customize your HPC setup, it is often the case that you would like to run certain commands at the beginning of every Argon session. There are two profile files to know about, both located in your home directory:

On Argon, .bash_profile sources .bashrc by default, so anything in .bashrc is also available at login. When in doubt, .bashrc is the right place for interactive customizations.

For example, suppose you want to install an application that is not available as a module. You download and compile it and place the compiled binary in .local/bin. You would export the updated PATH in .bash_profile, since it is an environment variable that needs to be inherited by child processes:

#!/bin/bash
export PATH=~/.local/bin:$PATH

Aliases, on the other hand, belong in .bashrc. For example, to prevent R from asking to save your workspace at the end of every session (something you should never do), add:

alias R="R --no-save"