Zorro, the AU High Performance Computing (HPC) System is managed by the HPC Liaison Committee; the policies on this page (download PDF) were developed by the Committee. The user policies below aim to
- help make the system effective for users,
- ensure proper maintenance of the system,
- document use of this federally-funded facility
- enable researchers to contribute to the system
This webpage always shows the policies currently in effect. Policies are continually reviewed and updated by the HPC Committee. Questions or concerns should be e-mailed to firstname.lastname@example.org.
It is key that all users have access to the HPC system and that the integrity of all users’ code is maintained. Following some of these policies is likely to require that you understand the nature of HPC computing and the configuration of the hardware and software on the system. Please contact email@example.com to ask questions or to report problems.
If a user does not abide by the policies, a representative of the HPC Liaison Committee has the right to terminate the user’s jobs and/or to suspend the user's account.
Users must use the batch submission system of the scheduler:
- Users may not log into the compute nodes for the purpose of running a job directly without permission from the HPC committee.
- If you believe interactive use of a node is necessary for your research please send a request to firstname.lastname@example.org.
Users must monitor the e-mail address on file with the HPC committee and are required to respond in a timely way to correspondence from the HPC Committee.
- Active communication is often necessary for effective management of a shared resource such as this HPC system.
- Users will be notified by e-mail about issues related to the system, such as scheduled downtime, upgrades, etc.
- Requests for information and feedback about system use and access will be made by e-mail.
Obtaining an Account
Costs of Use
There is no up-front cost for use of the American University HPC System. AU faculty PIs and students are encouraged to use the system to obtain preliminary results and to leverage their preliminary results into external funding (see Maintaining Access below). Externally funded users are encouraged to contribute funding to the facility. Users who provide financial support for the AU HPC System at the rate of $1000 per year will have 500 node-hours of priority access per month for 12 months, and a total guaranteed usage of one node-year for the year.
Who May Have An Account?
- Any AU faculty PI whose project has computational needs are beyond the capacity of his or her current workstation may apply for an account. The account can be accessed by all members of the research team on the project. (See Faculty Account Form.)
- Students (undergrad or grad) who are sponsored by an AU faculty PI to do independent research may apply for an account. (See Student Account Form.)
- Users from outside the AU community may also apply for an account for academic research, especially for research that includes an AU co-PI. The HPC Liaison Committee chair will be happy to assist in locating an AU co-PI. Please send inquiries to email@example.com.
The Chair of the HPC Liaison Committee reviews and approves requests for accounts continually. The Chair consults the Committee regarding special requests. User account status is reviewed annually by the Committee.
Submitting Jobs on the Cluster: Queues and Resources
User access to compute nodes is managed by software called a scheduler. The scheduler reserves available nodes and other resources according to the queue that a user can access. The queues are managed so that the AU's research capacity is maximized.
There are four queues on the cluster. Three are open to all users;one is a restricted. Each queue has a different runtime limit and resources (CPUs) associated with it. As a rule, compute-intensive jobs (such as computing certain statistical estimators) are allowed use more resources over a short period of time. Jobs that require long run times (such as simulations or real-time modeling) are allowed fewer resources so that these jobs do not create bottle-necks for other users.
Queues that are open to all users:
Normal: This is the default queue. If you do not specify another queue when you submit a job, your job will run in the normal queue. The normal queue has a runtime limit of 48 hours. Users can request up to 36 CPUs / job slots when they submit a job.
Long: The long queue is for jobs that are expected to run longer than 48 hours. The runtime limit in this queue is 240 hours. Users can request up to 24 CPUs /job slots. If a User finds that jobs submitted to the normal queue are terminated before completion, he or she should resubmit the job to the long queue.
Short: This queue is for compute-intensive jobs that are not expected to run longer than two hours. Runtime limit in this queue is 2 hours. Users can request up to 60 CPUs / job slots. Again, users specify the short queue when the job is submitted.
Special- purpose/restricted queues:
Priority: The priority queue is reserved for users who provide financial support for the AU HPC System, including its initial funding. Jobs submitted by priority users go to the front of the queue they requested.
Note: System administration and testing of the machine may interrupt jobs. System administrators will notify Users if maintenance or testing is expected to impact job run-time.
Each user has an obligation to help to sustain the AU HPC System. While financial support will help grow the system, the most important way each user sustains the system is by demonstrating that it contributes to ongoing research.
- Acknowledge the use of the HPC system in papers and presentations. A recommended acknowledgement is "Computing resources used for this work provided by the American University High Performance Computing System, which is funded in part by the National Science Foundation (BCS-1039497); see www.american.edu/cas/hpc for information on the system and its uses."
- Confirm that user accounts are still needed when requested.
- Update Titles and Abstracts for each research project being conducted on the HPC system when requested. (Requests are planned to coincide with FARS due dates.)
- Provide information on presentations, working papers, and publications based on work using the HPC system. We are happy to post PDF files of papers or presentations on the facility's webpage or point a link to another webpage. (Requests for updates are planned to coincide with FARS due dates.)
- Be willing to participate as co-PI or co-investigator in future grant proposals in support of the HPC system (faculty users only).
- Include budget requests for computational resources in individual grant proposals. The support requested should reflect resource use expected for the project; use the cost per node for cited above is a guide. HPC Liaison Committee members and users will cheerfully assist with proposals in whatever way will be most helpful (including but not limited to: drafting text, acting as co-PI/co-investigator, supplying a letter of support). E-mail firstname.lastname@example.org early in your proposal process.
The HPC Liaison Committee manages the AU HPC System. New members will rotate onto the committee for two-year terms.
Contact the Committee at email@example.com.
Duties of the HPC Liaison Committee include:
- advising OIT and CTRL staff on decisions regarding setup, maintenance, and operations of HPC resources
- coordinating with OIT to monitor utilization of processing and storage capacity
- informing faculty (especially new faculty) and students about availability of HPC resources
- reviewing requests for priority use of shared HPC resources that might affect other users
- reviewing requests for storage of data files over the typical allocation
- reviewing requests to install new software; communicating concerns about system operations from researchers using the HPC resources to OIT and CTRL staff
- tracking outcomes of research projects completed using the HPC system
- reviewing requests for external access
- coordinating participation in SURAgrid
- coordinating training of users in parallel-capable code and applications;
- organizing a regular seminar to share research results, to encourage use of the system, and to foster interdisciplinary research.