Launching a Desktop Session¶

Pick the right tile¶

Your Interactive Apps menu lists the apps you're authorised to launch:

Lab Desktop — a full Xfce desktop on one of your lab's nodes, with resource controls (hours, cores, memory, GPU) prefilled from the profile you pick. Best default for most users.
Single-tool launchers that put one application in your browser without a full desktop: JupyterLab, MATLAB, VS Code (code-server), ANSYS, Abaqus. They share the same resource form as Lab Desktop, plus tool-specific options (e.g. JupyterLab's modules field).

Neuroimaging users: there's no separate Neurodesk tile — run module load neurodesk inside any desktop or Jupyter session to get the Neurodesk catalog.

The form fields you'll actually see¶

Lab Desktop¶

Field	Default	Notes
Session name	(blank)	Optional label shown on the session card so you can tell sessions apart.
Desktop		Drop-down of approved profiles. Each profile pins to a specific node in your lab (see below) and prefills every resource field.
AD password	(blank)	Only needed if this session should reach your lab's CIFS shares. Leave blank to work in `$HOME` and `/scratch` only.
Resolution	1920x1080	Or 2560x1440.
Hours	8	Walltime — Slurm kills the session at expiry.
CPU cores	8	Capped at the selected node's core count.
Memory (GB)	32	Capped at the selected node's memory.
GPU	Shared (most profiles)	None / Shared GPU / Exclusive GPU(s) — see Choosing a GPU.
Number of GPUs	1	Hidden when GPU = None. Cards for Exclusive, shard slots for Shared; capped per profile.
GPU model	first model on the node	What the card is (and its VRAM). Only matters for Exclusive sessions on a mixed-model node.

Picking a profile prefills hours / cores / memory / GPU with that profile's defaults, and the drop-down only shows GPU options the selected node can actually schedule.

JupyterLab / VS Code / MATLAB / ANSYS / Abaqus¶

JupyterLab and VS Code use the same resource form as Lab Desktop, including the three-field GPU picker, plus tool-specific fields:

JupyterLab — modules (default jupyter-gpu/2026a), extra_jupyter_args.
VS Code (code-server) — modules (default code-server), workdir (default $HOME).

MATLAB, ANSYS, and Abaqus keep a simple GPU count field instead of the picker (0 = CPU-only; their GPUs are shared across jobs). MATLAB's modules default is matlab/R2025a matlab-proxy.

The "Desktop" / "Lab profile" selector picks the node¶

The most consequential field on every form is the profile drop-down. Each entry maps to one specific node in your lab — there's no "any node in my lab" option. The drop-down label shows the node's hardware summary next to the name. Today's profiles:

Lincheng Research → 3× RTX PRO 6000 Blackwell (96 GiB). Exclusive GPUs only — no Shared option on this node.
Inspire Turing → 4× H200 (141 GiB).
Inspire Ada → mixed node: 4× L40S (48 GiB) + 4× RTX PRO 6000 Blackwell (96 GiB). The GPU model picker matters here.
Inspire Searle → 1× RTX 2000 Ada (16 GiB). Shared only — no Exclusive option (smaller resource defaults: 4 cores, 16 GB).

If your lab adds another node, a matching profile gets added; pick the one that matches the hardware you need. The drop-down only shows profiles your lab is authorised for, so most users will just see their own lab's options.

AD password (optional)¶

Optional. Leave blank for sessions that only touch $HOME and /scratch.
Required if you need to read or write your lab's CIFS shares — i.e. anything under /mnt/<lab-share> or the matching symlinks in $HOME that your lab admin set up.
It's your AD.UMD.EDU password (for most people, the same as your UMD login password).
Used once at session start to register a per-user CIFS credential in the kernel keyring (cifscreds). Not stored beyond the session, not written to disk.

If you enter a wrong AD password, the session still launches; your lab share will just look empty. End the session and relaunch with the correct password.

There is no AD username field — the form uses your OOD-portal identity (your UMD directory ID) for the username automatically.

Picking a walltime¶

Slurm kills your session as soon as the walltime is up, regardless of whether you're in the middle of something. Pick something that comfortably covers your day:

4 hours — a focused working block.
8 hours (default) — a workday, plus a bit of slack.
24–72 hours — an overnight or weekend run. Use this only when you know what's running; your node being occupied for 3 days blocks your labmates.

Long-running computation is usually better submitted as a batch job via sbatch (see slurm-cli.md) — you don't need a desktop for that, and batch queues can run longer jobs.

Picking CPU cores and memory¶

Start with the prefilled defaults. They come from the profile and are tuned to leave room for your labmates on the same node.
Only ask for more than you'll use if you genuinely need it. CPU and memory are tracked per allocation; over-asking eats into what's available for labmates even though jobs share the node.

Choosing a GPU (allocation, count, model)¶

The GPU section is three fields (on Lab Desktop, JupyterLab, and VS Code):

GPU — how you want the hardware allocated:

None (CPU only) — software OpenGL. Fine for terminals, file browsing, prose writing, light editing. Hides the other two fields.
Shared GPU (time-share a card) — the considerate default on most profiles. Your session time-shares a physical card with labmates and sees the card's full memory (there's no per-session VRAM cap). Good for accelerated rendering, viewport work, and light-to-moderate CUDA — including neuroimaging containers run with apptainer --nv.
Exclusive GPU(s) (whole cards) — reserves whole card(s) for your session alone. Use for serious training runs or anything that needs a card's full throughput. While you hold it, labmates can't use it — see Releasing GPUs Promptly.

Number of GPUs — whole cards for Exclusive, shard slots for Shared. Capped at the selected profile's ceiling.

GPU model — shows what the card is and its VRAM on the selected node. On single-model nodes it's informational. On the mixed Inspire Ada node it decides which model an Exclusive session is scheduled onto (L40S 48 GiB vs RTX PRO 6000 Blackwell 96 GiB); asking for more cards than one model has spans both models. Ignored for Shared sessions.

The drop-downs only offer what the selected profile can schedule — e.g. Lincheng Research has no Shared option and Inspire Searle has no Exclusive option.

Workload	Sensible starting point
File browsing, light editing, viewing results	4 cores, 16 GB, GPU: None
MATLAB / ANSYS / Abaqus interactive (in Lab Desktop)	8 cores, 32 GB, Shared
Neuroimaging pipelines (fmriprep, C-PAC, Neurodesk)	8 cores, 32 GB, Shared
Accelerated viewport / rendering	8 cores, 32 GB, Shared
PyTorch / JAX training or inference, single GPU	8 cores, 32 GB, Exclusive × 1
Multi-GPU training	16 cores, 64 GB, Exclusive × 2+

Neurodesk tools¶

Neuroimaging users get the Neurodesk catalog inside any desktop or Jupyter session — run module load neurodesk and the tools appear as neuro/<tool>/<version> Lmod modules. There is no separate Neurodesk tile.

Resolution¶

Match your actual monitor for the sharpest text. If you're unsure, 1920x1080 is safe on any laptop; 2560x1440 looks good on most desktop monitors.

You can change resolution mid-session from the VNC client's top-of-window menu, but picking it right the first time avoids a reconnect.

Your session, once running¶

You'll land on the "My Interactive Sessions" page. Each session card shows:

Time remaining — when Slurm will end it.
Host — which compute node it landed on.
Launch NoVNC in a new tab — opens the desktop in your browser.
Launch TurboVNC client — for the native VNC client if you've installed one (faster over poor networks).
Native Instructions — a tab with copy-paste instructions for connecting any VNC client over an SSH tunnel (see below).
Delete — ends the session early and returns the node to the queue.

Connecting with a native VNC client¶

For weak networks or larger displays, a native VNC client is much smoother than the in-browser NoVNC viewer. The session card has a Native Instructions tab that gives you everything you need:

Click Native Instructions on the running session card.
Copy the SSH tunnel command and run it in a local terminal. It forwards a port from your laptop to the compute node via the HPC login host. Leave the terminal open while you're connected.
Either click the .vnc file download and open it with your VNC client, or point your client at localhost:<port> with the one-time password shown on the tab.

Recommended clients:

TigerVNC — free, works on macOS, Windows, Linux.
TurboVNC — best performance over slow networks; matches the server.
RealVNC Viewer — works, but configure it for Auto encoding.

Stop the SSH tunnel when you're done; the desktop session itself keeps running until walltime.

Extending a session¶

You can't extend a running session beyond the walltime you chose. Plan for a longer session up-front, or end it and start a new one when you need more time.

Ending a session¶

This applies to every interactive app (desktops, JupyterLab, VS Code, MATLAB, ...):

Best: click Delete on the session card. The node is returned to the queue immediately.
Otherwise the session ends automatically at walltime.
Just closing the browser tab leaves the session running until its walltime. Your CPU/memory allocation stays counted against the node, and any GPU you reserved stays reserved.
The apps themselves have no quit control that ends the session — e.g. VS Code (code-server) has no File → Quit. The Delete button is the way out.

Reconnecting¶

The session runs on the compute node, not in your browser tab. You can close the tab and come back later — the session survives until walltime. Go back to My Interactive Sessions and click Launch NoVNC again.

This also means OOD server maintenance (or your laptop dying) doesn't kill your work — your desktop keeps running on the compute node.

What you can't see from the form¶

Whether the node you picked is free. The profile pins your session to a specific node; if it's already at the OverSubscribe limit, Slurm queues you on that node rather than picking a different one in your lab. To check before you launch, open Clusters → Research Slurm Shell Access and run sinfo -p <your-lab> -N or squeue -p <your-lab> — every job you see is a labmate's. That's also how you find out which labmate to ping about a forgotten overnight session blocking the node.
How long until queued sessions run. Slurm will start your job as soon as the node has room (Shared sessions time-share cards, so there's usually room). Usually seconds; if it sits longer than a minute or two, the node is genuinely full — e.g. every card is held by Exclusive sessions.

Fine-tuning for power users¶

The defaults in the form correspond to Slurm flags:

Hours → --time=<hh>:00:00
Cores → --cpus-per-task=<n>
Memory → --mem=<n>G
Shared GPU → --gres=shard:<n>
Exclusive GPU(s) → --gres=gpu:<n> (or --gres=gpu:<model>:<n> on a mixed-model node when the count fits one model)

If you find yourself overriding defaults every time, ask IT to change the profile's defaults for your lab — they're one hiera edit.