Your research
Resources & fair access
Choose a sensible request and understand your compute and storage limits.
On this page
Start with your live profile
Ask your client to call research_profile. It reports your CPU, memory, GPU and time limits, running-job and submitted-job allowances, persistent storage quota and scheduling guidance. These values describe your account’s allowances, not the size or current utilisation of the platform.
| Limit | What it controls |
|---|---|
| CPU, memory, time and GPUs per job | The size of one resource request. |
| Concurrent running jobs | How many allocations can execute at once. Others can queue. |
| Queued and running jobs | How many unfinished jobs you can submit. |
| Persistent storage | Files created by your native jobs, workspace tools and transfer staging. |
research_validate checks a proposed run against policy and commissioned capacity. Submission rechecks the limits because availability can change. A personal allowance does not guarantee matching hardware is free.
The console shows your queued runs in the selected workspace, why they are waiting and an estimated start when the scheduler provides one. It refreshes automatically while visible. Quotes check cost and funding; they do not reserve a start time. Customer profiles and the cluster endpoint do not expose fleet inventory or utilisation.
Why valid work can wait
- Resources: requested compute is currently occupied or unavailable.
- Priority: fair-share scheduling is balancing access across researchers.
- Running-job limit: an existing allocation needs to finish before another can run.
Read your run’s returned state and reason. Keep the existing submission while it waits. Request fewer resources when your program can use them, and avoid keeping idle interactive allocations reserved.
The returned job.scheduling explains the reason and, when the scheduler supplies one, gives estimated_start_at and estimate_checked_at. These are conditional estimates and can change with priority, reservations and other allocations. Estimates older than 90 seconds or already in the past are shown as unavailable. Queue positions are not reported because scheduling is not a single first-in, first-out line. Queue time has no usage charge; your maximum-cost credit reservation stays held until cancellation or final accounting.
Ask for a useful change
Contact your research administrator or the Maincode team with the software, expected runtime, GPU use, peak memory and storage you need. Include a representative run ID and measured failure or result. That makes a resource request easier to assess.
Use measured runtime to size the next request
minutes is a maximum allocation lifetime, not a minimum billing or fair-share charge. An allocation releases resources when it finishes. elapsed_seconds records actual Slurm allocation duration; allocated_gpu_seconds is duration multiplied by allocated GPUs. It does not measure GPU kernel utilization. An idle interactive allocation still consumes allocated time.
research_validate returns runtime_history for your last 20 completed runs in the same experiment, including median_elapsed_seconds when available. Compare model, data and resource changes before using the history to choose your next time limit. Leave a practical checkpoint margin rather than requesting a whole day for a short test.