REPACSS GPU

RP account needed

REPACSS GPU is the accelerator partition of Texas Tech's REPACSS cluster, built for GPU-heavy work such as AI training, large-scale inference, and CUDA-accelerated simulation and data analytics. Each node carries several NVIDIA H100 NVL GPUs, each with a large amount of high-bandwidth memory, alongside an Intel Xeon host with substantial system memory. The large per-GPU memory is the partition's main strength for AI work, letting bigger models and batches fit in GPU memory.

This makes REPACSS GPU well suited to deep-learning training and inference, and to any CUDA or GPU-offloaded scientific code. As part of REPACSS, it also runs on the cluster's variable, renewable-energy design, so it fits researchers interested in energy-aware computing in addition to those who simply need the GPUs. Jobs are scheduled through Slurm, and GPU nodes are reached through the h100 partition.

Jobs

Work on REPACSS is managed by the Slurm workload manager. After logging in, you land on a login node, which is meant only for preparing work — editing files, compiling code, staging data — not for running it; all computation must be submitted to the compute nodes as a Slurm job. GPU work runs in the h100 partition, requested either as a batch script (sbatch -p h100 job.sh) or an interactive session (interactive -p h100); interactive jobs on GPU partitions are given scheduling priority on REPACSS. Because a partition placement alone does not allocate a GPU, every GPU job must also request the device explicitly with --gres=gpu:nvidia_h100_nvl:<count> — without it, the job lands on a GPU node but CUDA code fails because no GPU was assigned.

A couple of REPACSS-specific details matter when building GPU jobs. CUDA modules exist only on the GPU nodes, not on the login node, so module load cuda must be run after you've landed on an h100 node, not before; a quick nvidia-smi in an interactive session confirms the GPU is visible before you submit. GPU work is charged against your ACCESS allocation at 100 ACCESS credits per GPU-hour — charged per GPU, so a job using more than one GPU accrues credits proportionally. Walltime limits aren't stated in the user guide, so confirm those with sinfo/scontrol or the REPACSS team before relying on them.

For more detail, please visit the Job Basics page (https://guide.repacss.org/running-jobs/basics.html).

Queue specifications

Name Purpose Nodes CPU cores / node GPUs / node Node RAM Jobs
30 days
Wait Time
30-day trend
Wall Time
30-day trend
h100 GPU-accelerated workloads — AI training and inference, and CUDA/GPU-offloaded simulation and analytics 8 2x Intel Xeon Gold 6448Y (64 cores) 4 NVIDIA H100 NVL (94 GB vRAM) 512 GB

Software

No software usage data is currently reported for REPACSS GPU in XDMoD.

SEE ALL SOFTWARE AVAILABLE ON REPACSS GPU


Storage

REPACSS organizes user storage into three areas, all located under your group on a shared filesystem, so storage is allocated and counted per group rather than per individual — members of a project share the same space. Home ($HOME) is persistent space for scripts, configuration, and source code. Scratch ($SCRATCH) is high-performance space for the active inputs and outputs of running jobs; it is periodically purged, so it shouldn't hold anything you need to keep. Work ($WORK) is longer-term space for research data and results you want to retain between jobs. You can check your group's current usage from a login node with df -h /mnt/$(id -gn) or quota -s.

Note: There is a combined storage of 9TB across the 3 filesystems. For more information, visit https://guide.repacss.org/absolute-beginner-guide.html#checking-quotas.

File System

Directory Path Quota Purge Backup Notes
$HOME /mnt/GROUPID/home/USERID Persistent personal storage for user scripts and configuration files.
$SCRATCH /mnt/GROUPID/scratch/USERID High-performance temporary storage space subject to periodic purging.
$WORK /mnt/GROUPID/work/USERID Long-term storage for research outputs and work purposes.

File Transfer

Data moves in and out through a few methods. Globus Connect is a web-based service for large, reliable transfers, using parallel streams with automatic retry, reached through the collection endpoint named REPACSS. scp copies files over SSH from the command line and suits small or occasional transfers. rsync syncs files and resumes partial transfers efficiently, and sftp gives interactive file access over SSH — but large scp, rsync, or sftp transfers should not run on the login nodes, since that degrades performance for all users.

For more detail, please visit the File Transfer page (https://guide.repacss.org/understanding/repacss-system/file-system/file-transfer.html) and the system architecture page (https://guide.repacss.org/understanding/repacss-system/architecture.html).

Supported Methods Data Transfer Node URL
GLOBUS CONNECT | RECOMMENDED https://app.globus.org/dashboard
SCP
SFTP
RSYNC