What disk storage locations are available at the CSUC HPC machines?
There are four separate data storage locations in our HPC machines.
- The /home/ volume can be accessed from all machines. It is a permanent storage space, with regular back-up and a personal quota of 4GB. A group quota can also apply. This is the storage unit that should be used for permanent inputs, model files, scripts, and other such files. The environment variable $HOME points to /home/youruser/.
- The /cescascratch/ volume can be accessed from all machines. It provides a convenient location for produce large data files (such as long simulation outputs), with a personal quota of 1TB. Files in /cescascratch/ can be automatically deleted after 30 days, and the unit is not backed-up. The environment variable $SCRATCH points to /cescascratch/youruser/.
- The /dades/ volume is a specialised, unlimited, not backed-up permanent storage units for users with specific data storage needs. Access must be requested in advance. $DADES points to /dades/youruser/.
- /tmp/ is the local disk space in each node, allowing for fast I/O rate, but can only be accessed from the node itself. Files in /tmp/ are cleared after a week and space usage is limited by job. $TMPDIR points to /tmp/youruser/jobid.date/ for ease of identification.
What is the optimal amount of memory for Gaussian jobs?
Since Gaussian performance is often limited by memory, it is important to set memory limits correctly. The Gaussian directive %Mem and the LSF option -M shouldn't be confused:
%Mem limits the amount of memory (in words) that Gaussian will use during the calculation. Gaussian may implement some methods differently depending on this memory limit. You can use the Gaussian utility freqmem to estimate how much memory a Gaussian calculation needs.
How is job priority calculated?
The algorithm is quite complex, but the main factors are:
- The unused computational hours (HCs) assigned to the group. The more unused hours, the higher the priority.
- The number of jobs by the same user and by the same group currently running. The more jobs are currently running, the lower the priority of new jobs.
- To what queue is the job sent. The commant bqueues lists all the queues in the LSF system and their priorities (amongst other values).
Why is my job permanently in PEND mode?
If a job remains an unusually long time in pending mode, it is usually due to some mistake in the options specified in the LSF file so that no machine fits all the criteria. You can check the Quick Guide for more details about queues and machines.
In exceptional circumstances a job can remain pending for a long time with proper configuration, especially for jobs which require a large number of cores or which demand an entire node, if smaller jobs use these resources in a more piecemeal way, but the LSF priority algorithm tends to take care effectively of these situations so only rarely should a job be stalled for a long period of time due to queueing.