Login nodes vs compute nodes
When you SSH to Mjolnir you land on the login node (mjolnirgate). This is not where your analysis runs.
Two different machines, two different jobs#
| Login node | Compute nodes | |
|---|---|---|
| How you get there | ssh <KU-ID>@mjolnirgate.unicph.domain | Slurm places your job there |
| Shared with | Everyone logged in right now | Only the jobs Slurm has scheduled |
| Intended for | Preparing and managing work | Running work |
The login node is shared by everyone connected at that moment. A heavy process there slows down every other user's session — including people who are only trying to check on a job.
What the login node is for#
- Logging in
- File management — moving, copying, organising, editing files
- Preparing work: writing scripts, setting up environments
- Submitting jobs
- Monitoring jobs
- Other lightweight interactive tasks
What belongs in a Slurm job#
Computational work belongs on compute resources, submitted through Slurm. That includes analyses, alignments, assemblies, model training, large data processing — anything that does real work rather than preparing it.
Important If a command would take meaningful time or memory to finish, it belongs in a Slurm job rather than on the login node. Submitting jobs shows how.
Running computation on the login node is not permitted, and persistent misuse can lead to access being withdrawn.
But I only want to test something small#
That is a reasonable instinct, and short interactive work is exactly what the login node is for — checking a file, testing that a script parses, inspecting output. The line is whether it does *work* or *prepares* work.
If you need an interactive session with real resources, request one through Slurm rather than using the login node for it.
Next step#
How Mjolnir works places both machines in the wider picture, and First 15 minutes on Mjolnir puts this into practice with a first job.