Getting Started with Beehive

Connecting to the Cluster

SSH keys are required to access the cluster. Password authentication is disabled.

ssh YOUR_USERNAME@cluster.ttic.edu

If you haven't set up your SSH key yet, see the SSH Keys guide.

Critical Usage Information

Login Node Usage

The login node (cluster.ttic.edu) should only be used for:

• Submitting jobs with sbatch
• Monitoring jobs with squeue and sacct
• Light file operations and code editing

Note: VS Code Remote-SSH and similar editor back-ends do not work on this cluster: their node server processes are killed automatically on the login node, and compute nodes do not accept user SSH. Use a terminal editor (vim, emacs, helix) on the login node, or edit locally and sync with scp/rsync.

Do not run compute-intensive or I/O-intensive tasks on the login node. Instead, request an interactive job on a compute node when you need to:

• Debug your code
• Perform data preprocessing
• Run interactive Python/Jupyter sessions
• Compile large projects

Note: gdb, strace, py-spy and other ptrace-based tools are disabled on every cluster host (kernel.yama.ptrace_scope=3, a security mitigation). Use pdb, logging, or framework-level profilers instead.

Interactive Jobs

To get an interactive shell on a compute node:

# Request an interactive CPU job
srun --pty -p cpu bash

# Request an interactive GPU job
srun --pty -p gpu -G1 bash

Always pass -p. If you omit it, your job lands in the default partition dev-cpu: a single 12-core test node (test-c0, 64 GB RAM, no GPU) with a 1-hour time limit. Real work belongs on cpu or gpu (8 hours).

GPU partitions (gpu, low-gpu, dev-gpu, and the group partitions) reject any job that does not request a GPU (-G N, --gpus=N, or --gres=gpu:N). CPU-only work goes to cpu.

Storage

• Keep code, environments and results in your home directory or project space: they are visible from every node and survive your job.
• Use /scratch/$USER/... for I/O-heavy intermediate data during a job, and copy what you want to keep back to NFS before the job ends. On a few nodes (test-g0, priv-g12, priv-g13) /scratch is a directory on the system disk rather than a dedicated drive.
• /scratch is never cleaned up for you - remove what you no longer need.
• Heavy I/O against your home directory from many jobs slows NFS down for everyone; stage data to /scratch first.

Best Practices

1. Never run heavy workloads on the login node - use interactive jobs instead
2. Use the development partitions for testing and debugging jobs (limited to 1 hour)
3. Specify GPU architectures when your code requires specific features
4. Request only the resources you need to improve scheduling efficiency
5. Utilize checkpointing in your code to recover from the 8-hour time limit on standard partitions
6. Monitor your job's memory usage to avoid out-of-memory errors
7. Use appropriate CUDA version for your applications