---
title: "General HPC Guidelines"
canonical: "https://kb.uconn.edu/space/SH/26090766719/General%20HPC%20Guidelines"
format: markdown
---
> ℹ️ **Login issues:**
> ℹ️ 
> ℹ️ If you are having issues connecting to HPC using the [hpc2.storrs.hpc.uconn.edu](http://hpc2.storrs.hpc.uconn.edu/) connection after connecting to the UCONN VPN, feel free to replace the hpc2 portion with login4, login5, or login6 and try again before sending in a ticket.
> ℹ️ 
> ℹ️ Example:
> ℹ️ 
> ℹ️ [login4.storrs.hpc.uconn.edu](http://login4.storrs.hpc.uconn.edu/)

Welcome to the Storrs HPC community! There are about 2,000 students, faculty, and staff from all backgrounds and disciplines who regularly access and do research on the Storrs HPC. 

With so many people sharing the same resources, it is important that we be considerate of other users on the Storrs HPC. For that reason, we’ve laid out some general guidelines that we can all follow to make sure our work progresses smoothly without negatively impacting other HPC users. If you have any questions or comments, please feel free to reach out to us by email at [hpc@uconn.edu](mailto:hpc@uconn.edu). 

---

### **1. Please do not run computationally intensive programs (i.e. modules, scripts, analyses, or calculations) on the login nodes.**

- *Why*: The login nodes are a shared space where all users land when we log in to the cluster. They are meant to allow users to organize and set up jobs which are then run on compute nodes. Login nodes have limited memory (a.k.a. RAM) shared between all users and running programs on them is both inefficient and problematic as they do not have many resources and computationally intensive programs will slow that node down for all HPC users.
- *Exceptions*: Very basic programs (e.g. vim) or file management (e.g. rsync in a screen session) commands can be used on the login nodes, provided it is not already running slowly. See full list of allowed programs [here](https://kb.uconn.edu/space/SH/26033979893/FAQ#What-programs-am-I-allowed-to-run-on-the-login-nodes?).

> ℹ️ **Unfamiliar terms?** If some of these terms—like module, HPC, or SLURM—are new to you, feel free to check out our [Glossary](https://kb.uconn.edu/space/SH/26033979511/Glossary) page!

### **2. Always use the SLURM scheduler for any jobs or calculations. **

- *Why*: The SLURM scheduler (i.e. sbatch, srun) helps us ensure that HPC resources are being equitably distributed among our many users.
- Most jobs should be formatted as [submission scripts](https://kb.uconn.edu/space/SH/26032963685/SLURM+Guide#Job-Submission) and submit to the SLURM scheduler with the **sbatch** command
- When active input is required, an [interactive session](https://kb.uconn.edu/space/SH/26032963685/SLURM+Guide#Interactive-jobs) on a compute node can be requested with the **srun** command
- Accessing nodes directly (i.e. bypassing the SLURM scheduler) will impact your performance and someone else’s because SLURM will double book compute nodes. To reduce wait times for your jobs, consider contacting the Storrs HPC teams for information about [priority access](https://kb.uconn.edu/space/SH/26033979893/FAQ#How-do-I-get-priority-access-to-HPC-resources?).

### **3. When submitting a help request to the Storrs HPC, please include as much info, including screenshots, about the steps leading up to where problems arose. **

- *Why*: We know how frustrating it can be when technical problems are slowing research progress. Sharing screenshots of the steps leading up to where problems arise tells us that the problem is reproducible and gives us a place to start troubleshooting together.
- To submit a help request, send an email explaining the problem you’re facing to [hpc@uconn.edu](mailto:hpc@uconn.edu).
  - Examples of helpful things to screenshot include:
    - Error messages in the terminal
    - Paths to relevant files
    - Scripts that are failing
    - Modules that are being loaded
    - Partition (e.g. general-gpu) and node (e.g. cn123) where you’re working

### **4. Only use what you need.**

- While the SLURM scheduler ensures resources are distributed fairly, being mindful of the resources we use can help us get more work done as a community. We recommend that all users benchmark different configurations to see where they get optimal performance. Commonly, increasing resources does not increase performance at a certain point, and here, we ask that you allow other users to use them instead.
- In most cases, you should only use one core if your analyses are not parallelizable; using more would be a waste because the other cores are not used. An example of how to request one core in an interactive session is below.
  - *Exception: *Some analyses are not parallelizable but require more memory than is available to one core (default is 2 GB per core). If your analyses fail due to having insufficient memory, then you’ll need to request more memory using the [--mem or --mem-per-cpu flag](https://kb.uconn.edu/space/SH/26449379370/SLURM+Cheatsheet#Job-Submission).

### **5. Please do **<u>**not**</u>** use scratch for long-term storage. Instead, backup files to shared.**

- It is every researcher’s worst nightmare to have data deleted and then have to restart a research project. That’s why we should not use scratch for long-term storage. [Scratch ](https://kb.uconn.edu/space/SH/26034012236/Data+Storage+Guide#HPC-Storage-(short-term))is NOT backed up. Moreover, if scratch storage becomes limited, any files older than 60 days old can be deleted.
- Our best defense from data loss is to backup files regularly to your group’s shared directory (which are backed up daily). You can make a folder for yourself in your lab’s shared directory, which is typically found at one of the two following file paths, where the group name is typically your PI’s NetID:
  - /shared/<group_name>
  - /gpfs/sharedfs1/<group_name>
- If your group does not have a /shared directory, one can be created on request by your PI.
- Scratch should only be used to store data you’re actively working on. Scratch is best for that because it has the fastest performance.
- Follow these links for more info. on HPC [data storage](https://kb.uconn.edu/space/SH/26034012236/Data+Storage+Guide#Long-Term-Data-Storage), [backing up files](https://kb.uconn.edu/space/SH/26033816276/Data+Backup), or using [Globus](https://kb.uconn.edu/space/SH/26033653003/Globus+Connect).

### **6. Please install niche programs in your home or shared directories. **

- Storrs HPC staff members gladly install and maintain the most commonly used libraries (e.g. gcc), programming languages (e.g. R, Python, MATLAB), and programs (e.g. Gaussian).
- Storrs HPC **does not** install niche programs or packages. Instead, we facilitate installation by providing the base dependencies for most programs, like GCC compilers or base versions of python.
  - If there is a specific program or package you or your lab will be using, we recommend that users install those program/packages in their shared or home directory.
- Follow this [link ](https://kb.uconn.edu/space/SH/26033587644/Compiling+Software)for more info on software installation on the cluster. If you have questions about how to build or compile, please discuss it with your PI, and then if you have difficulty, feel free to reach out to the Storrs HPC staff.

### **7. Storrs HPC staff are not experts in most of the software on the HPC. **

- The staff at Storrs HPC are glad to be your first stop for questions about partitions, compiling software, or submitting jobs efficiently. You can contact Storrs HPC staff by sending an email to hpc@uconn.edu.
- But if you have specific software or coding questions, we recommend talking with your advisor or looking for forums related to that software where you may have a better chance at finding someone who has experience troubleshooting with that software.
- Often, copying and pasting the error message you’re receiving into a search engine (e.g., Google) may help you find forums where people have faced and fixed the same errors you’re experiencing. Posts on forums or StackOverflow are generally the most helpful, although you may need to try multiple solutions before finding one that works. Large language models (e.g ChatGPT, Gemini in Google search) can help point you in the right direction but are generally unable to solve nuanced issues by themselves.

### **8. Please exercise caution when writing scripts that automatically resubmit themselves.**

- *Problem*: Scripts that automatically resubmit can be useful for jobs that need to be run repeatedly or to extend certain jobs from previous checkpoints. But when there’s an error in the script, those scripts can get stuck in a loop where they resubmit themselves tens of thousands of times.
- *Solution*: Include language in your script that limits the number of times a given job can resubmit. Here is an example of submission script written in bash.

### **9. Please debug and test your code. **

- You can submit your test job to the *debug *partition, which allows a maximum run time of 30 minutes and is useful for estimating the resource requirements of jobs
- After a test job finishes, its CPU and memory usage can be accessed by running
- You can use this information to tailor your job submission so it runs more efficiently.

### **10. Please refrain from using sudo. It will not work. **