clip-hpc/cbe

Choose storage and transfer methods on CBE.next; stage job data, restore files from snapshots, check quotas, retention, automatic deletion, and permissions, or archive results. Use before deleting, moving, renaming, or overwriting any file or directory under /groups (rm, mv, find -delete, rsync --delete, rclone sync, shell redirection onto an existing file), even for a quick cleanup, when the user names only a relative path and the working directory is under /groups, and when recovering something deleted by mistake. Use for $HOME in /users, /scratch and $SCRATCHDIR on BeeGFS, per-job /tmp, /groups, /clustertmp, /resources and /resources/ngs, and transfers to or from laptops, campus workstations, Globus, Azure archive with AzCopy, FileSender, and EOS.

Port job scripts, sbatch files, modules, conda environments, containers, data, and interactive JupyterHub, RStudio, or XPRA workflows from legacy CBE to CBE.next. Use for legacy cbe.vbc.ac.at, clip-login-* or clip-* hosts, /scratch-cbe, old QOS settings such as c_short, m_long, or g_rapid, and preparation for the legacy shutdown on 2026-12-18.

Work on CBE.next, the Vienna BioCenter HPC cluster (SSH alias cbe.next, login atlas.cbenext.vbc.ac.at, nodes cbe-c3-*, cbe-g5-*, cbe-m3-*): connect over SSH, choose Slurm partitions c, g, and m and Slurm accounts, pick NVIDIA B200 GPUs or MIG slices, and write or submit sbatch, salloc, srun, and job-array jobs, including OpenOnDemand sessions. Use for general cluster access and job setup; use the specialized CBE skills for software, data, tuning, failure triage, and migration.

Find, load, install, or run software on CBE.next using Lmod modules (EESSI/2025.06 and CBE/2025.06 stacks, module spider, collections), CVMFS repositories (Galaxy BioContainers, Refgenie reference data, CERN unpacked images), SBGrid in /programs, Apptainer, uv Python environments, or conda from the global Miniforge (conda-forge only, never Anaconda or Miniconda). Use when asking whether a tool is available, choosing a software source, resolving an environment, building a container outside the cluster, running bring-your-own-license software such as MATLAB, or requesting missing software.

Diagnose failed, crashed, killed, cancelled, timed-out, out-of-memory, hanging, or incorrect Slurm jobs on CBE.next using job logs and accounting data. Check system-side causes such as exceeded quota, scratch deletion, node failure, network or storage errors, and maintenance; compare with successful runs, reproduce minimally, and draft an HPC Servicedesk ticket when needed. Use cbe-tuning for otherwise working jobs that need better performance.

Improve Slurm job performance and resource efficiency on CBE.next using measured accounting data (sacct, jobeff, jobinfo) and small parameter sweeps. Use for slow jobs, long queue waits, over- or under-requested CPU, memory, GPU, or time, thread settings, job arrays for trivially parallel work, storage I/O bottlenecks, full B200 versus MIG choice, and scaling or parallelising a workload; use cbe-triage for failed jobs.