1  Getting started on the cluster

1.1 What a cluster is

1.1.1 Mental model

MedicineBow is a few hundred ordinary Linux servers (“nodes”) wired together, all mounting the same shared filesystems, all managed by a scheduler (Slurm) that decides whose job runs where and when.

1.1.2 Login nodes vs. compute nodes

There are two kinds of machines:

1. Login nodes (mblog1, mblog2) are the front door. When you ssh in or open a terminal in the web portal, you land here. They are shared by everyone at once — dozens of people editing files, submitting jobs, and moving data. Use them for lightweight work: editing scripts, managing files, compiling small things, submitting and checking jobs.

2. Compute nodes are where computation happens. You never SSH to them directly; you ask the scheduler for one (or many), and it gives you exclusive, dedicated access for a bounded time. The default mb nodes have 96 CPU cores and ~1 TB of RAM each, and the GPU nodes carry up to 8 NVIDIA H100s.

flowchart LR
    U["Your laptop"] -->|"ssh / web portal"| L
    subgraph MB ["MedicineBow"]
        L["Login nodes<br/>mblog1 / mblog2<br/>shared, lightweight only"]
        S{{"Slurm scheduler"}}
        L -->|"sbatch / salloc"| S
        S --> C1["Compute node"]
        S --> C2["Compute node"]
        S --> C3["GPU node"]
    end
    FS[("Shared filesystems<br/>home, project, scratch")]
    L --- FS
    C1 --- FS
    C2 --- FS
    C3 --- FS
    style MB fill:#f3eefb,stroke:#7a4fb5,color:#3a2a5a

Figure 1.1: You reach a shared login node from your laptop; the scheduler runs your jobs on dedicated compute nodes. All nodes see the same filesystems.

Don’t compute on login nodes

A big job on mblog1/mblog2 slows the machine for everyone logging in. ARCC monitors this and kills runaway login-node processes (and emails you).

1.1.3 Where to get help

Channel	Use it for
arcc-help@uwyo.edu	Anything. Real humans, ticketed via Jira Service Management.
Office hours (Zoom)	Tuesdays, 11am–1pm — bring your actual problem.
ARCC wiki	The official reference docs.

1.2 Getting access

1.2.1 Requesting a new project

1. Email Josh Day (josh@rallypoint1.com) or Virginia Iglesias (virginia@innosphere.org) with the desired:

   1. Project name (cowy-<name>; its directory will be /project/cowy-<name>)
   2. Project PI
   3. CPU hours requested
   4. GPU hours requested
   5. Storage needed beyond the 5 TB default, if any

   ASCEND uses a shared /project/cowy space for data sharing between projects, which ARCC will add you to automatically when your cowy-<name> project is approved.

2. PI fills out new project request.

1.2.2 Adding users to a project

As an “Attachment” in the new project form, the PI provides details for each user to be added to the project:

1. First and last name
2. Email address
3. Institution
4. Phone number
5. Whether they are a foreign national under the ITAR/EAR definitions.

Alternatively, the PI can request users by contacting arcc-help@uwyo.edu with the project name and above info for each user.

1.2.3 UW accounts vs. ARCC-Only accounts

ASCEND spans UW, CSU, CU Boulder, Mines, NCAR, and NEON, so this distinction affects collaborators:

	Full UW account	ARCC-Only account
Who	UW-affiliated people	External collaborators without a UW identity
HPC (MedicineBow)	✅	✅
GitLab	✅	✅
Globus data transfer	✅	❌ cannot use Globus
Other UW services	✅	❌

ARCC-Only accounts and Globus

External collaborators on ARCC-Only accounts cannot use Globus, the recommended way to move large datasets (Section 3.2). They’ll need a guest collection set up for them, or a UW person to broker transfers. Plan for this early if your data lives at CSU, NCAR, etc.