Get access

Three services serve different purposes:

Before connecting, log in to Elpis with your CampusID and check that you belong to a project with an active allocation. Students should ask their supervisor or principal investigator (PI) to add them to the appropriate project. A PI without an allocation can follow the startup allocation instructions. Your project’s Slurm account name is needed when requesting computing resources. See GSU’s access prerequisites.

Start in the browser

Hemera is a convenient starting point if you are new to a computing cluster.

1. Sign in with your CampusID.
2. Open Interactive Apps → ACIDs Desktop and choose the account associated with your project.
3. Request a modest number of cores and a short runtime for testing. Wait for the allocation, then launch the desktop.
4. Use Files to inspect scripts or transfer a few small files. For larger datasets, use Globus as described below.
5. When finished, use Delete under My Interactive Sessions to release the session’s resources.

GSU describes these interactive apps as a development environment, rather than a place for production runs exceeding one hour. Use them to debug code and check packages; submit longer analyses as batch jobs. Hemera also provides Jobs → Job Composer for creating and submitting job scripts in the browser. See the Open OnDemand guide.

Connect from a terminal

SSH is useful when you prefer editing scripts locally and managing jobs from a terminal. ARCTIC uses an SSH key pair, a signed certificate from Elpis, and Duo authentication. A CampusID password alone does not complete this setup.

Follow GSU’s key-generation guide, then sign the public key in Elpis. Upload only the public key; keep the private key on your own computer. The SSH login guide explains certificate placement and SSH-agent configuration for each operating system.

After completing that setup, replace YOUR_CAMPUSID below and connect from your own computer:

ssh -o ForwardAgent=yes YOUR_CAMPUSID@arclogin.rs.gsu.edu

Use the login node to edit files, inspect jobs, and submit work. Request a compute allocation before running an analysis or installing computationally intensive packages. GSU’s interactive job guide explains how to obtain a terminal session on a compute node.

Store and transfer files

Choose storage according to the purpose of the files:

Within a Slurm job, $SCRATCH points to temporary space associated with that job. For substantial analyses, stage inputs there and copy results to Work or Project storage before the job finishes. Scratch is not a backup and its contents can be purged. Storage paths, access methods, and limits are described in the ARCTIC storage guide.

For large transfers, use Globus and the ARCTIC transfer flows. GSU provides separate instructions for personal computer → Scratch and Scratch → personal computer. Check that a transfer has completed before submitting a job that needs those files.

Submit a first R job

A batch job is a script that asks Slurm for resources and specifies what to run. Once submitted, it can wait in the queue and run without keeping your browser or SSH session open. This small example uses only base R and prints results to a log.

mkdir -p ~/gsu-computing-demo
cd ~/gsu-computing-demo

set.seed(2026)
x <- rnorm(10000)
cat("Number of observations:", length(x), "\n")
cat("Sample mean:", mean(x), "\n")
cat("Sample standard deviation:", sd(x), "\n")
sessionInfo()

#!/bin/bash
#SBATCH --job-name=r-smoke-test
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=2G
#SBATCH --time=00:05:00
#SBATCH --output=r-smoke-%j.out
#SBATCH --error=r-smoke-%j.err

set -e
cd "$SLURM_SUBMIT_DIR"
module load R
module list
export OMP_NUM_THREADS=1
export OPENBLAS_NUM_THREADS=1
export MKL_NUM_THREADS=1
Rscript --vanilla smoke_test.R

sbatch --account=YOUR_ACCOUNT --partition=YOUR_CPU_PARTITION \
  run-r.sbatch

# See your queued and running jobs.
squeue -u "$USER"

# Inspect a job after it finishes.
sacct -j JOBID --format=JobID,State,Elapsed,MaxRSS,ExitCode

Adapt the workflow to your research

R packages. Install dependencies once in a personal library from an allocated interactive session, then use the same R version and library path in your batch jobs. Avoid reinstalling packages in every simulation replicate. GSU’s R package guide covers user libraries.

Python. Choose an installed Python module and create a project-specific environment. In each batch script, load the matching module, activate that environment, and run your script with Python. GSU’s virtual environment guide explains this setup. Loading Python alone does not activate the packages installed in your environment.

Repeated simulations. For independent bootstrap samples or simulation replicates, consider a Slurm job array. Use the task ID to choose a replicate, set a reproducible seed, and give each task a separate output filename. Test one replicate successfully before launching many.

GPU workloads. Request a GPU only when your code can use it. A GPU partition and a GPU resource request are both needed; see GSU’s partition and GPU instructions. Ordinary R code does not automatically become GPU-enabled.

Troubleshooting and help

• SSH suddenly stops working: check whether the signed certificate has expired. GSU requires periodic renewal; the authentication troubleshooting guide explains how to inspect and renew it.
• An account or partition is rejected: check project membership and allocation details in Elpis, then confirm the permitted partition with your PI or ARCTIC.
• A package is missing in a batch job: compare the loaded modules, R library path, or Python environment with the interactive session where it worked.
• A job runs out of memory or time: inspect its logs and accounting information, test a smaller case, and adjust the request based on measured usage.

When asking for help, include the job ID, submission script, module versions, and relevant error output. The ARCTIC wiki is the starting point for cluster documentation; the GSU Resource page also collects computing and support links.