There are three tiers of allocations for CPU time:
Base Allocations are given to all ASU researchers who apply. For the 2007 fiscal year, the base allocation is 10,000 CPU-hours for Fulton School researchers (and other participating units) and 5,000 CPU-hours for all other ASU researchers. Allocations are tracked by principal investigator (i.e., a faculty members usage includes all of their graduate students and postdocs). A base allocation includes 10GB of home directory storage space.
Committee Allocations are granted through a proposal process to a faculty committee. Directions for the proposal process, click here. In FY08, the committee will allocate approximately 2 million CPU-hours. Requests can be for up to 200,000 additional hours beyond the base allocation. The committee judges allocation requests based on the research merit, the sponsored research supported, the potential for new research to be developed, and results from past allocations.
Purchased Allocations are additional CPU time a faculty member acquires through grants or charges. Purchases can take the form of direct charges for cycles or through contributions of hardware (there is flexibility in the type of charge to support most agency grant programs). A2C2 staff are happy to work with faculty to incorporate the most appropriate mechanism in research proposals. The rate for direct cycle charge for FY10 is $0.025 per CPU-hour.
To check the CPU hour allocation allotted to you, run
. The allocation will be listed by project.
CPU Hours are the number of CPUs for the job times the amount of time the job takes to run. All times are rounded to the nearest second. For example, if you have a job that takes 3 hours to run on 64 processors, you will have used 3*64=192 hours.
When you submit a job you must specify the amount of walltime you expect the job to take. The system will then check to see if you have enough hours, then reserve that number of hours, from our example 192 hours. When the run is completed, the actual amount of time used will be deducted and the reserve will be released. It is a good idea to leave a little extra time in your estimate. Note the word little, because any time that is reserved cannot be used on another job. For example, If you have 100 hours in your account and two jobs that have 100 CPU Hours estimated (number of processors * walltime), only the first job submitted will run, even if each job only uses 1 hour.
Jobs can run slightly over their walltime estimates before being killed.
If you have a job that is hard to estimate a walltime for (say a convergence problem), checkpoint the job so it can be restarted. As the job can be restarted from about where it left off, you can control how much time is reserved and not be worried about a particular sequence taking longer than expected.
If you are running code for a different project than your default, add
to your jobscript.
