Euler CPU Track

Euler is ETH Zurich's shared service for research calculations. A CPU is the general-purpose processor used by most programs. Instead of running a long program on the entry computer, you submit a job so Euler can run it on a compute node with requested CPU, memory, and time.

Complete this track before regular CPU computation on Euler. It is also a prerequisite for the Euler GPU track.

This page summarizes the track. Follow the current mission in your local Passport; do not use the links below as a second checklist.

After the Git and Euler lessons, researchers who use GitHub for project code can try the optional computer-GitHub-Euler sync demo. It does not add a Passport requirement or change existing progress.

Prerequisites#

• IT and Research Safety Core
• Supervisor confirmation that Euler is appropriate for the project
• Working ETH account and VPN access when outside the ETH network

Current Training Evidence#

Training checks bounded observations of the small CPU job plus reviewed fixtures and choices. Cancelling a correct completed job is not required; recovery applies to an identified incorrect job.

Use the current Passport lesson for sequencing. The competencies and evidence below describe later project capability and private owner review; they are not extra public submissions or automatic access grants.

Competencies#

You can:

• distinguish login nodes, compute nodes, and storage systems;
• connect using a personal account and safe SSH configuration;
• recreate a small Python environment on Euler and activate it inside a batch script instead of copying a laptop environment;
• submit, inspect, and cancel jobs with sbatch, squeue, myjobs, and scancel;
• inspect completed jobs with sacct and seff;
• use sstat appropriately for a running job step;
• interpret states, pending reasons, logs, and exit codes;
• start with conservative CPU, memory, and wall-time requests;
• optimize later requests from measured usage;
• preserve and record the source, configuration, and input versions used by a queued or running job;
• submit arrays with an explicit concurrency cap and calculate aggregate concurrency across all active submissions;
• distinguish the public and es_fuge accounts;
• choose $HOME, /cluster/work/fuge, $SCRATCH, and $TMPDIR intentionally;
• prefer sbatch for unattended work and short allocations for debugging.

Mission Coverage#

1. Euler access and SSH
2. Euler Python environments
3. Euler storage
4. Slurm job lifecycle
5. First Euler job
6. Resource optimization
7. Safe job arrays

Evidence#

• A tiny successful CPU job using one CPU and modest memory.
• Proof that the job used the named Euler environment.
• The relevant sacct and seff lines for its job ID, with usernames, private paths, project names, and research data removed.
• An explanation comparing requested and measured resources.
• A correct explanation of the batch script snapshot versus external files.
• A corrected Slurm array with a justified concurrency cap.
• Correct storage choices for code, data, logs, checkpoints, and temporary files.

Understand Before Accepting AI Output#

• I inspected the resource request before submission.
• I know what will execute and where output will be written.
• I can cancel the job if the request or behavior is wrong.
• I measured usage before increasing resources.

Pass Criteria#

The student completes the practical evidence and correctly explains the job lifecycle. Memorizing Slurm flags without interpreting accounting output is not sufficient.