Best practices¶

Guidelines to help you make the most of the clusters and keep them running smoothly for everyone.

Login nodes are shared

Use them only for editing, compiling, and submitting jobs. Never run heavy computations on them.
Work from /scratch

Always submit jobs from /scratch. Clean up when done; it is not permanent storage.
Request only what you need

Oversized requests waste resources and wait longer in the queue. Use seff to right-size.
Use --no-requeue

Prevent SLURM from silently restarting your job after a node failure unless your code checkpoints.
Test before launching

Always validate your script with a short --qos=test run before committing to long production jobs.
Enable email notifications

Use --mail-type=END,FAIL to get notified instead of polling the queue.
Name your jobs

Use descriptive --job-name values to keep track of what is running.
Acknowledge DIPC

Include the required acknowledgement in your publications.

The login nodes are shared by all users. They are intended for:

Submitting and managing jobs.
Editing files and scripts.
Short, serial compilations.
Transferring data between filesystems.

No heavy computation on login nodes

Running computationally intensive processes on the login nodes is strictly forbidden. This includes long compilations, data processing, and any CPU or memory-intensive task. If you need an interactive session with significant resources, submit an interactive job through SLURM instead:

salloc --qos=test --time=00:10:00 srun --pty bash

Always run jobs from `/scratch`¶

Your /scratch directory is the right place to submit and run all your jobs. The details vary by cluster:

HyperionAtlas EDR / Atlas FDR

On Hyperion, /dipc (home) is accessible from compute nodes, but /scratch is still the recommended working directory for all jobs. It runs on BeeGFS over InfiniBand and is designed for high-throughput I/O.

On Atlas EDR and Atlas FDR, /dipc (home) is not available on compute nodes. Inside compute nodes, /dipc is a symbolic link pointing to /scratch. If you submit a job from your home directory, it may not behave as expected.

Always submit your jobs from /scratch to ensure consistent behavior across all clusters.

Keep `/scratch` clean¶

The /scratch filesystem is designed as a fast, temporary workspace for active jobs. It is not backed up.

Performance degrades above 80% occupancy

When /scratch usage exceeds 80%, the filesystem experiences performance degradation that affects all users. If occupancy continues to grow, files and directories older than 90 days may be removed without prior notice.

Follow these guidelines to keep /scratch healthy:

Move results to a permanent storage location after your jobs complete.
Delete temporary files (intermediate outputs, checkpoints you no longer need) regularly.
Avoid storing many small files in a single directory. Try to keep directories to a few hundred files at most. Consider using tar archives for collections of small files.

Request only the resources you need¶

Requesting more CPUs, memory, or time than your job actually uses does not make it run faster. It makes it wait longer in the queue and blocks resources for other users.

Use seff to right-size your requests

After a job completes, run seff <jobid> to see actual CPU and memory usage:

$ seff 123456
Job ID: 123456
State: COMPLETED
Cores: 48
CPU Utilized: 12:34:56
CPU Efficiency: 87.5%
Memory Utilized: 24.5 GB
Memory Efficiency: 51.0% of 48.00 GB

If CPU efficiency is consistently low, reduce --cpus-per-task. If memory efficiency is very low, reduce --mem. Tighter requests get scheduled faster.

Protect your jobs with `--no-requeue`¶

If a node fails (freeze, reboot, memory error), SLURM will attempt to requeue your job by default. The restarted job runs from the beginning and overwrites your output files.

Unless your code is specifically designed to resume from checkpoints, add this directive to your batch scripts:

#SBATCH --no-requeue

More details: Requeuing policy

Test before launching¶

Always validate your workflow with a short test run before committing to long production jobs. The test QoS has high scheduling priority and a 10-minute time limit, which makes it ideal for this:

#SBATCH --qos=test
#SBATCH --time=00:10:00

Use these test runs to verify that:

Your script starts without errors (paths, modules, input files).
The program produces the expected initial output.
Resource requests (memory, CPUs) are in the right ballpark before scaling up.

Tip

A 10-minute test that catches a typo in your script saves you from wasting hours of queuing time and compute resources on a job that was going to fail anyway.

Enable email notifications¶

Instead of repeatedly running squeue to check on your jobs, let SLURM notify you:

#SBATCH --mail-user=your_email@dipc.org
#SBATCH --mail-type=END,FAIL

Available notification types: BEGIN, END, FAIL, ALL. Using END,FAIL is a good default: you get notified when your job finishes or if something goes wrong.

Name your jobs¶

Give your jobs descriptive names with --job-name:

#SBATCH --job-name=vasp_relaxation

This helps you identify jobs in squeue output, and makes output files self-documenting when using %x in the filename pattern (--output=%x.%j.out). It also helps administrators diagnose issues more quickly when you contact support.

Acknowledge DIPC in publications¶

If your research benefits from DIPC computational resources, please include an acknowledgement in your publications. This helps demonstrate the impact of our infrastructure and supports continued funding for the clusters.

Suggested wording and details

Getting help¶

If you run into problems or have questions, contact us at support-hpc@dipc.org. To help us resolve your issue as quickly as possible, please include:

What to include	Why
Your username and cluster	So we can look up your account and environment
The job ID	So we can check logs and scheduler history
The error message or unexpected behavior	So we can understand the symptom
The commands or scripts you ran	So we can reproduce the problem

Tip

Email is the most effective way to reach us. It allows us to track, prioritize, and follow up on your request properly. Walk-ins and phone calls are welcome but may not receive the same immediate attention, as our team is often working on infrastructure tasks.

Our support hours are Monday to Friday, 9:00 to 18:00.

Requesting software¶

Our clusters include a wide range of pre-installed applications and libraries managed through Environment Modules. If you need something that is not available, send us a request at support-hpc@dipc.org with the software name, version, and a download link. Any extra detail you can provide (dependencies, compilation notes, test inputs) helps us get it installed faster.

Full details: Software requests

You can also install software in your own home directory or use containers (Apptainer/Singularity) for full control over your environment.

Best practices¶

Use the login nodes responsibly¶

Always run jobs from /scratch¶

Keep /scratch clean¶