# Your lab account

## Overleaf and files: browser only

1. Open the private invitation link in your email. It is sent automatically once; if it did not arrive, ask the administrator, who can see its delivery state and resend it manually. Enter your first and last name in their separate fields; your username is generated for you. Verify your email address and choose your own central password. You do not need an SSH key or an S3 account.
2. Link your Telegram account when registration asks. This step is required for every invitation registration.
3. Only the apps you requested are granted. Requested SSH, VPN or compute access stays pending until the administrator approves it. By default your home has 5 GiB and VPN has a 3 GiB quota.
4. Open **Overleaf** at https://overleaf.smtornado.com to write papers, or **Nextcloud** at https://nextcloud.smtornado.com to work with files.
5. Change your password through https://auth.smtornado.com (Settings or recovery). Use that central password for supported app and SSH password logins. Some apps redirect to the central sign-in page; Overleaf asks for your email and central password.

If you used our old Overleaf, tell the administrator and keep the same verified email. Your old account and project memberships will be linked before the new login is enabled. Do not create a second Overleaf account or try to transfer every project yourself. The old Overleaf password is replaced by central authentication at migration.

You can ask for more services later using this same account. Invitation validity is the deadline for accepting the link; account expiry is a separate date that the administrator can extend. Immich is a separate permanent family service.

## Adding compute access

Request compute access and the machines needed; you have no access until the administrator approves it. They configure your permanent Unix identity and home before enabling Slurm. Generate an SSH key on your own computer, for example `ssh-keygen -t ed25519`, and supply only the public `.pub` file through the commissioned account-settings form or directly to the administrator. Keep the private key on your computer. Existing keys are fine. `ssh-copy-id` is not needed: this cluster obtains authorized keys from the central directory.

Use the connection details and host fingerprints provided by the administrator. The planned route is a jump through `bastion.smtornado.com` to NAS; confirm that route at rollout. Never disable host-key checking. Compute work belongs in Slurm, not the NAS shell.

## Starting a notebook when you need it

On NAS:

```sh
lab-jupyter --partition debug --time 01:00:00 --mem 8G
lab-jupyter-info JOB_ID
```

Replace `JOB_ID` with the returned number after the job reaches RUNNING. Run the printed SSH tunnel on your own computer, then open the private localhost URL. Keep its token private. The `debug` partition uses node2's RTX 3060; `batch` uses rig's RTX 3090 and requires permission. Queueing is normal when the permitted GPU is busy.

Select **Lab teaching-2026b**, or the release the administrator publishes. Nothing starts a notebook automatically when you enroll or sign in. End the allocation with `scancel JOB_ID` when finished; closing the browser does not necessarily stop it. Idle cleanup is a fallback, not a way to save unsaved work.

## Python and storage

Everyone can read and run the administrator-owned uv environment at `/opt/lab/envs/teaching-2026b`. Each person has their own Python process and files. Never run pip, uv install/sync, Conda or notebook `%pip` against that shared release. Ask for a package to be added to a new release. An approved private uv environment is separate and needs its own dependencies and lockfile.

Keep code, notebooks, lockfiles and checkpoints in your backed-up home or approved project storage. `/scratch/$SLURM_JOB_ID` is temporary job storage. Local caches and the extra public-dataset disks can be purged or re-downloaded. They are not backups. Ask the administrator to adjust a quota before running out; increasing a quota does not create physical capacity.

## MLflow experiments

Request MLflow access if it is not assigned. Visit https://mlflow.smtornado.com with your central username and password. The administrator can inspect students' experiments; other students have no access by default unless explicitly shared.

Once the `lab-mlflow` helper is installed, run `lab-mlflow --login` interactively on NAS to save a private credential file. Do not put a password in your script, `sbatch` arguments or a chat. After changing the central password, repeat this login. Inside your Slurm script use:

```sh
lab-mlflow -- /opt/lab/envs/teaching-2026b/bin/python train.py
```

In Python, create an experiment, record parameters once and metrics with a step:

```python
import mlflow
mlflow.set_experiment("YOUR_USERNAME/project-name")
with mlflow.start_run():
    mlflow.log_params({"seed": 42, "learning_rate": 0.001})
    mlflow.log_metric("validation_loss", 0.25, step=1)
    # mlflow.log_artifact("summary.json")  # only a file you intend to upload
```

This is a logging example, not a training algorithm. Log useful summaries and selected artifacts; do not upload entire datasets, credentials or every checkpoint. MLflow stores artifacts through its server, so students do not need its Garage key. Save checkpoints separately. If tracking is unavailable, preserve local results and report the logging failure; offline runs are not automatically uploaded later.

## Garage, notifications and assistants

Nextcloud works without a direct Garage/S3 key. If you need programmatic object storage, request `svc-s3`. Compute users receive private `~/.aws/credentials`, profile `lab`, for their own buckets. Use the provided HTTPS endpoint, region `lab`, path-style access and normal TLS verification. Never share a key. Garage does not provide object versioning; an overwrite can replace data.

Email carries invitations, account/lifecycle messages and configured job notifications. Your Telegram account is linked during registration, but the bot may be unavailable at times; do not rely on it as the sole channel. `/me` shows your account, `/jobs` your jobs and `/jupyter` your existing notebook; it does not launch one. `/extend` and `/contact` send requests to the administrator; `/notify` manages optional preferences.

Give your coding assistant **AGENT_USAGE.md** before it runs code or connects MCP. MCP is optional; browser-only work needs none of this setup. The public status page shows machines, queue capacity and rack/cooling telemetry. Per-person allocated GPU-hours are visible to the administrator, not published as a student leaderboard.

Temporary Slurm submission pauses deny new jobs until the displayed deadline. Existing queued/running jobs are not cancelled by this pause. Account expiry/revocation has broader effects. During planned Windows maintenance a node stops accepting work; notebook memory is not recoverable after a reboot. Save/checkpoint and request only the time and resources needed.

## MATLAB on the Ubuntu rig

For approved rig users with MATLAB installed/licensed, the **MATLAB (Slurm CPU)** application shortcut opens the normal GUI inside a Slurm allocation. Alternatively run `lab-matlab --gui` in a local rig desktop terminal: defaults are 4 CPU threads, 8 GiB RAM, 4 hours, and no GPU. Keep the launch terminal open, save before the walltime ends and quit MATLAB when finished. More CPU/RAM can be requested with `--cpus 8 --mem-gb 16`; it may queue behind existing work.