Frequently Asked Questions

• Fill out the Account Request form. Requests submitted by non-faculty members must be confirmed by faculty sponsors prior to account creation. 
• Follow the instructions on the Get Started page.

Research Computer does not manage user credentials. GatorLink credentials are used throughout the system. Visit the GatorLink Account Management page for all your account needs or contact UFIT HelpDesk.

• If you encounter problems or have questions, please open a support ticket. Support tickets provide a traceable, permanent record of your issue and are systematically reviewed on a daily basis to ensure they are addressed as quickly as possible. You may also contact us by email or visit our offices in person.
• Follow the instructions on the Get Started page.

The answer to this question depends mostly on how your affiliation with UF will change when you leave the university. If the new affiliation with UF does not allow for you to have an active GatorLink account, you will no longer be able to access HiPerGator.

If you will need to maintain access to your HiPerGator account after leaving UF, contact your group sponsor and request to be affiliated within their department as a “Departmental Associate.” This will ensure your GatorLink account, and therefore HiPerGator account, remain active after your previous affiliations are removed.

Of course, general UFRC Account Policies are still in effect; any HiPerGator accounts that remain inactive for more than 1 year are automatically deactivated.

HiPerGator compute and storage capabilities are changing on a regular basis. 

For detailed information on HiPerGator hardware components, view the Hardware Specification page.

HiPerGator-RV is a system for working with restricted data, having its own set of use cases.

HiPerGator-RV is a secure environment for research projects that use electronic Protected Health Information (ePHI), which are required to comply with the Health Insurance Portability and Accountability Act (HIPAA). ResVault can also be used for projects that require a “low” FISMA compliance rating, and for projects that require International Trade in Arms Regulation (ITAR) compliance.

Please see our Storage Resources page for details about the various storage options available on HiPerGator.

You can request a temporary quota increase. Submit a support request and indicate:

1. How much additional space you need
2. The file system on which you need it
3. How long you will need it

Additional space is granted at the discretion of Research Computing on an “as available” basis for short periods of time. If you need more space on a long-term basis, please review our storage options and contact us to discuss an appropriate solution for your needs.

Please see our File System Quotas page on our public wiki for details about this.

Home directories are intended for relatively small amounts of human-readable data such as text files, shell scripts, and source code.  Neither the servers nor the file systems on which the home directories reside can sustain the load associated with a large cluster. Overall system response will be severely impacted if they are subjected to such a load. This is by design, and is the reason all job I/O must be directed to the network file systems such as blue or orange.

The full list of applications installed on the cluster is available at the Installed Software wiki page.

GPU-accelerated computing is intended for use by highly parallel applications, where computation on a large amount of data can be broken into many small tasks performing the same operation, to be executed simultaneously.  More simply put, large problems are divided into smaller ones, which can then be solved at the same time.

Since GPU is a special purpose architecture, it supports restrictive programming models; one such model is nVIDIA’s CUDA. On HiPerGator, only applications that were written in CUDA can run on the GPU partition. Currently, these applications are:

• Amber
• LAMMPS
• NAMD
• Gromacs
• KERAS

Yes, if the software you need is not listed on our Installed Software page, you may submit a support request to have it installed by Research Computing staff. Please observe the following guidelines:

1. Provide a link to the web site from which to download the software
2. If there are multiple versions, be specific about the version you want
3. Let us know if you require any options that are not a standard part of the application

If the effort required to install the software is 4 hours or less, the request is placed in the work queue to be installed once an RC staff member is available to perform the work, usually within a few business days.

If initial evaluation of the request reveals that the effort is significantly greater than 4 hours, we will contact you to discuss how the work can be performed. It may be necessary to hire Research Computing staff as a consulting service to complete large and complex projects.

You may also install applications yourself in your home directory.

Please only ask us to install applications that you know will meet your needs and that you intend to use extensively. We do not have the resources to build applications for testing and evaluation purposes.

The Linux command interpreter (shell) maintains a list of directories in which to look for commands that are entered on the command line. This list is maintained in the PATH environment variable. If the full path to the command is not specified, the shell will search the list of directories in the PATH environment variable and if a match is not found, you will get the “command not found” message. A similar mechanism exists for dynamically linked libraries using the LD_LIBRARY_PATH environment variable.

To ease the burden of setting and resetting environment variables for different applications, we have installed a “modules” system. Each application has an associated module which, when loaded, will set or reset whatever environment variables are required to run that application – including the PATH and LD_LIBRARY_PATH variables.

The easiest way to avoid “command not found” messages is to ensure that you have loaded the module for your application. See Modules for more information.

The purpose of a batch system is to execute a series of tasks in a computer program without user intervention (non-interactive jobs). The operation of each program is defined by a set or batch of inputs, submitted by users to the system as “job scripts.”

When job scripts are submitted to the system, the job scheduler determines how each job is queued. If there are no queued jobs of higher priority, the submitted job will run once the necessary compute resources become available.

A batch job is submitted to the batch system via a job script passed to the sbatch command. Once queued, a batch job will run on resources chosen by the scheduler. When a batch job runs, a user cannot interact with it.

• View a walk-through of an example batch job script

An interactive job is any process that is run at the command line prompt, generally used for developing code or testing job scripts. Interactive jobs should only be run in an interactive development session, which are requested through the srundev command. As soon as the necessary compute resources are available, the job scheduler will start the interactive session.

• View the Interactive Development & Testing documentation page

A GUI job uses HiPerGator compute resources to run an application, but displays the application’s graphical user interface (GUI) to the local client computer. GUI sessions are also managed by the job scheduler, but require additional software to be installed on the client side computer.

• View the GUI Programs documentation page

Use the following command to view your group’s total resource allocation, as well as how much of the allocation is in use at the given instant.

$ module load ufrc
$ slurmInfo <group_name>

Allocation information is returned for the both the investment QOS and burst QOS of the given group.

The primary job submission mechanism is via the sbatch command via the Linux command line interface

$ sbatch <your_job_script>

where <your_job_script> is a file containing the commands that the batch system will execute on your behalf. Jobs may also be submitted to the batch system through the Galaxy web interface as well as the Open Science Grid’s Globus interface.

• View a walk-through of an example job script
• View sample scripts for several different job types (single-threaded, multi-threaded, MPI, hybrid, array)
• View exhaustive documentation on the sbatch command on SchedMD

Parallel computing refers to the use of multiple processors to run multiple computational tasks simultaneously. Communications between tasks use one of the following interfaces, depending on the task:

• OpenMp – used for communication between tasks running concurrently on the same node with access to shared memory
• MPI (OpenMPI) – used for communication between tasks which use distributed memory
• Hybrid – a combination of both OpenMp and MPI interfaces

You must properly configure your job script in order to run an application that uses multiple processors. View sample SLURM scripts for each case below:

• OpenMp job (sample SLURM script)
• MPI job (sample SLURM script)
• Hybrid job (sample SLURM script)

If you get this error, it is most likely either because

1. You submitted a job with a specified qos for which you are not a group member
2. Your group does not have a computational allocation

To check what groups you are a member of, log in to the cluster and use the following command:

$ groups <user_name>

To check the allocation of a particular group, log in to the cluster and use the following command:

$ module load ufrc
$ slurmInfo <group_name>

Sometimes, SLURM will log the error slurmstepd: Exceeded job memory limit at some point. This appears to be due to memory used for cache and page files triggering the warning. The process that enforces the job memory limits does not kill the job, but the warning is logged. The warning can be safely ignored. If your job truly does exceed the memory request, the error message will look like:

slurmstepd: Job 5019 exceeded memory limit (1292 > 1024), being killed
slurmstepd: Exceeded job memory limit
slurmstepd: *** JOB 5019 ON dev1 CANCELLED AT 2016-05-16T15:33:27 ***

You can easily check the status of your jobs using the Job Status utility. To navigate to the utility from the Research Computing website, use the Access menu header along the top of each page.

Alternatively, you can use the following command to check the status of the jobs you’ve submitted:

$ squeue -u <user_name>

To check the status of jobs running under a particular group, modify the command with the -A flag:

$ squeue -A <group_name>

To also return QoS information for jobs under a particular group, use the following command:

$ squeue -O jobarrayid,qos,name,username,timelimit,numcpus,reasonlist -A <group_name>

You can use the command

$ scancel <job_id>

to delete jobs from the queue. You can only delete jobs that you submitted.

This is typically caused by hidden characters in your job script that the command interpreter does not understand. If you created your script on a Windows machine and copied it to the cluster, you should run

$ dos2unix <your_job_script>

This will remove any characters not recognized by Linux command interpreters from the text file.

Use the following command to view how busy the cluster is:

$ slurmInfo

You should use the interactive test nodes for software development and testing. These nodes are kept consistent with the software environment on the computational servers so that you can be assured that if it works on a test machine, it will work via the batch system. Connect to the cluster and use the following command to start a developmental session:

$ module load ufrc
$ srundev


The srundev command can be modified to request additional time, processors, or memory, which have defaults of 10 minutes, 1 core, and 2GB memory, respectively. For example, to request a 60-minute session with 4 cores and 4GB memory, use:

$ module load ufrc
$ srundev --time=60 --cpus-per-task=4 --mem-per-cpu=4gb


Generally speaking, we use modules to mange our software environment including our PATH and LD_LIBRARY_PATH environment variables. To use any available software package that is not part of the default environment, including compilers, you must load the associated modules. For example, to use the Intel compilers and link against the fftw3 libraries you would first run:

$ module load intel
$ module load fftw

Which may be collapsed to the single command:

$ module load intel fftw

We have two compiler suites, the GNU Compiler Collection (GCC) and the Intel Compiler Suite (Composer XE). The default environment provides access to the GNU Compiler collection while the Composer XE may be accessed by loading the intel module (preferably, the latest version).

HiPerGator meets the security and compliance requirements of the HITRUST standard. To set up a project that works with PHI, you must adhere by the policies and follow the procedures listed here.

HiPerGator meets the security and compliance requirements of the HITRUST standard. To set up a project that works with FERPA, you must adhere by the policies and follow the procedures listed here.

HiPerGator has a secure enclave called ResVault, that has been certified to be compliant with NIST 800-171 and 800-53-moderate as required for handling controlled unclassified information (CUI) as specified in the DFARS. Follow the policies and procedures

You may use the interactive MATLAB interpreter on the test nodes. However, in order to run MATLAB programs through the batch system, you must compile your MATLAB source code into a standalone executable. This is required because there are not enough MATLAB licenses available to run the programs directly. To learn how to compile your MATLAB program please see our MATLAB wiki page.

Generally speaking, you will load the MATLAB module and then use the MATLAB compiler, mcc, to compile your MATLAB program(s). See our MATLAB wiki page for more detailed instructions.

If you tried to use the MATLAB compiler, mcc, and received the message “Could not check out a compiler license” it is because Research Computing does not have its own MATLAB licenses but relies on the UF campus license. There are a limited number of MATLAB compiler licenses shared by the whole campus. When the license is checked out during an interactive MATLAB session, it does not get checked back in until the MATLAB session is terminated, which could take a long time depending on what the user is doing. Unfortunately, you will not be able to run mcc until a license becomes available.

For upload and manipulation of datasets within the Galaxy framework, please see this section of the Galaxy wiki.

See the relevant wiki article.

You can always open a support request when you have questions even if you are not sure whether there is an issue. If you’d like you can check the list of known Galaxy issues that are already being worked on before searching for help.

Please submit a support request. The tool in question could already be wrapped by someone and available in the Galaxy Tool Shed. If it’s in the Tool Shed we can usually make it available in the UF Galaxy instance almost immediately. If the tool is not available in the Galaxy Tool Shed, we can look at the tool to determine if we can “wrap” it into the Galaxy interface and what the timeline for the project may be.