The high-performance computing cluster, affectionately known as ‘Ada’, is a collaborative effort among faculty and ITS staff to increase access to computing resources for research and teaching purposes. The cluster is funded by a Major Instrumentation Research grant from the National Science Foundation, contributions of hardware from individual faculty and staff support from ITS. As a common pool resource, the cluster requires a shared understanding of proper use and purpose among its users. Below is a summary of the policies and understandings drawn up at the December 3, 2019 meeting (* denotes members present) among the grant recipients, contributors and ITS staff (hereafter: ‘working group’) for managing the cluster.
Setting and changing the rules
The working group established itself as the primary stakeholders in the cluster, contributing hardware and time to building and maintaining the cluster. These individuals include:
NSF Grant Participants
- Amy Yuen*
- Bert Johnson*
- Michael Linderman*
- Amanda Crocker*
- Erin Eggleston*
- Obie Porteous*
- David Munro
- Erik Bleich
- Chris Herdman*
- David Guertin*
- Bill Koulopoulos*
- Paul Dicovitsky
Currently, the working group has designated Amy Yuen to serve as director of the working group going forward. Decisions on usage policy and cluster management are to be decided in consultation with the working group, as needed and by majority rule.
Assessing the cluster
The working group recommended a periodic assessment of cluster usage every six months. These assessments should include total users, basic usage statistics (average number of jobs, CPU hours, storage capacity, idleness, software usage, etc.) and ITS time for the purposes of managing expansion and replacement of both hardware and software.
The working group identified a variety of needs and possible use cases for potential HPC users. Discussions of access included two general groups of users: faculty and students. Below is a description of the different profiles and mechanisms for how users access the cluster. Both groups will include users with varying levels of comfort working in a cluster environment, so general procedures for gaining access and accepting fair and appropriate use principles follow the description of user profiles.
Faculty are subdivided into tier 1 and tier 2 users. The two faculty tiers were created to give priority to faculty who are more likely to have high computational needs (tier 1). Faculty signal that need by contributing compute nodes to the overall cluster and are allocated priority CPU hours proportional to their contribution. Tier 2 faculty are any other faculty who need access to HPC resources but have not contributed hardware to the cluster. This tiered design avoids placing hard limits on any potential users but still ensures that those who are most likely to need its resources will continue to have access commensurate with their contributions to the architecture. Any faculty may request access from the HPC working group.
Student users are likely to take one of three profiles: student-faculty collaboration on research, members of a course with specific HPC needs or an individual student pursuing independent research/senior work. The working group considered these needs, the level of supervision required and the likelihood of each case in developing its policies.
- Student-Faculty Collaborative Research: these situations are common and generally involve close faculty supervision. In these cases, students will be granted access to the cluster through the faculty member’s cluster allocation.
- Student Access for Coursework: These are cases in which the faculty member intends for the class to use cluster resources as part of the assigned coursework. These are not cases of individual, independent student needs. The faculty member will consult with the working group director and ITS staff to produce a proposal defining access and limits for the class. Functionally, the cluster will use a group setup to grant student access which will expire at the end of the academic term.
- Student Access for Independent Work: The working group felt that this use case is at highest risk of reduced faculty supervision since students may be pursuing independent research that may benefit from HPC resources but may not be supervised by a faculty member with HPC proficiency. The working group anticipates this use case to be quite rare, and in these cases would negotiate directly with the supervising faculty member on whether and how to grant access, including appropriate supervision of the student’s work on the cluster.
Expectations and Support for Users
All HPC users will be expected to accept the standard Middlebury Code of Conduct relating to information and technology as well as a general set of best practices specific to the cluster. These will be posted on the HPC wiki page. Additionally, faculty who have little or no experience using a shared computing cluster are strongly urged to participate in the periodic training sessions offered by ITS staff and HPC-affiliated faculty.
Cluster Use Principles
The use of the Ada cluster is governed by all the policies that apply to Middlebury’s Information Technology and the following principles:
- The Ada cluster supports the research and educational missions of Middlebury College. Users agree to only run computational jobs related to those missions. For example, cryptocurrency mining for financial gain or commercial use of the cluster is not appropriate.
- The Ada cluster is a shared resource. Running computations that consume large portions of the cluster for extended periods (including consuming large portions of the available disk space) could prevent others from using this community resource. Exercise care in how you use the Ada cluster to be respectful of other community members’ interest in using the system.
- You are entirely responsible for any data you place on the cluster. You agree that your data management practices are in accordance with Middlebury’s policies and any applicable regulations or agreements, e.g. HIPAA, data use agreements, etc.
- The Ada cluster is intended for data analysis not data storage. Data is not backed up. Data that is no longer needed should be promptly deleted to ensure there is sufficient disk space for everyone.
- You agree to respect the privacy of other users, e.g. by not exploring directories owned by other users even if those directories are accessible to you.
- You are expected to report any security incidents or abuse to ITS immediately. Examples of security incidents include but are not limited to: unauthorized access or use, compromised accounts – including “shared” login credentials, and misuse of data.
Users whose behavior runs counter to these principles may be asked by clust
er administrators to leave the cluster.
1 Includes any other faculty who contribute nodes in the future.