UCR Home ITS HPCC Campus status Get help
Research ComputingUniversity of California, Riverside
Home / Compute / OSG / OSPool
National | Distributed high-throughput computing

OSG / OSPool

The OSG's Open Science Pool runs large numbers of small, independent jobs, including GPU jobs, on spare capacity contributed by institutions across the country.

External High throughputBatchHTCondorGPUContainers Data: P1 only (no protected data)

Is it right for you?

A good fit

  • Many independent jobs (parameter sweeps, Monte Carlo, per-sample or per-file pipelines)
  • Jobs that each run on one machine, under about 20 hours, or that save checkpoints
  • Modest per-job needs (1 to 8 cores, a few GB of memory, inputs under a few GB)
  • Short GPU jobs that fit on one GPU (inference sweeps, many small trainings)
  • Researchers willing to describe jobs with HTCondor, or to ask an AI agent to help

Not a fit

  • Tightly coupled MPI jobs that span machines (use the HPCC)
  • Any protected data (P2 to P4)
  • Single jobs longer than about 20 hours without checkpointing
  • Work that needs a large shared file system, a database or a long-running service
  • Multi-GPU or multi-day model training (consider NRP Nautilus)
Not sure? Describe your work in a short consultation request and the team will suggest options. Suggestions are guidance; the service terms decide what is provided.

What it is

OSG supports distributed high-throughput computing (dHTC): splitting work into many independent jobs that run wherever capacity is idle. The Open Science Pool (OSPool) is its shared pool for US-based researchers, made up of spare capacity contributed by institutions across the country. You log in to an OSG access point, keep your files there, and submit jobs with HTCondor. HTCondor sends each job to an idle machine somewhere in the pool and brings the results back.

UCR's HPCC is one of the sites that contributes capacity to the OSPool.

What it looks like in practice

In Research Computing's own tests (November 2026), small CPU and GPU jobs typically started within a minute or two, on machines at several universities.

  • CPUs. Several thousand slots typically match a small one-core job. Smaller requests start sooner.
  • GPUs. About a hundred GPUs were in the pool when we looked, from older cards to current data-center GPUs, at around twenty sites. The mix changes from day to day, so you ask for what your code needs (for example a minimum amount of GPU memory) rather than a model. See GPU jobs on the OSPool.
  • Software. Simple, self-contained scripts run as they are. Bigger software stacks (Python or R packages, CUDA, bioinformatics tools) go in a container, either one of the images OSG provides or your own. See Containerize your research software.

Limits and guidelines

The OSPool documentation sets these, and access points enforce some of them when you submit:

  • Job length. Label each job Medium (expected under 10 hours) or Long (expected under 20 hours). Jobs that run past their category's maximum are held. Work longer than about 20 hours per job should be split up or save checkpoints.
  • Cores and memory. One core and a couple of GB of memory match the most machines. Requests up to about 8 cores, and larger memory, are possible but wait longer.
  • Data per job. Files under 1 GB move with each job. Larger files and container images go through the OSDF, which comes with an OSPool account; datasets you want to share widely can live in an Open Storage Network bucket.
  • Quotas. Your home and data directories on the access point have quotas, shown in the login message.
  • Data level. P1 only. No protected data.
  • Acknowledgement. Using an access point means accepting the OSG acceptable use policy; publications should acknowledge the OSPool.

The researcher guide explains each of these with examples.

How to get started

Try it today. Anyone with a UCR login can open OSPool Notebooks, a JupyterLab service run by the OSG, and practice HTCondor jobs and the OSG tutorials in a browser. No account is needed.

Get your own account to use the full pool. There are no shared or lab sub-accounts and no allocation proposal: each researcher who submits jobs applies, meets an OSG facilitator, and gets an account on an access point.

Our researcher guide to the OSPool and OSDF is a series of seven articles:

  1. What fits, limits and guidelines
  2. Try the OSPool today in your browser
  3. Getting an account and logging in
  4. Moving data
  5. Submitting jobs and getting results
  6. GPU jobs
  7. Common job types: sweeps, Monte Carlo, per-file pipelines and workflows

If your software needs packages or libraries, Containerize your research software with an AI coding agent shows how to package it once so it runs on the OSPool, NRP Nautilus and Google Cloud.

If you are unsure whether your work fits, ask us. Research Computing can help you decide, guide you through the application and look over your first submit file. OSG facilitators run the service, approve accounts and hold weekly office hours (support@osg-htc.org).

Owner: OSG (the service); Research Computing (UCR guidance) Reviewed: 5 Nov 2026 Governed by: OSG and OSPool policies