ARCC Policies

1. Scope and Applicability
   1. These policies apply to all users of ARCC resources (HPC clusters, storage, and associated services). Users must also comply with University of Wyoming regulations (Unireg 8-1) and any other UW policies referenced here.
   2. Access to ARCC resources requires acceptance of these policies during account/project request.
2. Definitions
   1. ARCC: Advanced Research Computing Center (ARCC) resources and services.
   2. PI: Principal Investigator — a qualifying UW faculty / research staff member authorized to create and manage projects and sponsor users.
   3. Project: An ARCC resource allocation assigned to a PI (or designated manager) and used by project members.
   4. Investment / Investor: A funded hardware purchase that grants priority access (not ownership) to specific nodes.
   5. Normal usage: Use that does not require preemption, reservation, or priority access.
3. Acceptable Use and Prohibited Activities
   1. Purpose: ARCC resources are provided for authorized research, teaching, and university-related activities only.
   2. Prohibited uses include (non-exhaustive):
   3. Commercial/profit-making use without written University approval
   4. Activities that interfere with others’ access or system operations.
   5. Illegal, fraudulent, or malicious activity or activity that violates export controls (EAR/ITAR) or other laws.
   6. Storing or processing sensitive protected data without prior written University approval (e.g., HIPAA, FERPA, classified data, or other restricted categories).
   7. Introducing malicious software or performing denial-of-service actions.
   8. Accessing or hosting sexually explicit material or engaging in harassment.
   9. Circumventing access controls, impersonation, or misuse of credentials.
4. User and PI Responsibilities
   1. User prerequisites:
   2. Be a UW faculty member or have a UW faculty sponsor (PI).
   3. Have an active UW or ARCC account.
   4. Enroll in Two-Factor Authentication (2FA).
   5. Maintain an active email monitored regularly (USERNAME@uwyo.edu for UW users; externally provided email for collaborators).
5. Account and access:
   1. All ARCC accounts must be associated with a project and approved by the project PI.
   2. PIs are responsible for project members’ compliance with policies and for requesting project creation, changes, and account access.
   3. PIs may designate Project Managers (DMs) in writing specifying scope, projects, and timeframe. ARCC must be notified in writing of DM designations.
6. Notification & cooperation:
   1. Users must promptly comply with ARCC requests (e.g., reduce disk usage or halt prohibited activity).
   2. Report compromised accounts immediately to arcc-help@uwyo.edu and notify UW IT Security for lost/compromised 2FA tokens.
   3. Keep contact information current; monitor ARCC announcement email list (users are auto-enrolled; unenrolling may cause missed notices).
7. Accounts, Projects, and Roles
   1. PI qualification:
      1. PIs are UW faculty with extended-term appointments or designated research staff. Graduate students may be PIs only with ARCC approval and with reduced default storage/compute allowances.
   2. Account types:
      1. PI accounts — for PIs only; elevated permissions for their projects.
      2. Project member accounts — for researchers sponsored by a PI.
      3. ARCC-only accounts — non-UW accounts created by ARCC (requested by PI).
      4. Instructional accounts — created per course and limited to semester use and class queues.
      5. System and staff accounts — for UW staff with administration duties.8
8. Account lifecycle:
   1. 1. 1. 1. 1. Creation: PI must request accounts and an associated project where needed.
               2. Renewal: Accounts/projects with end dates must be renewed before expiry if continued access is required.
               3. Transfer: Projects or non-PI accounts may be transferred to a new PI on request.
               4. Termination: Violation of policies or University decisions may lead to immediate deactivation. Restoration requires a written request from the PI and review by ARCC leadership or UW Research Computing governance where applicable.
9. Security, Data, and Licensing
   1. Authentication & data access:
   2. Access controlled by usernames, passwords, and 2FA. Users must protect credentials and not share them.
   3. ARCC systems are research systems protected to NIST 800-53 low baseline; network and file storage may be unencrypted by default. Users are responsible for protecting their sensitive files and ensuring compliance with applicable controls.
10. Restricted and prohibited data:
    1. Storing or processing restricted or regulated data (HIPAA, FERPA, PII, export-controlled, classified data, nuclear/weapon design, etc.) requires prior written authorization from the University; use for those categories is generally prohibited.
11. Licensing & copyright:
    1. Only properly licensed software may be installed or used. ARCC requires proof of licensing for commercial software and may refuse installations that exceed system capabilities.
    2. Users must not copy, store, or transfer copyrighted software/data unless authorized.
12. Monitoring, Backups & Retention
    1. ARCC may monitor resource use to enforce policies and manage the environment.
    2. Backups:
       1. MedicineBow (HPC) file systems are not backed up by default; some replication and optional snapshots may be available (20-day snapshots upon request).
       2. Alcova / VAST and Pathfinder have specified backup/snapshot policies; consult the service page.
    3. Data ownership and removal:
       1. Data on ARCC systems is considered research data and associated with the PI’s project.
       2. ARCC may remove or reassign data after account deletion or project termination; users should maintain external backups.
       3. Data retention windows:
          1. /home: preserved while account is active; removed after account deletion as per ARCC process.
          2. /project: preserved up to 6 months after project termination (subject to ARCC rules).
          3. /gscratch: may be purged after 45–90 days of inactivity (90-day purge policy may apply; warnings will be issued).
          4. /lscratch: node-local scratch; files deleted nightly (or per policy), typically after 14 days.
13. Login Node and Compute Node Use
    1. Login nodes:
       1. Intended for interactive tasks (job setup/submission, small compilations, data transfer, result inspection).
       2. Forbidden on login nodes: compute-intensive tasks, long-running processes (>10 minutes), or large numbers of concurrent tasks that impact others.
       3. Long or parallel compilations should be done in an interactive job on compute nodes (request via salloc).
       4. ARCC staff may terminate offending processes and may suspend access for repeat violations.
    2. Compute nodes:
    3. Use compute nodes for heavy computation via scheduled jobs. Use the scheduler (SLURM) and follow queue/QoS/partition rules.
14. Job Scheduling, Queues, Reservations, and Limits
    1. Job submission:
       1. All job submissions must specify an account. If no QoS/partition/walltime is specified, jobs default to the Normal queue with a 3-day wall time.
       2. Users are encouraged to specify accurate, preferably shorter, wall times to help scheduling.
       3. Partitions route jobs from oldest to newest hardware unless explicitly requested otherwise.
15. Cluster Quality of Service (QoS) and Queues (MedicineBow example):
    1. Debug — small hardware subset, ~1-hour limit; for quick debugging.
    2. Interactive — highest priority, up to 8 hours; used for interactive desktops, OnDemand sessions, salloc, Jupyter, etc.
    3. Fast — up to 12 hours; for short jobs needing quick turnaround.
    4. Normal (default) — up to 3 days; general-purpose default queue.
    5. Long — up to 7 days; limited to 20% of cluster + investments.
    6. Extended (Investor) — up to 14 days; limited to investors/15% of cluster outside investments; enables investor flexibility and preemption on invested nodes.
    7. Note: Interactive jobs may be restricted from certain queues; consult the cluster-specific queue definitions.
16. Reservations:
    1. Reservations guarantee exclusive access to specified nodes for a time window.
    2. Request reservations at least 14–21 days in advance (21 days recommended for instructional use) to allow configuration and to respect maximum job wall times.
    3. Reservations are charged for the whole reserved time regardless of actual usage and apply to full nodes (cannot reserve a single GPU on an 8-GPU node).
17. Preemption and investments:
    1. Investor-owned-priority grants preemption rights on invested nodes: non-investor jobs running on investor nodes can be killed to give investor access.
    2. Users may use non-investor queues to reduce preemption risk. Checkpointing is the user’s responsibility.
18. Limits:
    1. No single SLURM account/project may occupy more than 33% of cluster resources (plus investment allocation); enforced per project/account.
    2. Memory must be explicitly requested (no --mem=0) to prevent over-requesting; use --exclusive only if you intend to reserve the entire node.
    3. GPU partitions require explicit GPU requests; using a GPU node without requesting a GPU may result in billing or job rejection (exemptions may apply to investments).
    4. Allocations, Quotas, and Service Limits
       1. Default compute and storage quotas (MedicineBow example):
          1. MedicineBow CPU hours: up to 100,000 non-investment CPU core-hours/year (default pool).
          2. MedicineBow A30 GPU hours: up to 20,000 total non-investment GPU hours/year (GPU hours summed across GPUs).
          3. Default storage per user/project:
             1. /home: 50 GB per user
             2. /gscratch: 5 TB per user (subject to purge after inactivity)
             3. /project: 5 TB per project
       2. Graduate project quotas: 50% of default quotas unless otherwise specified.
       3. Wildiris projects have different defaults (e.g., 1 TB /gscratch, 2.5 TB /project).
    5. Quota enforcement:
       1. Users exceeding quotas are blocked from creating new files until usage is reduced or additional quota purchased/approved.
    6. Capacity increases:
       1. Options: rented space (shared TB/year pricing), purchased space (group disks integrated into HPC), or hardware investment (dedicated hardware; economical when > ~15 TB).
       2. One-time capacity increase: requires written justification, ARCC leadership approval, typically applies for life of the storage system (~3 years), and is capped (e.g., 10 TB) unless otherwise approved.
       3. Requests for additional capacity should be submitted through the ARCC Service Portal.
19. Costs, Charging, and Investments

1. 1. General policy:
      1. ARCC operates an investment model: researchers may fund hardware purchases to gain priority access (not ownership). Investment nodes remain ARCC property; priority access and preemption rights are the investor’s benefit.
      2. General (non-investor) cluster usage is free to UW faculty, staff, and students within default quotas. Non-UW entities may be charged.
      3. Pricing for new hardware, investments, and services depends on procurement costs and market conditions.
   2. Reservations and billing:
      1. Reservations charged for the entire reserved duration (e.g., reserving an H100 node for 1 week charges for the full week even if only used 1 GPU-hour).
      2. Reservations require a setup fee (e.g., $100) in addition to per-hour/per-node charges; must be requested in advance.
   3. Example unit prices (subject to change; consult price sheet):
      1. MedicineBow H100 GPU: $0.6210779 per GPU-hour above quota (example figure).
      2. MedicineBow L40S GPU: $0.1802285 per GPU-hour above quota.
      3. MedicineBow A30 GPU: $0.1291350 per GPU-hour above quota.
      4. CPU core-hours above quota: $0.0039453 per core-hour.
      5. VAST (Alcova) storage above quota: $75 / TB / year (example).
      6. Pathfinder S3: $45 / TB / year; one-time $50 fee per access/secret key issuance.
      7. Long-term archival storage (example): $750 / TB for 10 years.
      8. Account setup for external collaborator: $10 (charged by UW IT).
      9. Personnel consultation or additional software install: $25 / staff-hour.
      10. Hardware reservation base cost: $100 + compute/GPU hours reserved (billed per rates above).
   4. Billing triggers:
      1. Non-UW entities may be charged immediately.
      2. UW users are charged when usage exceeds default quotas or when purchasing capacity, reservations, or services.
      3. ARCC will provide notice before instituting general billing for “normal” users; investments and non-UW charges may apply earlier.
   5. Examples (illustrative):
      1. H100 node daily cost calculation: 8 GPUs × 24 hours × $0.6210779 ≈ $119.25/day; plus $100 setup fee for a reservation (example totals: 1 day ≈ $219.25; 1 week ≈ $934.73).
      2. L40S node daily cost: replace per-GPU rate to compute daily charge, plus setup fee.
   6. Quotes and miscellaneous services:
      1. Complex requests (custom hardware, large storage, special installs) will receive a project quote based on hardware, configuration, storage, licensing, and personnel hours.
   7. Software Support, Installation, and Acquisition
      1. Support model:
         1. ARCC provides consultations on software capabilities, installation guidance, licensed deployment, updates, and best-effort support for non-vendor issues.
         2. A community-driven Known Error Database (wiki) is available.
         3. Supported software:
            1. ARCC maintains a supported software list per system and reviews it biannually. Underused software may be deprecated; movement to deprecated status occurs during system upgrades (twice per year)
            2. Faculty may request continued support for deprecated applications by contacting arcc-help@uwyo.edu.
         4. Software acquisition & licensing:
         5. Open-source software is recommended when possible. Proprietary licenses are typically financed by the requesting PI/department/college unless broad university-wide use warrants UW-IT involvement.
         6. ARCC assists with license server hosting and license administration where appropriate.
         7. Requests for software installs or consultations must be initiated by a PI via the ARCC Software Consultation Request and should include expected users, licensing details, costs, and timeline.
         8. Installation:
            1. ARCC will install commercial/licensed software only with valid licensing proof and if system configuration supports it. ARCC may decline installations that exceed system capability or conflict with existing configurations.
         9. Development & troubleshooting:
         10. ARCC provides best-effort code development assistance, troubleshooting, and update support based on staffing and priorities.

1. 13. Enforcement, Violations, and Appeals

1. 1. Enforcement:
      1. ARCC staff will act to stop actions that harm system stability or other users’ access (e.g., killing offending processes, suspending accounts).
      2. Policy violations may result in immediate account deactivation, suspension of access, or other administrative or legal actions.
      3. Restoration typically requires a written request from the PI and review by ARCC leadership; major actions may involve UW Research Computing governance (UW-ESC) and University offices.
   2. Reporting:
      1. Users and staff must report suspected misuse, abuse, or criminal activities to ARCC and University authorities.
   3. Liability and disclaimers:
      1. ARCC and UW make no warranties regarding availability or data integrity. The content of ARCC pages and policies are guidance and do not constitute legal advice.

1. 14. Foreign National Access and Export Control

1. 1. Foreign nationals may generally use ARCC resources; exceptions apply under OFAC or other federal restrictions (e.g., prohibitions for certain sanctioned nationals in specific jurisdictions). Compliance with export control and federal restrictions is mandatory; prohibited cases require denial or written approval.

1. 15. Notices, Communications, and Policy Changes

1. 1. ARCC communicates service announcements via the arcc-announcement mailing list and the ARCC News page. Users are auto-enrolled upon provisioning; opting out may prevent receipt of critical information.
   2. Policy changes:
      1. ARCC reserves the right to update policies. Substantive changes to billing or default entitlements will be announced in advance.

1. 16. Contact and Requests

1. 1. For account, quota, reservation, or support requests: arcc-help@uwyo.edu
   2. For software consultations and installation requests: use the ARCC Software Consultation Request or email arcc-help@uwyo.edu.
   3. For security incidents and 2FA token loss: IT_Security_Office@uwyo.edu (and notify ARCC).

Appendix: Quick Reference (selected numbers and schedules)

1. 1. Default storage quotas: /home 50 GB/user; /gscratch 5 TB/user; /project 5 TB/project (graduate projects: 50% defaults).
   2. MedicineBow default compute quotas (example): CPU up to 100,000 core-hours/year (non-investment); A30 GPU up to 20,000 GPU-hours/year (non-investment).
   3. Example rates (above quota / example values — confirm current price sheet):
      1. CPU above quota: $0.0039453 per core-hour
      2. A30 GPU above quota: $0.1291350 per GPU-hour
      3. L40S GPU above quota: $0.1802285 per GPU-hour
      4. H100 GPU above quota: $0.6210779 per GPU-hour
      5. VAST/Alcova storage above quota: $75 / TB / year
      6. Pathfinder S3: $45 / TB / year; $50 access key fee
      7. Reservation setup fee: $100 (plus per-hour charges)
      8. Personnel/consultation: $25 per staff-hour (example)
   4. Reservation lead time: 14–21 days (21 days recommended for instructional use).
   5. Preemption: Investors may preempt non-investor jobs on investor nodes; users should checkpoint work to mitigate loss.