Teaching and mentorship
I design and teach an accessible high-performance computing (HPC) workshop series that introduces blind and low-vision (BLV) researchers to the NCSA Delta cluster. It grew out of a simple gap: HPC is increasingly essential to modern research, but its tooling and documentation assume a sighted user by default. The series is both a teaching artifact and a service contribution \u2014 a reusable, evidence-informed curriculum for bringing BLV researchers into compute-intensive work.
The first edition ran as a three-day series (March 30 \u2013 April 1, 2026) with 15 participants \u2014 the first time we designed and delivered a workshop series of this kind.
Workshop philosophy
The curriculum rests on four principles that keep the learning environment effective and empowering:
Learner-centered and problem-focused
Every new skill is framed as the solution to a real research problem (e.g., "how do I run my analysis on a machine with more power?") rather than an abstract feature tour.
Command-line first, GUI as a complement
The command line is the most powerful, universal, and scriptable way to work with HPC, so it comes first. The web-based Open OnDemand portal is introduced later as an accessible complement, not a replacement.
Verbalize, don’t just visualize
Concepts usually shown visually — directory trees, cluster diagrams, data plots — are re-expressed in clear, structured language so nothing depends on a single visual modality.
Build a community of practice
Sessions are designed as a space where participants learn from the instructor and each other, trading tips and building a durable support network.
Participants also receive a pre-workshop checklist a week ahead \u2014 screen reader and terminal setup, SSH client, and ACCESS/NCSA account activation \u2014 so everyone can start hands-on from the first session.
A three-part workshop series
The series is scaffolded from foundational skills to goal-oriented research tasks, so each session builds on the last.
Workshop 1 — The lay of the land: connecting and navigating
1.5 hours (60 min instruction + 30 min Q&A)
Goal: Confidently connect to the NCSA Delta cluster, understand the remote environment, and perform basic file and directory work.
- What HPC is, via a laptop-vs-supercomputer analogy and the login-node vs compute-node distinction.
- Connecting over SSH, plus an accessibility setup pass: terminal contrast and font size, screen reader verbosity, and confirming command output is read correctly.
- A quick CLI refresher oriented around HPC-specific locations (scratch space, project directories, storage quotas).
- Introducing the Slurm scheduler with a "deli-counter ticket system" analogy for jobs, partitions, nodes, and cores, and what shared nodes actually mean.
- A hands-on first interactive job: requesting resources with salloc, running commands on the allocated node, checking status with squeue, and exiting cleanly.
Workshop 2 — Doing the work: editing files and running jobs
1.5 hours (60 min instruction + 30 min Q&A)
Goal: Write and edit files on the cluster and submit a first computational job through Slurm.
- Connecting and editing with VS Code Remote-SSH, and initializing a project in the remote Explorer.
- The anatomy of a Slurm batch script: the shebang, SBATCH directives (job name, nodes/tasks, walltime, partition, output/error, mail), and structuring scripts with clear, commented sections.
- Submitting and managing jobs (sbatch, squeue, scancel, sacct) from the integrated terminal, and reading Slurm output files.
- Using GitHub Copilot as an interpreter — generating commands from natural language, explaining cryptic errors, and lowering the cognitive load of memorizing syntax.
Workshop 3 — Scaling up: software, version control, and fine-tuning
1.5 hours (60 min instruction + 30 min Q&A)
Goal: Access software, organize a research workflow, and understand the pathway to running your own models.
- Environment modules (module avail / load / list / purge) to manage software accessibly.
- GPU computing basics: CPU vs GPU, requesting GPU resources in a batch script, and checking status with nvidia-smi.
- Research workflow development: project structure (data / scripts / results) and file transfer via VS Code or rsync.
- A conceptual path to fine-tuning a model end to end — preparing a Python script, writing a Slurm job that loads modules and requests a GPU, submitting, monitoring, and analyzing results.
- The GUI complement: Open OnDemand for file management and interactive sessions, evaluated for screen reader navigation and keyboard shortcuts.
Theoretical frameworks
The design is grounded in three complementary learning theories, which keep it rigorous rather than ad hoc:
Universal Design for Learning (UDL)
The three UDL principles are built in from the outset rather than bolted on. Multiple means of representation show up as verbal analogies and multi-format materials ("verbalize, don’t just visualize"). Multiple means of action and expression appear as the command-line and Open OnDemand options plus hands-on exercises across assistive technologies. Multiple means of engagement come from the problem-focused framing, the community of practice, and the scaffolded three-part structure.
Constructivism
Participants build a mental model of an HPC system through experience rather than memorizing a command list. The hands-on exercises — making directories, navigating, writing and submitting a real Slurm script — are the experiences through which that understanding is constructed, and the try-listen-decide loop is constructivism in action.
Andragogy (adult learning theory)
The design answers Knowles’ conditions for adult learners: the problem-focused approach explains the "why," support for different tools respects self-direction, the exercises are experiential, and the whole curriculum is of immediate value to researchers who need to use Delta.
Instructor practices
A few teaching habits do most of the accessibility work in a live, non-visual session:
- Pace slower than feels necessary, leaving ample time to type commands and listen to output.
- Narrate every command explicitly ("I am typing L S space dash L") instead of "I’ll list the files."
- Avoid ambiguous language like "over here" or "like you see"; use concrete references such as "in your home directory" or "the first column of the ls -l output."
- Provide an accessible plain-text cheat sheet of key commands with a short description for each session.
For related research, see my Research page.