Allocation Guidelines

Allocations are requested in Service Units which roughly translate to CPU Hours.  Your account is charged for the CPU time you reserve and make unavailable to others, not the amount of CPU time your job actually consumes.

Startup allocations:

  • 50K (50,000)SU
  • One time only
  • For CU faculty/staff/students only.  
  • No PI or Faculty supervision needed.
  • Not to be shared or given away.
  • Extensions possible upon reasonable request. Extensions are rarely granted other than for a short time to process a Project allocation request. More commonly the user should work with a PI to begin a Project when their Startup is exhausted or expired.

Startup allocations are offered to facilitate easy of access to the system for testing, proof-of-concept, and general familiarization with the systems without the need for a detailed proposal and PI (faculty) oversight.
 

A user is not allowed more than one startup allocation so that users transition to supervised work allocations with reporting requirements. Sharing of startup allocations is not allowed in order to prevent the pooling of startups by groups of users (to avoid doing a project allocation request) and to prevent the allocation being shared with outside collaborators, visitors, and others who must work on PI supervised allocations.


Project allocations:

  • Must have a PI/Faculty as the owner/supervisor
  • Can be any size
  • Can be renewed/replaced
  • Visitors and outside collaborators can be members and use the allocation
There are four types of project allocations:
  • Basic Project - Informed by work from a Startup or testing/scaling study allocation, the basic Project allocation defines the project, the computational plan, the efficient code and workflow, expected results, etc.  An example is an allocation for the first year of work in a multi-year project to be followed up by Follow-Up project allocation(s).
  • Testing/scaling study - essentially a supervised Startup for users who cannot get a Startup (who have already had one or are not eligible), or for instances where testing and scaling require more resources that a Startup can provide.
  • Bridge - To provide compute time to use during the request and approval process for a follow-up allocation.
  • Follow-up - Requests continued work on a Project that has had a full (typically one year) allocation in the past.  The project description,code and workflow can carry over but a new timeline and milestones should be defined.  The size of the request may change to reflect changing needs.
Allocations should be the "right" size and not arbitrarily large or small, or sized for quick approval rather than as appropriate to need. Your estimates should clearly inform the size request, or if this is not yet possible a Testing allocation should be requested to develop the request.