Use Cases and User Limits


Why use the grid? Or what are some examples of things one can do that will enable or accelerate your research?

  • You wish to run software interactively that requires computing power (RAM or CPUs) equal to or more than one's desktop or laptop.
  • You have to run an analysis that may take quite a few hours, but need to free up one's desktop or laptop for other work.
  • You wish to analyze or transform large datasets sitting on the research storage spaces with computing resources local to that data.
  • You wish to work with data in the research MariaDB database.
  • You wish to run a piece of code hundreds of times for a parameter sweep, optimization, or model fitting.

Since this is a shared system, we have to ensure that everyone has equal access and opportunity to use the resources. At this time, the following constraints have been put in place to help give fair usage:

  • For interactive sessions, each user can use up to 16 CPUs (cores) across all jobs and up to 3 jobs at a time.
  • For batch jobs, there is no hard limit on the number jobs that can run at once. Instead, the scheduler will dynamically limit the number of jobs dispatched to run run based on past usage. This Fairshare scheduling ensures that everyone is able to run jobs. This is an upper limit of 16 cores/job, and we also cap a total of 100 CPUs in play at any one time.
  • There are currently no limits on RAM (memory). This may change as we find that underuse of requested RAM (RAM wasted) is a significant problem.

Unlike the previous grid, if you launch 3 Stata-MP4 sessions on the NoMachineNX server (which consumes a total of 12 cores), and then try to launch any other program, this program will not pend as long as it doesn't consume more than the remaining 12 cores. 

If your work requires resources beyond these limits, please contact Research Computing Services (RCS) so that we can arrange temporary exemptions.

Last Updated 8/9/19