This guide is for researchers moving compute work from an Ursa Major (Google Cloud) project to the UCR High-Performance Computing Center (HPCC) cluster. The HPCC is a separate service from Ursa Major; its documentation at hpcc.ucr.edu is the authority on its policies and software.
Why move to the HPCC?
- Cost model: the HPCC charges an annual lab registration, $1,000 per lab per year (HPCC Recharging Rates 2026/2027, as of Oct 2026), that covers the lab's members, subject to the HPCC's shared-use quotas (Queue Policies). For steady, long-running work this can cost a lab less than keeping cloud VMs running, which are recharged under Ursa Major Tier 2 (see Ursa Major service tiers).
- Hardware: CPU, high-memory and NVIDIA GPU nodes, with shared parallel storage. See the HPCC Hardware Details page.
- Batch scheduling: jobs run when resources become available and stop when they finish, so nothing keeps running (or charging) while idle.
You need an HPCC account first. See Getting an HPCC account.
The three steps
Step A: move your data (Cloud Storage to the HPCC)
Copy your data from Google Cloud Storage buckets to your lab's /bigdata space on the HPCC. /bigdata is storage a lab buys separately from cluster access; your home directory has a 50 GB quota (see HPCC Recharging Rates), which is too small for most datasets. See the HPCC Data Storage page and HPCC storage.
Costs on the Google side: downloading data out of Google Cloud can incur network egress charges, and reading Coldline or Archive storage adds retrieval charges. These are billed to the Ursa Major project. Check Google Cloud Storage pricing and estimate before moving large datasets.
Using rclone
- Log in to the HPCC:
ssh username@cluster.hpcc.ucr.edu - Load the module:
module load rclone - Configure a remote: run
rclone configand answer:nfor a new remote, namedgcp.- Storage type:
Google Cloud Storage (this is not Google Drive). - Your project number (from the Google Cloud console).
- Authentication: either give the path to a service account JSON key file that can read the bucket, or leave it blank to log in with your own Google account.
- When asked to use auto config, answer
n(the HPCC has no web browser). rclone then tells you to run a command on your laptop to authorize and paste the result back.
The rclone Google Cloud Storage guide explains each option.
-
Copy the data:
# Copy a bucket to your lab's bigdata space rclone copy gcp:my-lab-bucket /bigdata/labname/username/project_data/ -P-Pshows progress. Replacemy-lab-bucket,labnameandusernamewith your own. Run large copies inside a batch job or atmuxsession so they keep going if your connection drops.
Step B: move your software environment (Docker to Singularity)
In the cloud you may have used Docker or a custom VM image. You do not have root on the HPCC, so containers run with Singularity (singularity-ce), which can run Docker images. See the HPCC Singularity page.
1. Pull an image from Docker Hub:
module load singularity
singularity pull my-env.sif docker://ubuntu:22.04
2. Use your own Dockerfile:
- Build it on a machine where you have Docker:
docker build -t my-repo/my-image . - Push it to Docker Hub or the GitHub Container Registry.
- Pull it on the HPCC:
singularity pull my-env.sif docker://my-repo/my-image
3. Run it interactively on a compute node (not the head node):
srun -p gpu --gres=gpu:1 --mem=16g -c 4 --time=1:00:00 --pty bash -l
module load singularity
singularity shell --nv my-env.sif
The --nv flag makes the node's NVIDIA GPU available inside the container. Leave it out on CPU-only nodes.
Step C: move from always-on VMs to batch jobs
In the cloud you might leave a VM running around the clock. On the HPCC you submit jobs: instead of running a server, you ask for resources for a set number of hours, and the job ends when your script finishes.
Example Slurm script (submit_job.sh):
#!/bin/bash -l
#SBATCH --job-name=my_analysis
#SBATCH --output=logs/output_%j.txt
#SBATCH --error=logs/error_%j.txt
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G
#SBATCH --time=24:00:00
#SBATCH --partition=gpu
#SBATCH --gres=gpu:1
# Load Singularity
module load singularity
# Run your script inside the container
singularity exec --nv my-env.sif python3 /bigdata/labname/username/scripts/run_model.py
Create the logs directory before submitting (mkdir -p logs); Slurm does not create it. Jobs on the gpu partition must request a GPU with --gres. For CPU-only work, use a CPU partition such as epyc and remove the --gres line and --nv. Partition limits (for example 7 days maximum on gpu) are on the HPCC Queue Policies page.
Submit it:
sbatch submit_job.sh
See the HPCC Managing Jobs page for monitoring and more examples, and Connecting to the HPC cluster for a first test job.
Troubleshooting and FAQ
Q: My code needs a public IP address or hosts a web service. A: HPCC compute nodes do not have public IP addresses and are not meant to host services. Contact support@hpcc.ucr.edu or research-computing@ucr.edu. A Kubernetes platform such as Nautilus may fit better.
Q: I need root access.
A: Users do not get root on the HPCC. Install your dependencies into a container image, built where you do have root (your laptop, or a remote builder), then run that image on the HPCC with Singularity. Many tools are also already available as HPCC modules (module avail).
Q: Can I move my VM disk to the HPCC?
A: No. A Google Cloud VM disk cannot run on the HPCC. Copy the files you need (data, scripts, configuration) with rclone or scp, and rebuild the software environment as modules or a container.