R¶

R is an open-source language and environment for statistical computing and graphics.

Loading the module¶

module load R/4.4.1-gfbf-2023b

installed.packages()[, "Package"]

Batch job example¶

#!/bin/bash
#SBATCH --qos=regular
#SBATCH --job-name=r_job
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=32G
#SBATCH --time=08:00:00
#SBATCH --output=%x.%j.out
#SBATCH --error=%x.%j.err

module load R/4.4.1-gfbf-2023b

export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}

Rscript my_analysis.R

You can also use R CMD BATCH my_analysis.R (output goes to my_analysis.Rout) or R < my_analysis.R --no-save. Prefer Rscript for new scripts; it is the simplest and most portable option.

Interactive sessions¶

To explore data or test code before submitting a batch job, request a compute node and start R interactively:

srun --qos=test --cpus-per-task=4 --mem=16G --time=01:00:00 --pty bash
module load R/4.4.1-gfbf-2023b
R

For a full IDE experience, see RStudio Server.

Pre-installed package bundles¶

In addition to R itself, we provide two package bundles from our central repository that cover most common use cases. Load them alongside R to get access to hundreds of packages without installing anything yourself:

module load R-bundle-CRAN
module load R-bundle-Bioconductor

The bundle must be compatible with your loaded R version and toolchain. Use module spider R-bundle-CRAN to see which versions are available and what R they require.

Installing R packages¶

DIPC staff installs commonly requested packages centrally. Contact support-hpc@dipc.org if you need something that is not available. You can also install packages locally in your own directory.

Setting up a local library¶

Add the following to your ~/.Renviron file (create it if it does not exist):

R_LIBS_USER=/scratch/%u/R/libs/%V

R expands %u to your username and %V to the R version. Then create the directory and install packages normally:

mkdir -p /scratch/$USER/R/libs/4.4.1

install.packages("ggplot2")

Packages that fail to compile¶

Some packages need system libraries that are not available by default (e.g., sf and terra need GDAL, rstan needs a C++ toolchain). Before contacting support, check whether the library is already available as a module:

module spider GDAL

If a module exists, load it before running install.packages(). Make sure the module uses the same toolchain and version as your R module (e.g., if you loaded R/4.4.1-gfbf-2023b, look for a GDAL built with gfbf-2023b or compatible), and that it meets the minimum version the R package requires.

If the dependency is not available as a module or you are unsure which one to load, contact us at support-hpc@dipc.org with the error output; we can install the missing dependencies or the package itself as a system module.

Compiled packages on Hyperion¶

Hyperion has three CPU microarchitectures (CascadeLake, IceLake, Emerald Rapids). When you run install.packages() on a package that contains C, C++, or Fortran code, R compiles it for the CPU you are currently on. This means:

• A package compiled on a login node may crash with "illegal instruction" if your job lands on a node with a different CPU
• Or it may work everywhere but miss optimizations specific to newer CPUs

Two ways to handle this:

Simple approach -- add --constraint to your SLURM scripts so your jobs always run on the same architecture where you compiled. For example, if you installed packages from a login node with IceLake CPUs:

#SBATCH --constraint=icelake

Maximum compatibility -- compile inside an interactive job on the oldest architecture, so the binaries work everywhere:

salloc --qos=test --constraint=cascadelake --time=00:10:00 srun --pty bash
module load R/4.4.1-gfbf-2023b
R

install.packages("mypackage")

The second approach sacrifices some performance on newer nodes, but your packages will work on any node without worrying about constraints. For most R workloads the difference is negligible.

See Node selection for more details on microarchitecture constraints.

Parallel computing¶

R is single-threaded by default, but many operations (matrix algebra, apply on large data) can benefit from parallelism. There are two levels:

Implicit parallelism (BLAS)¶

Our R modules are compiled with OpenBLAS, which automatically parallelizes linear algebra operations (matrix multiplication, SVD, etc.) across multiple cores. This happens transparently; you do not need to change your code. The number of threads is controlled by OMP_NUM_THREADS, which the batch script examples above already set via SLURM_CPUS_PER_TASK.

Explicit parallelism (parallel package)¶

For embarrassingly parallel tasks (e.g., running the same analysis on many datasets), use the built-in parallel package:

library(parallel)

ncores <- as.integer(Sys.getenv("SLURM_CPUS_PER_TASK", "1"))

results <- mclapply(1:100, function(i) {
    # your analysis here
    expensive_function(i)
}, mc.cores = ncores)

mclapply uses forking and works within a single node. Match mc.cores to --cpus-per-task in your SLURM script. Other popular alternatives include foreach/doParallel for loop-style parallelism and future for a more flexible backend-agnostic approach; both are available in the CRAN bundle.

Memory tips¶

R loads all data into RAM. For large datasets:

• Use object.size() to check how much memory an object uses, and gc() to trigger garbage collection after removing large objects
• Consider data.table instead of data.frame for large tabular data; it is significantly more memory-efficient and faster
• If your data does not fit in memory, process it in chunks or consider a database backend (DBI + SQLite)

To estimate how much memory to request, run your script interactively on a small subset first, check peak memory with gc(), and extrapolate.

Troubleshooting¶

export LC_ALL=C

options(bitmapType = "cairo")
pdf("plots.pdf")  # or png(), svg(), etc.

.libPaths()

See also¶