Compute Jobs

TL;DR – Use Compute Jobs when a task will run for minutes‑to‑days, needs more CPU / RAM / GPU than a regular Compute container, or must process thousands of files. The job runs on a dedicated node, so it finishes much faster than the same notebook executed interactively.

Why choose a Compute Job over a Compute container?

Feature	Compute container (JupyterLab)	Compute Job (batch)
CPU	Up to 8 vCPU (hard limit)	Up to 20 vCPU (node‑wide)
Scheduling	Starts instantly, runs on a shared node	Queued, runs on an exclusive node (no noisy‑neighbor interference)
Use‑case	Exploratory analysis, quick visualisation, prototyping	Large‑scale pipelines, Monte‑Carlo simulations, processing thousands of FITS files, etc.

Bottom line: If your notebook would stay busy for a long time or you need more resources than the interactive limits, submit a Compute Job.

What a Compute Job can run

Terminal commands / scripts – entered directly in the UI via the textfield.
A Jupyter notebook – the platform will execute the notebook from top to bottom (no manual conversion to a .py script required).

Both run inside the same curated Docker images you use for interactive containers, so all your familiar Python packages and mamba environments are available. You will need to install the environment as a first step.

Quick‑start checklist

Step	Action	Screenshot / UI hint
1️⃣	Open Compute Jobs → Run Command from the main dashboard.
2️⃣	Job name – e.g. `spectra‑pipeline`.
3️⃣	Compute domain – choose the domain.
4️⃣	Compute image – pick the same image you would use for a notebook (e.g. `xray`).
5️⃣	Data / User volumes – attach any volumes the job needs (same mount points as in a container).
6️⃣	Command – either paste a short script or point to a notebook file (e.g. `workspace/Storage/<user>/persistent/run_pipeline.ipynb`).
7️⃣	Click Create Job.
8️⃣	Monitor the job in the Jobs list; status changes from Pending → Running → Completed/Failed.
9️⃣	When finished, download stdout / stderr logs and any output files from the attached volumes.

Example: Running a notebook as a batch job

# UI fields (illustrative)
Job name:      process_fits
Compute domain:  high‑mem (32 vCPU, 250 GiB)
Image:         sciserver‑xray
Data volumes:  /workspace/Data/erosita
User volumes:  /workspace/Storage/<username>/persistent
Command:       notebooks/process_fits.ipynb

The platform will:

Pull the selected image onto an exclusive node.
Mount the specified volumes under the same paths as in an interactive container.
Execute jupyter nbconvert --to notebook --execute notebooks/process_fits.ipynb --output /workspace/Storage/<you>/persistent/results.ipynb.
Store logs and the final notebook in your persistent volume.

Example: Running a pure Bash script

#!/usr/bin/env bash
set -euo pipefail

cd /workspace/Storage/$SCISERVER_USER_NAME/persistent

# Process 10 000 FITS files in parallel (using GNU parallel)
find /workspace/erosita -name "*.fits" | \
  parallel -j 16 "python -m mypipeline.process {} > logs/{/.}.log"

Paste the script into the Command box (or upload run_pipeline.sh) and submit.

Where I can help

I can:
- Point you to the right image, volume, or UI field.
- Explain how to convert a notebook to a batch‑compatible form (e.g., nbconvert).
- Troubleshoot environment‑related errors (missing packages, permission issues).
I cannot:
- Fully write or debug your scientific Python code.
- Develop custom pipelines for you.

If you hit a Python‑logic problem, feel free to ask me on the Matrix channel, but please understand that detailed code development is outside the scope of my support role.

Best‑practice tips

Tip	Reason
Test on a small subset first (e.g., 10 files) before scaling to thousands.	Saves time and quota if something is mis‑configured.
Keep the job script idempotent – re‑running should not corrupt results.	Batch systems may restart failed jobs.
Write output to a mounted User Volume, not the container’s root FS.	The root filesystem is limited (~1 GiB) and disappears after the job ends.
Use `mamba` environments inside the job if you need extra packages. Activate them at the top of the script (`source activate myenv`).	Guarantees reproducibility.
Monitor resource usage via the Logs tab or `kubectl top pod <pod>` (if you have access).	Prevents silent OOM kills.