Training Workshops: 2026 Poltical Networks Conference

This repository contains the accompanying jupyter notebooks for two training workshops held on August 4, 2026 at the Political Networks conference in Manchester, UK.

Setting up your environment with the devcontainer

The notebooks in this repository depend on a specific stack of packages (pytorch, torch-geometric, CUDA drivers, and pathpyG). Instead of asking you to install all of this by hand, the repository ships a devcontainer, a ready-made description of a working environment that Visual Studio Code can build and run for you automatically.

Here is what is actually happening, in plain language:

• A container is like a lightweight, disposable virtual machine, i.e. an isolated environment that bundles an operating system, Python, and all required libraries, without touching anything else on your computer.
• The recipe to build that environment is described in .devcontainer/Dockerfile. It starts from a base image that contains pytorch, then installs torch-geometric and finally pathpyG on top. By default it installs the CPU-only build of pytorch, so it works out of the box on any machine, no NVIDIA GPU or CUDA setup required.
• .devcontainer/devcontainer.json tells VS Code how to use that recipe, e.g. which VS Code extensions to install inside the container (Python, Jupyter, linters, ...).
• Docker Desktop is the free application that actually builds and runs containers on your machine. It must be installed and running before you start.

To use the devcontainer:

1. Install and start Docker Desktop, which is available for free for Linux, Windows and MacOS.
2. Open this repository folder in VS Code.
3. VS Code will detect the .devcontainer folder and show a notification "Folder contains a Dev Container configuration file" with a Reopen in Container button. Click it (or run the command "Dev Containers: Reopen in Container" from the command palette).
4. VS Code will close, build the container (this can take a while the first time, since it downloads several GB of pytorch dependencies), and reopen connected to it. A blue indicator in the bottom-left corner shows you are working inside the container. The container only needs to be built the first time and will be reused the next time as long as you do not change the devcontainer description.
5. You can now open and run any of the notebooks. All required packages are already installed. The example networks used in the tutorials are small, so training on CPU only takes a few seconds longer than on a GPU.

The advantage of this approach is ease-of-use and reproducibility: everyone workshop participants gets the exact same environment, regardless of what is already installed on their own machine or what operating system they are using, and the same container can later be reused to run the code on another machine or an HPC cluster. Since each execution in the container will use exactly the same version of libraries, the results are also reproducible and the container description can be archived for long-term reproducibility.

Enabling GPU acceleration (optional)

If your machine has a working NVIDIA GPU with a correctly configured CUDA/WSL2 GPU setup (Docker Desktop with GPU support enabled, or a native Linux Docker host with the NVIDIA Container Toolkit installed), you can switch the devcontainer to use the GPU instead of the CPU:

1. In .devcontainer/Dockerfile, comment out the two pip install lines marked "CPU-only" and uncomment the two lines marked "GPU (NVIDIA/CUDA 12.6)" right below them (for torch and for the torch_geometric dependencies).
2. In .devcontainer/devcontainer.json, add a runArgs entry so the container is given access to your GPU:

   "runArgs": ["--gpus", "all"]

3. Rebuild the container: run the command "Dev Containers: Rebuild Container" from the command palette. This re-downloads the CUDA-enabled version of pytorch, so expect another few GB of downloads.
4. Verify it worked by opening a terminal inside the container and running:

   python -c "import torch; print(torch.cuda.is_available())"

   This should print True. If it instead prints False or raises a CUDA initialization error, GPU passthrough is not working correctly on your machine — this is usually a Docker Desktop/WSL2/driver configuration issue rather than something wrong with the devcontainer itself. Double-check that nvidia-smi works inside a plain container (docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi), that Docker Desktop's GPU support is enabled, and that your NVIDIA driver and WSL are up to date. If in doubt, the CPU-only default is a safe fallback that works everywhere.

In the following, we give the outline of the practice sessions integrated in the two tutorials:

Part I: Introduction to Deep Graph Learning

• 01-01 Introducing pathpyG
• 01-02 Importing and Visualizing Network Data
• 01-03 Supervised Node Classification and Link Prediction
• 01-04 Classification with Perceptron Model
• 01-05 pytorch, gradients, and SGD
• 01-06 Neural Networks with pytorch
• 01-07 Neural Message Passing in pyG
• 01-08 Graph Convolutional Network (GCN)
• 01-09 GCN with Node Features
• 01-10 Semi-Supervised Learning with GCN

Part II: Causality-Aware Temporal Networks

• 02-01 Temporal Networks in pathpyG
• 02-02 Time-Respecting Paths and Temporal Centralities
• 02-03 Higher-Order De Bruijn Graphs
• 02-04 Model Selection with De Bruijn Graph Models
• 02-05 Modelling Path and Trajectory Data
• 02-05 Do Standard Temporal GNNs Capture Causality?
• 02-06 Causality-Aware Temporal Graph Learning with DBGNN