2026 PINN Workshop — Participant Guide

You have an account on a hosted environment for the 2026 PINN Workshop. Everything runs in your web browser — there is nothing to install. This guide covers how to log in, how the system behaves day to day, and how to look after your work.

The two servers

You will use two separate servers that share the same files:

Both servers run until 10 July 2026, after which the whole environment is planned to be decommissioned and all data deleted. Unless you’re told the service is being extended, treat 10 July as the cutoff and download anything you want to keep.

Your username was sent to you by email. You choose your own password on first login (next section).

Which hub should I use? (Use the CPU hub by default)

Do most of your work on the CPU hub, and switch to the GPU hub only for the specific tasks that genuinely need a GPU. Because your files are the same on both, moving between them costs you nothing.

• Use the CPU hub (recommended default) for: writing and editing code, data preparation, plotting, debugging, small/medium models, and anything that isn’t bottlenecked on the GPU. It’s always on, never interrupted, and is a larger machine (more CPU cores and RAM) — for most of the course it’s the better experience.
• Use the GPU hub only for: actually training neural networks / PINNs that benefit from GPU acceleration, or other heavy CUDA / PyTorch / JAX compute.

Why prefer the CPU hub? The GPU is a single, shared, scarce resource — one GPU serves everyone on the hub at once, it’s only available 8 am–8 pm on most days (see below), and it’s the expensive machine. Keeping casual work on the CPU hub means the GPU stays free for the people doing real training, and your own experience is smoother (no waiting on a busy GPU, no evening shutdown). A good rhythm: develop and debug on CPU, move to the GPU only to run the heavy training, then switch back.

Course materials

The course content lives in the open repository below — you don’t need to clone anything to follow along, but it’s the reference for all exercises. A read-only copy is also available inside your home folder at course-materials/, and there’s a Course Notes tile in the JupyterLab launcher.

• Course website: https://open-aims.github.io/Julia_PINN_training_2026/
• Source repository: https://github.com/open-AIMS/Julia_PINN_training_2026

First login — do this on both servers

This environment uses first-use authentication: the password you type the very first time you log in becomes your password. There is no separate sign-up step.

Steps:

1. Open https://cpu.aims.accumulationpoint.com in your browser.
2. Enter your username (from the email) and a password of your choice, then click Sign in. That password is now set.
3. Repeat at https://gpu.aims.accumulationpoint.com using the same username and the same password.

When the servers are available

• CPU hub — always on (24/7), until 10 July 2026. Use it any time, including evenings and the week after the workshop.
• GPU hub:
  • During the workshop (Mon 22 – Fri 26 June): non-stop, day and night, so your GPU work is never interrupted during the course.
  • On other days: 8 am – 8 pm AEST — switched off overnight to save cost and back on each morning. It does not run after 10 July.
  • Use it for the GPU-accelerated parts of the course.

About the GPU

The GPU hub gives you a dedicated NVIDIA GPU with 24 GB of memory (currently an NVIDIA L4) on top of the same software stack as the CPU hub. The login page shows which machine you’re on — look for the “Running on…” line.

• Everything GPU-accelerated in the course — Julia’s CUDA.jl, PyTorch, and JAX — is preinstalled and ready; using CUDA, torch.cuda, and JAX all see the GPU with no setup on your part.
• Because GPUs are a scarce cloud resource, the exact GPU model can occasionally differ from one day to the next (for example an L4 or an A10G). The software is identical either way and your code does not change — only raw speed may vary slightly. The current machine is always shown in two places: on the login page, and on the coloured bar at the top of JupyterLab once you’re in.
• The GPU is shared by everyone on the hub — one card, not one each. The hub has one physical GPU with a single pool of memory (around 24 GB), used by the whole class at the same time. There is no per-person GPU and no automatic per-person memory slice — everyone’s work lands on the same device. The two halves of “sharing” behave very differently:
  • Compute time-shares gracefully. If several people run GPU work at once, the jobs simply take turns on the chip — everyone’s code still runs, just a little slower. Nothing breaks.
  • Memory does not share gracefully. Whatever your code puts on the GPU stays reserved until you release it. So a handful of large idle allocations can leave everyone else unable to fit their work, with an “out of memory” error — even when nobody is actively computing.
  So please be considerate of the shared memory:
  • Restart your kernel when you finish a piece of GPU work (Kernel → Restart). Killing the kernel process is the surest way to hand everything back. In Julia, note that simply setting x = nothing does not immediately free GPU memory — CUDA.jl keeps it in a reuse pool until garbage collection runs and you call CUDA.reclaim(). A kernel restart releases it all at once, every time.
  • Avoid leaving large idle allocations on the GPU between experiments.
  • (Using PyTorch or JAX from Python? Same idea — PyTorch’s caching allocator and JAX’s up-front reservation also hold GPU memory until the kernel process exits.)

Where your files live, and saving your work

When you sign in, JupyterLab opens in your personal folder — the root you see in the file browser on the left.

• On disk this is /home/efs/<your-username>, on a shared network drive (AWS EFS) mounted on both servers.
• Because it’s the same drive on both, your files are identical on the CPU and GPU hubs. Save on the GPU hub in the afternoon, open the CPU hub in the evening, and it’s right there — no copying.
• Your files persist: logging out, server restarts, and the nightly GPU shutdown don’t affect them.
• Just save normally (Ctrl/Cmd+S). JupyterLab also autosaves notebooks; save other files (scripts, data, editor buffers) yourself.

Downloading your work (before 10 July 2026)

Because the whole environment is planned to be deleted after 10 July 2026, download anything you want to keep before then (unless you’re told the service is being extended). Two easy options:

• A single file or notebook: right-click it in the file browser and choose Download.
• Your whole workspace: open download_my_work.ipynb (waiting in your home folder) and run it. It bundles your work into one my-work-backup-….zip; then right-click that .zip and choose Download.

JupyterLab can’t download a folder directly, which is why the notebook makes a single zip. The backup skips the read-only course-materials (it’s on GitHub) and reproducible package caches.

Storage quota — 20 GB per person

Each account has a 20 GB limit on the home directory.

Practical advice: avoid storing large datasets or many model checkpoints — keep only what you need for the exercises.

Data policy

JupyterLab or VS Code

You land in JupyterLab: notebooks (Julia & Python kernels), a terminal, and a file browser for your home. Prefer a full editor? Open VS Code in the browser from the launcher — it shares the same home folder, so you see the same files either way. The launcher also has a Course Notes tile that opens the course website in a new tab.

Julia and Python environments

Course packages come preinstalled in a shared, read-only base environment, with your personal environment stacked on top:

• Julia: the course stack (ModelingToolkit, NeuralPDE, Lux, CUDA, …) is just using-able. Packages you add with Pkg.add("…") go into your personal environment in ~/.julia — they persist across sessions and both hubs and don’t touch the shared base. See the welcome_julia.ipynb notebook in your home.
• Python: scientific packages (numpy, scipy, matplotlib, …) are preinstalled; pip install … lands in your personal ~/.local (persists). See welcome_python.ipynb.

More detail on the full stacks will be covered during the workshop.

Using git and your own repositories

git is installed and your home folder is persistent, so you’re welcome to work in your own git repository — clone, commit, and push as usual.

• Cloning a public repo works out of the box (git clone https://github.com/…).
• Pushing, or cloning a private repo, needs your own git authentication (a GitHub personal access token or SSH key). This is left to you to configure if you know how; we don’t manage per-user credentials.

Getting help

Stuck or locked out? Email yoni@accumulationpoint.com.