- Data Portals
- User Support
- About Us
Actively managing and monitoring your allocation of computing and storage resources will help ensure that you use these resources as efficiently as possible.
Here are some guidelines:
Allocations are made to the project lead who is designated in the allocation request. The project lead often is the principal investigator (PI) for the associated funding awards, but need not be.
The project lead may designate a project administrator (project admin) who can request actions on behalf of the project, such as adding or removing users. To designate a project admin, submit a request to CISL Help.
On the allocation request form, you have the opportunity to identify users who are authorized to share access to a project's allocation. PIs, project leads, and project admins can add new users to their projects any time after receiving an allocation award.
To add new user accounts for a project, submit a request by email to CISL Help or call 303-497-2400.
Include the user's name, email address, phone number, and a full shipping address for delivery of the new user's authentication token. You do not need to include a shipping address if the user already has a CISL token.
A PI, project lead, or project admin can deauthorize or remove a user from a project by sending the user's information to CISL Help.
A user account must be associated with at least one allocated project and may be associated with more than one. You will have an alphanumeric project code for each such project. These project codes are used to charge your use of computing and storage resources against the appropriate allocations. Take care to specify the correct project code when you submit jobs or write files to HPSS.
Charges for using the Yellowstone, Geyser, and Caldera systems are assessed in adjusted core-hours, which is essentially the number of processor cores used multiplied by the duration of the job in hours and modified by queue priority.
If you are concerned about your usage rate, contact CISL for guidance on running jobs more efficiently and conserving your allocation. Sometimes jobs can be configured to make better use of the processors, and you may be able to save core-hours by running in a less expensive queue. Seek help from us if you notice anything amiss with your allocation.
All Yellowstone jobs (in any queue) and jobs in the exclusive-use queues on Geyser and Caldera are charged for exclusive use of the nodes by this formula:
wall-clock hours × # nodes used × # cores per node × queue factor
The Yellowstone and Caldera clusters have 16 cores per node; Geyser has 40 cores per node.
Charges for jobs submitted through the shared-use "geyser" and "caldera" queues are calculated using this formula:
core-hours × queue factor
In this case, core-hours are derived from the recorded UNIX processor-seconds consumed by the job divided by 3600 (to convert seconds to hours).
# terabytes × # years
Terabytes is the total number of terabytes held on storage media at the time of the weekly accounting run. Years is the fraction of a year until the next accounting run, which typically is seven days.
A project has 25 TB of data stored on HPSS. When accounting records are generated that week, the weekly charge will be:
25 × (7/365) = 0.48 TB-years
Storing 25 TB for one year would result in charges of 25 TB-years.
If you have a user account for the Yellowstone system and a UCAS authentication token or password, you can track your usage in the CISL Systems Accounting Manager (SAM). SAM reports show usage data and charges against allocations for both computing and storage. Charges for computing are calculated and updated daily; storage charges are updated weekly.
Janus—Allocations and charges for use of the Janus cluster at the University of Colorado, Boulder, are assessed in Service Units (SUs), which are equivalent to Janus core-hours. There are no queue priority factors that modify job charges. See Quick start for NCAR users: Checking usage.