# Triton winter kickstart 2026 planning
## Previous meetings
Let’s have it in an online format for winter 2026.
• The main audience is people who have triton account, maybe submitted one or two jobs; but not monitoring etc. (phd students, new postdocs)
• “Demo” part can show for example environment creation with triton in mind
• GPU monitoring has improved from last year so that is another topic
• We don’t need the afternoon zoom just say that we can help until day xyz so they can do the exercises and submit.
• Demo from last year was too fast, we can keep things slower, e.g. with 3 hours
• Maybe have it in the afternoon.
• Let’s keep the data for Jan 28, 2025, @12-15.
• EG will create the placeholder for course + registration
• Material will be TBA.
• Twitch TV with notes. ~~Patricia doing the streaming.~~
• Student from the hpc competition might also join to learn slurm basics
• It can still be marketed as first step to bigger clusters, what you learn here you can reuse it in other clusters who have very similar tools. We welcome people from other clusters but we give the demos and paths that are more specific to triton. We can mention that it fits into the LAIF tutorials as a kickstart for bigger clusters. “We are teaching the basics of slurm and HPC workflows while using Aalto’s cluster as an example, you can learn from here and transfer skills to other sites. There are also courses available at xyz…”
• Skills / learning outcomes
• Slurm from zero to /inf (like last year, it was good)
• Environments (and modules?).
• A program does not know it is running on the cluster (local files and configs, environments, monitoring - especially with GPUs since low efficiency is bad for everyone)
• Important to get accustomed to the typical workflow (and developing on HPC can be a hassle, e.g. VScode on login node + cgroups limitations… + utilities and tools )
• We can demo new things e.g. slurm user monitoring, OOD still many don’t know about it,
• Stress on the importance of the documentation, each cluster has its flavors, and programs have some specific tweaks specific to the cluster, checking the docs before running is always good
We can still ask during the event if students would like to have a dedicated exercise session, otherwise they work on their own. (e.g. a garage breakout room dedicated to kickstart exercises)
## Structure
- Typical streaming & notes structure.
- Demo + exercises
## Personnel
- streaming: Jarno
-
## Teaching goals
- How to use the queue / what is the queue / how does it work
- what types of jobs, sbatch/srun/ood
- checking jobs
- System Sructure (File System limitations/properties?)
- Lustre on "slow" drives, but efficient for larger files
- Local storage for random access (/tmp)
- HOME and WRKDIR
- Login node / compute node
- moving data in/out of triton?
- Resource estimation?
- seff / how much memory
- How to ask for help
- Garage / esupport / email / zulip
-
## Lectures
- Slurm from zero to hero (or sufficient) demo:
- Connection
- Data copying
- Interactive
- Serial
- Multiprocessing
- Array
- Where to install software and how to install it?
- modules
- mamba: creating and activating env
- HOME vs WRKDIR
- What is SciComp?
- How to get help?
- Garage / eSupport / Zulip
- What are RSEs?
- How to ask for help for your projects?
- Triton Issues
- Request for module / software
- General issues / announcmenet
- What are your rights as a researchers:
- Laptop
- Project folder
- RSE support
- CSC account
- Data managers help
- AI help / access
- version control
## Structure
- 12:00 - 12:20 -> Introduction to scientific computing (Enrico, Hossein)
- 12:20 - 13:30 -> demo (Simo, Thomas)
- 13:30 - 13:45 -> break
- 13:45 - 14:30 -> Environments / Modules / Filesystems (Simo, Patricia)
- 14:30 - 15:00 -> What is SciComp (Enrico, Susa)
## Notes
- Last year's version https://www.youtube.com/watch?v=tkwlfX9MSes&list=PLZLVmS9rf3nNMyt5LGAOzhWkrgdXxyGO_
## Lesson notes
### How to install software and where?
#### Key learning points
- Do you need to install it yourself?
- How to check if something is already there
- Where you should install your software
- Guide your software so that it knows where to store stuff and what to use
- Environment management, documenting your steps
- Practice working one software at a time and switching between them
#### Teaching tools: moving analogy
- Don't ask what your software can do for you, ask what you can do for your software
- All software includes assumptions (created for certain use cases)
- Icebreaker:
- Often we might look at our programs like they would be a black magical box and we run these magical commands that just happen to work
- Idea of the lecture is to demystify this
- Treat your software as a friend that would keep you company during your research project
- For getting most out of the time we spend with the software we should get to know it a bit better and look at things from it's point of view
- Perspective of the software
- Moving from home to university dorm
- Changes
- OS might change: Linux
- Private vs shared system
- Before installation:
- Environment & documentation:
- Guides from older students
- Recording your steps makes it easier for helpers to help & you to reinstall the thing
- Existing support structure helps with transitions
- Superstitious world: software works by magic
- Installing software independently is better than trying to cram everything together
- Bigger dorm creates more drama and fighting (less compatibility)
- Everyone having their individual apartments helps with this
- Practice working with one software at a time
- During installation:
- Home folder is not correct place any more
- .cache (XDG_CACHE_HOME)
- hidden folders (.-folders)
- (pkgs_dirs, envs_dirs) https://scicomp.aalto.fi/triton/apps/conda/#first-time-setup
- Dependencies: basic amenities
- Conda: installs system libraries
- conda
- Activating the installed software
- Making it available (conda activate / source activate, PATH)
- Quippy demo
- Intro: a user came to us asking for help about quippy, what is quippy about? Add image
- Docs:
- installation instructions
- conda pages
- do first time setup (avoid $HOME)
- install
- activate
- fail
- github issues
- re-install
- activate
- success
- IRL even more complicated (MPI needed, manual compilation for development purposes, ...)
- Running software:
- Environment variables: where is the kitchen
- HF_HOME ?
- Behaviour rules: don't try use all CPUs
- OMP_NUM_THREADS
- Pick the right environment: GPU codes run in GPU nodes
- CUDA_VISIBLE_DEVICES
- Common software:
- Modules:
- Changes environment variables
- Huggingface demo
- Use modules
- Set up environment variables
- Use GPUs
- Checklist (recipe for installing software)
Originally:
- Windows desktop -> Software
After installation:
- Triton -> Container -> Ubuntu -> Wine -> Software