ARCC Administrative and Operational Policies

Introduction

The UW Advanced Research Computing Center (ARCC) is the University of Wyoming's core computational facility under UW's Division of Research and Economic Development. Our facility is tasked with supporting advanced computational needs of the UW research community. We are staffed by a team of system administrators and research computing facilitators with expertise towards supporting high performance computing and computationally intensive disciplines.

ARCC enriches research at the University of Wyoming through the administration of cutting-edge cyberinfrastructure hosted on site at the UW Campus, by providing pragmatic research oriented services and resources, and by facilitating the application of advanced computing and technologies among those in our research community.

This page serves as a landing point and index for ARCC policies applicable to all users accessing ARCC hosted resources. All policies and procedures are intended to ensure that UW resources are used effectively and in support of UW's greater research and academic mission.

1. General Policies

i. UW Acceptable Use Policy

ARCC clusters and UW resources are made available to the UW research community, and as such are covered by Unireg 8-1. All users of ARCC resources are required to adhere to UW regulations in addition to ARCC specific policies. All users should read and be familiar with this regulation as it is applicable to all UW resources and users must accept terms of use when requesting access to our resources, which includes adherence to UW Regulation 8-1.

Regulation 8-1 includes the following provisions which may be particularly applicable to users of the ARCC resources, but the list below is NOT complete and you are bound by all directives under the regulation:

“It is the responsibility of individuals to protect their access privileges, including any access codes or passwords, so that they are not used by any unauthorized persons.”
Protect your passwords and do not share your login information with others.
“The technology resources of the University are supported by State funds and are intended to be used primarily for University related activities that support teaching, learning, research, and service, including University administrative functions and student activities consistent with the University’s mission and learning environment.”
“Improper use [of UW resources] includes, but is not limited to, use for personal gain; use which intentionally interferes with legitimate use by others; and, use which violates any law or University Regulation”. Engaging in conduct that interferes with others' use of shared ARCC resources is prohibited and the use of ARCC resources for commercial or profit-making purposes is prohibited without written authorization from the University.

ii. ARCC Specific Acceptable Use Policy

In addition to the University regulations, the ARCC resources are subject to additional policy listed on our Policy page. The use of any ARCC resource requires compliance with all policies linked or referenced on UW ARCC’s Policies Pages. The process of requesting an allocation and/or account on a UW ARCC resource includes acceptance of any policies specific to the resource in your request. All terms of use apply to all ARCC resources.

i. Global User Prerequisites:
All ARCC users must meet prerequisites to use ARCC High Performance Computing (HPC) or Research Data Storage services.

Be a UWYO Faculty member, or have sponsorship from a UWYO faculty member.
Have an active UWYO Account or ARCC created HPC account.
Enroll in Two-Factor Authentication
Have access to Internet

ii. Global User Responsibilities:

ARCC users are accountable for their actions and while using ARCC resources. Violations of any university regulation, policy, procedure, and/or security may result in administrative or legal actions.

iii. PI Responsibilities:

Please see HPC Policy->HPC/HPS Accounts->PI Accounts for who qualifies as a PI.

User Account Requests: To obtain an account necessary to access ARCC resources, users must have approval from a Principal Investigator (PI).
A PI must request or approve of any user access to ARCC resources. PIs must also request or approve access changes on their managed projects. Additionally, all resource access should be associated with a project (either requested for creation or existing) on that resource. If an associated project does not exist on the resource for which the user account request is made, a project must be created in conjunction with the user account request.

PIs are responsible for ensuring that these policies, procedures, and security rules are followed for their project members and ensuring that project members working under their supervision fulfill these responsibilities.

Project Requests: Principal Investigators (PIs) are the only individuals that may request the creation of new projects, or request changes to their projects, unless the PI designates a project manager in writing. The project PI has the duty to oversee any projects created at their request.

PI's are responsible for ensuring that policies, procedures, and security rules are followed for their project members and ensuring that project members working under their supervision fulfill these responsibilities.

Designate Project Managers: PIs may identify designated manager(s) for their project(s). A designated manager (DM) is a project member allowed to request specific actions associated with a project on behalf of the project PI. Designated manager requests should be made in writing to ARCC and specify:

The individual granted DM status
The project(s) they are granted DM for
The associated actions on the project that may be requested by the DM on the PI’s behalf
Timeframe (if any) for DM designation

iv. Research Use:

ARCC resources may only be used for research activities and must never be used in the violation of any other university regulation.
The following categories of use (without limitation) are prohibited:

For personal or private benefit
In support of illegal, fraudulent, or malicious activities,
Facilitation of transaction(s) in violation of US Federal, or UW institutional export control regulations.

v. User Data Requirements:

Users of ARCC resources agree to store only data that meets the following conditions:

Is research data
is NOT covered by HIPAA or FERPA,
Does NOT contain personal information such as credit info, entertainment media, illicit material, SSNs or similar personal data and does NOT contain copyrighted material that the user doesn’t have appropriate rights to.

vi. Compliance with requests from ARCC

ARCC users are required to comply within a prompt timeframe to ARCC direct requests from regarding the use of ARCC resources. This includes requests to reduce disk space consumption or halting prohibited actions. ARCC purposefully aims to keep our list policies as short as possible in order to facilitate the use of these research tools in novel and creative ways, however, behaviors or practices that interfere with the ability of others to use shared resources, must be handled with immediacy and ARCC staff require prompt compliance on such requests.

vii. Monitor your provided e-mail account

You are required to monitor your USERNAME@uwyo.edu email address. If you are an external collaborator, you should monitor the email address provided to IT Application Security upon your account creation.

viii. Providing notifications

ARCC users should notify arcc-help@uwyo.edu immediately when aware that any accounts used to access ARCC resources have been compromised.
ARCC users should promptly inform UW of any changes in their contact information.
Upon actual or suspected loss, disclosure, or compromise of the two-factor authentication physical or virtual token and/or associated password, account holders should immediately notify the UW IT Security Office (IT_Security_Office@uwyo.edu). Two-factor authentication tokens must not be transferred to another person.

ARCC resources may only be used for activities authorized by the University and are always subject to Unireg 8-1. Prohibited actions include, but are not limited to, the following:

i. Unauthorized Use
Attempting to send or receive messages or access information by unauthorized means, such as imitating another system, impersonating another user or other person, misusing legal user credentials (usernames, passwords, etc.), or causing some system component to function incorrectly

ii. Altering Authorized Access
Changing or circumventing access controls to allow the user or others to perform actions outside authorized privileges

iii. Reconstruction of Information or Software
Reconstructing or re-creating information or software outside authorized privileges

iv. Data Modification or destruction
Taking actions that intentionally modify or delete information or programs outside authorized privileges

v. Malicious Software
Intentionally introducing or using malicious software, including, but not limited to, computer viruses, Trojan horses, or worms

vi. Denial of Service Actions
Using UW/ARCC resources to interfere with any service availability, either at UW or at other sites

vii. Pornography
Using UW/ARCC resources to access, upload, download, store, transmit, create, or otherwise use sexually explicit or pornographic material

viii. Harassment
Engaging in an offensive or harassing actions toward another individual or organization

i. ARCC Use by Foreign Nationals
ARCC use by foreign nationals is generally permitted regardless of whether access to ARCC resources is from the United States or abroad. However, the U.S. Department of Treasury’s Office of Foreign Assets Control (OFAC) regulations prohibit the of ARCC resources by citizens of Cuba, Iran, Syria, or Sudan while residing and/or working in one of those countries.

ii. Restricted Data
The use of UW/ARCC resources to store, manipulate, or remotely access information, software, or data (materials) that require additional controls or that could negatively impact or compromise administrative and business operations of ARCC resources requires prior written approval from the University. Such materials include, but are not limited to, export-controlled software or technical data subject to Export Administration Regulations (EAR) or International Traffic in Arms Regulations (ITAR); Personally Identifiable Information (PII) or health information subject to the Health Information Portability and Accountability Act (HIPAA), and materials subject to "Official Use Only" or similar government restrictions.

THE USE OF UW/ARCC RESOURCES TO STORE, MANIPULATE, OR REMOTELY ACCESS CLASSIFIED INFORMATION, UNCLASSIFIED CONTROLLED NUCLEAR INFORMATION (UCNI), NAVAL NUCLEAR PROPULSION INFORMATION (NNPI), SECRET RESTRICTED DATA (SRD), SPECIAL ACCESS REQUIRED DATA (SAR), THE DESIGN OR DEVELOPMENT OF NUCLEAR, RADIOLOGICAL, BIOLOGICAL, OR CHEMICAL WEAPONS, OR OF ANY WEAPONS OF MASS DESTRUCTION IS EXPRESSLY PROHIBITED.

UW/ARCC resources are operated as research systems and should only be used to access and store data related to research. These research systems are categorized as low per FIPS-199 and protected to the NIST 800-53 low-security control baseline.

iii. System Security
UW/ARCC resources control data access via username and password authentication for network access and UNIX directory and file permissions for data storage. Network access and data storage systems provide no explicit encryption. ARCC users are responsible for protecting data files and acknowledge and understand that UW/ARCC security control implementation is sufficient for research data access and storage.

vi. Software Licensing and Copyright Compliance

ARCC users must ensure that when using ARCC resources, all software is acquired and used according to appropriate licensing. Possession, use, or transmission of illegally obtained software on ARCC resources is prohibited.
ARCC users shall not copy, store or transfer copyrighted software or data using ARCC resources, except as expressly permitted by the copyright owner.
Installation of software on ARCC systems must include a valid license (if applicable). No software will be installed on the ARCC cluster(s) without prior proof of license eligibility.
Installation of commercial or licensed software will be performed in a best-effort manner. If the requirements for the software are outside the current configuration of ARCC systems, ARCC may reject the installation.

v. Data Retention

Users who leave UW: ARCC reserves the right to remove any data at any time and/or transfer data to other individuals (such as Principal Investigators working on a same or similar project) after a user account is deleted or permanently deactivated, or a user no longer has an association with UW/ARCC.
Data backups:
- Although ARCC takes steps to ensure the integrity of stored data, ARCC does not guarantee that data files are protected against destruction. ARCC users should read the information on data retention, backups, and data deletion in any applicable policies for the ARCC resources they use, and make backups of necessary data and software in an archive system or at other sites.
- In some cases, ARCC may elect to make backup copies of some data files. When backup copies are made, ARCC reserves the right, at its sole discretion, to hold such backup copies indefinitely or to delete them.

i. Repercussions
If it has been determined that you have violated any of the ARCC resource policies, or any other UWYO computing policies, your account(s) will be deactivated immediately. Your account will not be reactivated until the ARCC director receives a formal request from the Principal Investigator of your project.UW personnel and ARCC users are required to address, safeguard against, and report misuse, abuse, and criminal activities. Misuse of ARCC resources can lead to temporary or permanent disabling of accounts, loss of access to ARCC resources, and administrative sanctions or legal actions.

i. The information contained in the Privacy Policy, Terms of Use Policy, and any other ARCC policies should NOT be construed as giving legal, professional, or any other advice.

ii. The content of this site is provided by ARCC and UW researchers as a service to the UW research community without any warranty of being accurate, current, or applicable to any particular use. The University makes no express or implied warranty with respect to the use of ARCC resources. Neither the University nor ARCC shall be liable in the event of any resource failure or loss of data

2. ARCC HPC Policies

ARCC's SLURM HPC Scheduling Policy is subject to adjustments. These proposed changes are intended to improve and incentivize the following:

Encourage fair-share access to ARCC resources and limit disproportionally dominant HPC resource utilization by any individual or a single research group.
Prioritize Access for Funded Research.
Incentivize HPC Investment for Priority Access.
Spur innovation by maintaining a level of free services available to the overall University of Wyoming research community.

i. Login Node Provisioning
Login nodes are provided for authorized users to access ARCC HPC cluster resources. These nodes are intended for specific purposes only and should only be utilized for these specific use cases. Users may set up and submit jobs, access results from jobs, and transfer data to/from the cluster, using the login nodes.

ii. Unauthorized Login Node Activities:
As a courtesy to your colleagues, users should refrain from the following on login nodes:

anything compute-intensive (tasks that use significant computational/hardware resources - Example: utilizing 100% of cluster CPU)
long-running tasks (over 10 minutes)
any collection of a large number of tasks that results in a similar hardware use footprint to the actions listed previously.

Computationally intense work performed on login nodes WILL interfere with the ability of others to use the node resources and interfere with community user’s ability to log into HPC resources. To prevent this, users should submit compute intensive tasks as jobs to the compute nodes, as that is what compute nodes are for. Submitting batch jobs or requesting interactive jobs using salloc to the scheduler should be performed from login nodes. If you have any questions or need clarification, please contact arcc-help@uwyo.edu.

Short compilations of code are permissible. If users are doing a very parallel or long compilations, a request should be made for an interactive job, and users should then perform compilation on nodes allocated after requesting an interactive job using an salloc as a courtesy to your colleagues. If you’re not sure how to do this, see an example requesting an interactive job on our wiki.
If ARCC staff are alerted of computationally intense work or jobs being performed on a login node, they may will kill them without prior notification.
Do NOT run compute-intensive, long-running tasks, or large numbers of tasks on the login nodes.

iii. Violations and Repercussions
Tasks violating these rules will be terminated immediately and the owner will be warned, and continue violation may result in the suspension of access to the cluster(s). Access will not be restored until the ARCC director receives a written request from the user’s PI.

HPC/HPS accounts are available for all University faculty, staff, and students for research

i. Account as a PI
Principal Investigator (PI) may request an account and project on any ARCC resource for research purposes.
In order to create an account on a resource, an associated research project must be created on that resource.

Who qualifies as a PI?
Principal Investigators (PIs) are any University of Wyoming faculty member with an extended-term position with UW. This designation does not extend to Adjunct nor to Emeritus Faculty. See more about PI Responsibilities above (Under General Policies: 1 -> User Responsibilities: B -> PI Responsibilities: iii)

ii. Account as a member of a HPC Resource Project
All accounts with access to ARCC resources must be approved by a University of Wyoming Principal Investigator (PI).
PIs give permission to a user to use the HPC/HPS resource allocations as a member of their project(s).

PIs may sponsor multiple users.
Users can be sponsored by multiple PIs. Removing a user from a project does not necessarily mean the user is removed from the resource, if they retain membership to another PI's project on that resource.
HPC/HPS resource allocations are granted to PIs as projects. Users utilize resources from their sponsor's allocated project on that resource.

iii. Account General Terms of Use

The following conditions apply to all account types. Additional details on how the different account types of work can be found elsewhere on this page.

All HPC accounts are for academic purposes only.
Commercial activities are prohibited.
Password sharing and all other forms of account sharing are prohibited.
Account-holders found to be circumventing the system policies and procedures will have their accounts locked or removed.

iv. Accounts and Requesting an Account

All HPC accounts can be requested through the ARCC Account Request Form. Note that all requests, for creating projects and making changes to a project, must be made by the project PI as specified above, and only the listed project PI may request a user be granted access to their project**  
For questions about HPC account procedures not addressed below, please e-mail us at arcc-help@uwyo.edu

v. Account Types

PI Accounts
PI accounts are for individual PIs only. These accounts are for research only and are not to be shared with anyone else. PI accounts are subject to periodic review and can be deleted if the PI's University affiliation changes or they fail to comply with UW and ARCC account policies.
Project Member Accounts
PIs may request accounts for any number of project members, but these accounts must be used for research only. UW PIs are responsible for all of their project members. These accounts are subject to periodic review and will be deleted if the PI faculty member or the account holders change their University affiliation or fail to comply with UW and ARCC account policies.
External Collaborator Accounts (To be replaced by ARCC-Only Accounts)
Prior to the implementation of ARCC-Only accounts, PIs went through UW Information Technology to request UWYO federated accounts for non-UW users collaborating on their research projects. These accounts granted the external collaborator access to the PI's project on ARCC resources.
ARCC Only Accounts
These are accounts are not associated with UWYO federated login nor UWYO enterprise technology resources. They are created by ARCC and explicitly grant access to designated ARCC resources. Like all other project member accounts, they must be requested by the project PI and PIs are responsible for the account users access and actions on the resource.
Instructional Accounts
PIs may sponsor HPC accounts and projects for instructional purposes on the ARCC systems by submitting a request through the ARCC Account Request. Instructional requests are subject to denial only when the proposed use is inappropriate for the systems and/or when the instructional course would require resources that exceed available capacity on the systems or substantially interfere with research computations. HPC accounts for instructional purposes will be added by the Sponsor into a separate group created with the 'class group' designation. Class group membership is to be sponsored for one semester and the Sponsor will remove the group at the end of the semester. Class/Instructional group jobs should only be submitted to the 'class' queue, which will be equivalent in priority to the 'windfall' queue, and only available on the appropriate nodes of the ARCC systems.
System Accounts
System accounts are for staff members who have a permanent relationship with UW and are responsible for system administration.

vi. Account Lifecycle

Account Creations
ARCC HPC/HPS accounts will be created to match existing UWYO accounts whenever possible. PIs may request accounts for existing projects/allocations or courses.
Account Renewal
If an account or project is specified with an end date, and needs to be extended beyond that date, a renewal of the account (and if necessary, member project) is required.
Account Transfer
A PI who is leaving the project or the University can request that their project be transferred to a new PI. Any non-PI accounts can be transferred from one PI's zone of control to another as necessary as students move working from one researcher to another. Account transfer requests will also be made by contacting the Help Desk (766-4357).
Account Terminations
The VP of Research, the University and UW CIO, and University Provost comprise the University of Wyoming's Research Computing Executive Steering Committee (UW-ESC). The UW-ECS will govern the termination of Research Computing accounts, following other University policies as needed. Non-PI accounts may be terminated at the request of the UW-ESC. Any users found in violation of this Research Computing Allocation Policy or any other UWyo Policies may have access to their accounts suspended for review by the Director of Research Support, IT, and the UW-ESC.

** - unless otherwise designated by the PI with documentation (i.e., in cases of a designated project manager), and acknowledged by ARCC.

This policy is subject to proposed revisions and approval. Please see this page to review a detailed description of proposed changes.

i. Job Submissions

a. All job submissions require the specification of an account. Based on wall time and/or quality of service, a job will be placed in one of several queues. If no partition, QoS, or wall-time is specified, a job, by default, will be placed in the Normal queue with a 3 day wall-time.

b. Job submission syntax will remain largely the same, except that users should supply a Quality of Service (QoS) to put their work into a prioritization queue. If a user does not supply a QoS or wall time in their job submission, they will, by default be placed into the Normal queue. Queue information is detailed below under Queues/QoS Types. Users are incentivized to specify shorter wall times so their jobs are given priority to run, and thereby placed in a queue with a shorter queue time frame when the cluster is under high utilization.

c. Job submissions will have a partition set for them if not supplied. This will work in a specific order of 'oldest' hardware to 'newest'. This will ensure the newer hardware is available for jobs that require it, and less intense jobs are sent to older hardware.

ii. Reservations

a. Our department has found that PIs are more frequently using ARCC systems in the classroom or for instructional purposes. If resources are required during a specific time window, we strongly encourage PIs to request reservations when using part of the cluster in an instructional setting.

b. Reservations must be requested 21 days prior to the start of the reservation period. This advance notice is necessary to account for the scheduling of personnel needed to configure reservations, and the 14-day maximum job wall time.

c. This is critically important for classes running interactive sessions. Reservations must be requested and configured to guarantee timely access.

iii. General Account and Project Limitations

a. No single SLURM defined account or HPC project may occupy more that 33% of the cluster + their investment allocation. This will be set per SLURM Account (AKA project, not per user).

b. Users can no longer specify all memory on a node using the --mem=0 specification in their submission. Users must explicitly specify how much memory they need. This will reduce the likelihood that users request a disproportionally large segment of available HPC memory and thereby reduce likelihood that such portions would be assigned by the SLURM scheduler to any given job. Alternatively, --exclusive may be used but will request all resources on the node. This will ensure accurate utilization in reporting.

c. Users cannot use a GPU partition without requesting a GPU. Users will be required to request a GPU (and potentially be billed for that use) if they use a GPU node. This does not apply to investments with GPUs.

iv. Queues/QoS Types
ARCC has created the following queues and Quality of Service (QoS) as a function within SLURM allowing for configuration of preemption, priority and resource quotas for different purposes. Each is detailed below:

Queue/QoS Name	Priority	Maximum Specified Wall Time	Limitations	Purpose
Debug	n/a	1 hour	Limited to a small hardware partition, limited in job size	For debugging job submissions, code issues, etc.
Interactive	1	8 hours	Limited to interactive jobs	Hosting interactive jobs and imposing a short wall time to ensure fair use.
Fast	2	12 hours	None outside of the general account/project limitations**	For any normal jobs that will not take an extended amount of time. Higher priority means the user's job will run quickly and the shorter wall time means the scheduler may prioritize more efficiently.
Normal (Default)	3	3 days	None outside of the general account/project limitations**	This is the default queue. The shorter wall time is still liberal, but will allow the scheduler to manage resources effectively.
Long	4	7 days	Limited to 20% of overall cluster + Investment**	To allow for jobs requiring a longer wall time. This flexibility benefits users with longer-running workloads while not overwhelming the entire cluster.
Extended	5	14 days	Limited to investors Limited to 15% of cluster total Limited with respect to number of jobs in queue per project**	To encourage investments to ARCC providing investors more flexibility.

** Interactive jobs may not be run in this queue

a. Debug
This queue consists of a small subset of HPC hardware with rigid limitations. Priority is not applicable since this queue falls outside of normal Slurm scheduling and standard scheduling policies. This is a specialty partition. Submissions will be subject to partial node allocations, and debug jobs may not request the entire node.

b. Interactive
The Interactive queue is used for all interactive jobs, and such jobs are given the highest priority when jobs are submitted. All interactive jobs are subject to a maximum 8 hour wall time.
This includes:

1. Interactive desktops (Including On-Demand XFCE Desktop Sessions)
2. On-Demand applications (Jupyter, XFCE Desktop Sessions, Matlab, Paraview, and all sessions launched through web the based OnDemand Platform, https://medicinebow.arcc.uwyo.edu)
3. Jobs requested via an salloc command.

c. Fast **
The Fast queue is given highest priority for typical job specifications. It should have a shorter wall time of 12 hours to encourage rapid clearing of open devices for use, and will allow the Slurm Job Scheduler to effectively and more quickly manage any job backlogs.

d. Normal (Default) **
This queue is the default queue for any job submitted without a specified wall time or QoS. It will have standardized priority, and should be subject to larger wait time than the fast queue to run a job.

e. Long **
The Long queue will allow for 7-day jobs to account for jobs that require this substantial duration, but will be limited in scope encouraging shorter wall times and higher overall HPC resource availability. This is subject to the 20% of overall cluster + Investment limit detailed in the above table.

f. Extended (Investor-Only/Discretionary) **
To encourage investment, ARCC investors and their project members will be able to use a 14-day wall-time on any node. This allows them to run longer jobs, but also allows ARCC to implement maintenance windows as required. Priority level is 5 (outside of investments when discretionary). Investors will be able to use a longer wall time on ANY node however can preempt jobs only on nodes they have invested. Limit to number of resources outside of investment is 15% HPC resources + Investment.

v. Wall Time extensions
Users may e-mail arcc-help@uwyo.edu to request an extension for long-running jobs. Approval will not be guaranteed, is discretionary, and will be dependent upon current HPC usage, and justification.

The following table describes HPC service quotas applicable only to UWYO internal users and quota applies on top of any Investment Allocations.

HPC Compute
MedicineBow CPU Hours	Compute hours on MedicineBow CPU Node	*up to 100,000 total non-investment CPU core hrs/year
MedicineBow A30 GPU Hours	Compute hours on MedicineBow A30 GPU Node	*up to 20,000 total non-investment GPU hrs/year (GPU hrs are calculated as combined sum of all GPU hours over 1 year, independent of GPU hardware)
MedicineBow L40S GPU Hours	Compute hours on MedicineBow L40S GPU Node
MedicineBow H100 GPU hours	Compute hours on MedicineBow H100 GPU Node
Data Storage
MedicineBow HPC storage (Formerly known as Beartooth/TetonCreek)	HPC/Cluster storage. No backups by default, 20 day snapshots available upon request *All /gscratch storage is subject to a 90 day purge	50GB /home 5TB /gscratch WildIris associated projects 1TB /gscratch 5TB /project WildIris associated projects 2.5TB /project

3. Software Policies

i. ARCC Software Support Agreement
UW ARCC personnel will help UW users with

Consultations on software capabilities and acquisition expertise

Guidance with respect to software installation and deployment, and secured/controlled access
Support with respect to the efficient and effective functioning of software (where not provided by software vendor)
Software updates to maintain currency with the vendors and ARCC systems

General software usage, functionality, and application questions should be addressed by the research computing community. To support the community support model, ARCC makes a community-driven Known Error Database in the form of a Wiki available.

ii. Policy Review
ARCC reviews the software policy annually during the Change Advisory Board meeting with input from the Faculty Advisory Committee (FAC) members.

i. Supported Software
ARCC will maintain a list of currently supported software for each HPC system that ARCC supports. Supported software is evaluated biannually. The ARCC reserves the right to discontinue support for underutilized software. Software proposed for discontinued support will be placed in a "deprecated" section of the software modules interface. Movement of applications to a deprecated status will happen twice per year during system upgrades.
ii. Requests for continued support
Faculty can submit a request for continued software support of deprecated applications by e-mailing arcc-help@uwyo.edu

iii. Consultation Requests
Requests for software installation consultation must be initiated by a faculty member via the ARCC Software Consultation Request. The information on this form (e.g. estimates on the number of users, software and licensing details, software cost, and the timeline for installation) will be utilized to determine the degree of support provided by the ARCC.

i. Financial Support

Whenever possible, researchers are encouraged to use open-source software. The costs for discipline-specific, proprietary software will typically be born by the PIs requesting the software. A small number of one-time 'seed funding' opportunities may be made with input from the FAC. Financial support for the software is dependent on the user base, as follows:

Single PI or department: The license for the software is purchased by the user and his/her department. ARCC will handle acquisition, installation, and support on ARCC resources.
Multiple PIs or departments in a single College: The license for the software is purchased by the college. ARCC will handle acquisition, installation, and support on ARCC resources.
Broad Use (Multiple Colleges): If the software (e.g. MatLab or Mathematica) serves both significant academic and research uses, then funding by will be reviewed by UW-IT. If the software serves significant research uses only; then the ARCC will review funding. ARCC will handle acquisition, installation, and support on ARCC resources.

ii. Technical Support

ARCC staff will provide support in the identification of efficient and cost-effective software packages to meet the research objectives of faculty members. Where suitable the ARCC will coordinate software acquisitions of faculty with similar objectives to better leverage research investment.

i. Licensing Support
ARCC, with the help of UW-IT and UW General Council, will help provide guidance on research software licensing and suitable installation/controlled access.

ii. Technical Support
ARCC staff will provide software installation support and consultation for software to be run on ARCC resources. Department IT consultants will help with the installation of software on researchers' workstations. Requests from IT may be made by e-mailing userhelp@uwyo.edu. ARCC will also provide centralized license server services for software on ARCC resources when needed.

i. Software Support
Staff will provide software support with respect to efficient and effective software functions (where not provided by the software vendor). ARCC may also oversee and implement software updates to maintain currency with both the software vendor and ARCC resources.

ii. Software Development
ARCC will endeavor to facilitate code development subject to personnel availability.

4. Storage Policies

ARCC provides two options for research data storage. Alcova, and Pathfinder. As of June 1st, 2024, Alcova will begin migration from Alcova to ARCCs Data Portal. Research Data Storage on ARCC’s Data Portal, HPC Storage, and Old Alcova are subject to default quotas as listed on our DRAFT pricing sheet under Costs and Charges (5.)

i. Intended Use
ARCC high-performance storage system (HPS) for MedicineBow is a high speed, tiered storage system designed to maximize performance while minimizing cost. Beartooth is intended to be used for storing data that is actively being used.

ii. Best Practices
The following policies discuss the use of this space. In general, the disk space is intended for support of research using the cluster, and as a courtesy to other users of the cluster, you should try to delete any files that are no longer needed or being used. All data on the HPS, are considered to be related to your research and not to be of a personal nature. As such, all data is considered to be owned by the principal investigator for the allocation through which you have access to the cluster. MedicineBow is for the support of active research using the clusters. You should remove data files, etc. from the cluster promptly when you no longer actively working on the computations requiring them. This is to ensure that all users can avail themselves of these resources.

iii. Backup Policy
None of the MedicineBow file systems are backed up. We do data replication within the file system in order to minimize the loss of data in case of a system fault or failure.

Each individual researcher is assigned a standard storage allocation or quota on /home, /project, and /gscratch. Researchers who use more than their allocated space will be blocked from creating new files until they reduce their use.

Service Name	Description	Default Quota (ARCC services provided at no cost to UW Researchers)
Data Storage
MedicineBow (prior working name, “Thunderer”) HPC storage (Formerly known as Beartooth/TetonCreek)	HPC/Cluster storage. No backups by default, 20 day snapshots available upon request *All /gscratch storage is subject to a 90 day purge	50GB /home 5TB /gscratch WildIris associated projects 1TB /gscratch 5TB /project WildIris associated projects 2.5TB /project
Data research storage (Formerly known as Alcova)	General research storage On-Site Backups and 20 day snapshots included	2TB / project
Pathfinder S3 Storage	S3 bucket storage, on-premises. *On-site backups by user request and subject to cost above quota.	N/A All Pathfinder storage is charged based on allocation and private/secure key.

/home Personal user space for storing small, long term files such as environment settings, scripts, and source code.

/project Project-specific space shared among all members of a project for storing short term data, input, and output files.

/gscratch User-specific space for storing data that is actively being processed. This storage is subject to purge policy and should not be used for long term storage.

/lscratch Node specific space for storing short-term computational data relevant to jobs running on that node. Files are deleted nightly.

Researchers working with or generating massive data sets that exceed the default allocations or quotas, or tha have significant I/O needs should consider the following options:

Rent space on shared hardware: There is a set price per TB per year. Please contact ARCC for the exact pricing.
Purchase additional storage disks to be incorporated into HPC: This option is appropriate for groups that need more space than the free offering, but don’t have the extreme space or performance demands that would require investing in dedicated hardware.
Buy your own dedicated storage hardware for Research Computing to host: If you need more than about 15 TB of storage or very high performance, dedicated hardware is more economical and appropriate. The exact choices are always evolving. Please contact ARCC for more information.

ARCC HPC file deletion policy is based on directory as described above in directory descriptions:

/home: Home directories will only be deleted after the owner has been removed from the university system.
/project: Project directories will be preserved for up to 6 months after project termination.
/gscratch: Files that have not been accessed in 45 days can be purged. Data may be deleted as necessary.
/lscratch: Files are automatically removed after 14 days.

Please see Policy (5.) on Costs and Charges, below

i. One-Time Increase Requests Process and Provisions
If users require quota increases on Beartooth file storage, they may apply for a one-time, no-cost capacity increase by providing written justification for the amount of extra storage and it’s benefit to the UW mission of research, education and economic development.

This capacity increase lasts for the life of the storage system (typically 3 years), the increase must be approved by ARCC Leadership, and is subject to a 10TB max limit.

ii. Costs associated with section 4E, Capacity Increase Options
In all other cases, the user will be charged per Cost of Resources as listed below in Policy Section 5.

Users may request capacity increases on the ARCC Service Portal.

5. Costs and Charges

i. Investments:
ARCC operates its HPC clusters via an investment model. A UW researcher may invest into compute nodes on the ARCC HPC clusters by funding their purchase. This gives them priority access to those specific nodes, meaning that any jobs running on the investment nodes at the time of request by the investor, will be killed in order to give the investor access. ARCC owns those nodes. Investment buys priority access, not ownership, for the investor. The cost of nodes is based on current market conditions and is shown in this regularly updated page: Node Purchase Estimates.

ii. General (non-investment) cluster usage
General cluster usage is free for UW faculty, staff and students within an approved UW research project. If a general-user job lands on an investor’s node, it can be pre-empted (killed) when the investor requests access. Checkpointing the jobs for the purpose of continuing computation on a different node is the responsibility of the users.