DL4Proteins: A Ten-Notebook Course That Walks From NumPy to RFDiffusion

What DL4Proteins Is Actually For

The repository is a set of Jupyter notebooks hosted on GitHub and opened through Google Colaboratory. The README states the goal directly: to democratize deep learning for protein design and prediction, and to bridge the gap between research and classroom learning. That framing matters, because it sets the expectation for everything else. There is no pip-installable package here, no CLI, no API. The deliverable is ten chapters of instructional material, each one a .ipynb file under notebooks/ with a WS prefix.

The intended audience is named in the README: researchers, educators, and students. The acknowledgments mention Johns Hopkins students of the 2023 course 540.614/414, Protein Structure Prediction, and an instructional enhancement grant from the Johns Hopkins Center for Teaching Excellence and Innovation. So the material was built for a graduate or advanced undergraduate classroom first and released publicly second. If you are a computational biologist looking for a toolkit to fold a protein tonight, you are not the target reader. If you are the person who has to explain to twenty students why a diffusion model can invent a backbone that AlphaFold will then score, you are.

The Ten-Chapter Progression and Why the Order Matters

The table of contents is a curriculum, not a collection. Chapter 1 builds neural networks in NumPy. Chapter 2 rebuilds them in PyTorch. Chapter 3 covers convolutional networks. Chapter 4 introduces language models using Shakespeare and proteins side by side, which is a deliberate pedagogical move: the same architecture, two alphabets. Chapter 5 takes language model embeddings and applies transfer learning to a downstream task. Chapter 6 introduces AlphaFold. Chapter 7 covers graph neural networks for proteins. Chapter 8 covers denoising diffusion probabilistic models. Chapter 9 chains RFDiffusion into ProteinMPNN into AlphaFold. Chapter 10 covers RFDiffusion All-Atom.

The ordering is the substance. A reader who jumps straight to Chapter 9 will meet three model families at once, each with its own input format and its own failure modes, and will have no vocabulary for why the pipeline is arranged the way it is. The first five chapters exist so that the second five are legible. That is a real design decision and it is the main reason to use this repository rather than a folder of unrelated Colab links.

One caveat visible from the README alone: the repository lists no releases. There is no versioned snapshot, so the chapter list is whatever main holds at the moment you read it. The last push is dated 2026-04-17, and the README describes the repository as living and actively incorporating feedback.

Running a Chapter in Colab

Every chapter link in the README is a colab.research.google.com URL pointing at the GitHub blob path for that notebook, for example:

https://colab.research.google.com/github/Graylab/DL4Proteins-notebooks/blob/main/notebooks/WS09_PuttingItAllTogether_DesigningProteins.ipynb

That URL pattern is the entire installation procedure. You click it, Colab clones the repository into the runtime, and the notebook opens. There is no environment file to configure and no dependency list published in the README.

The one configuration instruction the README does give is a display setting: set Colab notebooks to light mode, otherwise figures and questions will not render correctly. This is a small thing that will cost you ten minutes of confusion if you skip it, particularly in chapters that rely on rendered structure images.

Because the notebooks live in Colab, the practical constraints are Colab's, not the project's. Runtime type, session timeouts, and GPU availability are all governed by your Colab tier. The README does not state which chapters need a GPU, and it does not state expected runtimes. That information is not in the supplied material, so treat it as something to discover by opening the notebooks rather than something the project tells you up front.

The Pipeline in Chapter 9: Three Models, Three Contracts

Chapter 9 is titled Putting it All Together, From RFDiffusion to ProteinMPNN to Alphafold, and it is the chapter that shows what the field's toolchain actually looks like end to end. The three stages do different jobs. RFDiffusion generates a backbone. ProteinMPNN assigns sequences to that backbone. AlphaFold then predicts the structure of the designed sequence, and the comparison between the generated backbone and the predicted structure is what tells you whether the design is self-consistent.

The teaching value is in the handoffs. Each model consumes a file produced by the previous one, and each has its own assumptions about residue numbering, chain identifiers, and coordinate conventions. A reader who has only run AlphaFold in isolation has never had to think about those interfaces. Chapter 10 extends the same idea to RFDiffusion All-Atom, which moves beyond backbone-only generation.

What the README does not provide is any statement about how long these runs take, what hardware they need, or how sensitive the results are to sampling parameters. Those are the questions a practitioner will ask first and the notebook text is the only place they might be answered. I cannot confirm from the repository description whether they are.

Where the Notebook Format Stops Being an Advantage

The choice to ship notebooks instead of a package is correct for teaching and awkward for everything else. A notebook is a linear script with hidden state. If a reader executes cells out of order, or re-runs a cell after editing it, the kernel holds objects that no longer match the visible code. In a chapter that loads a model checkpoint and then samples from it, that mismatch produces results that look plausible and are not reproducible. The repository has no test suite and no CI described in the README, so nothing catches this.

There is also no dependency pinning visible in the supplied material. The notebooks call upstream tools (AlphaFold, RFDiffusion, ProteinMPNN) whose own APIs and installation paths change independently of this repository. A notebook that worked when a course was taught can break when an upstream release lands, and the failure will appear as a Colab error rather than a version warning. The README's Issues tab is the stated channel for problems, and the authors describe the repository as living, which suggests fixes arrive but not on any schedule you can plan around.

Finally, the licence is MIT. That is permissive and it covers the notebook content. It does not relicense the third-party models the notebooks invoke, and it does not relicense the figures and images bundled in the repository's images/ directory. If you plan to reuse course material beyond the notebooks themselves, that distinction is worth checking with your own institutional guidance.

How This Differs From Running AlphaFold Directly

The obvious alternative is to skip the course and work from the upstream tools: AlphaFold's own repository and Colab notebook, RFDiffusion's repository, ProteinMPNN's repository, each with its own README and installation instructions. Those are the actual software. They are maintained by their own teams, they track their own releases, and they are what you would use in a real project.

The difference is scope and framing. An upstream AlphaFold notebook answers one question: given this sequence, what is the structure. DL4Proteins answers a different one: what is a neural network, why does a language model transfer to protein sequences, what does a graph representation buy you, and how do these pieces compose. The upstream notebooks assume you already know what a transformer is. DL4Proteins spends five chapters making sure you do.

That also means DL4Proteins is the wrong tool for a job that only needs the last step. If you have a sequence and you want a structure, the AlphaFold notebook is shorter, closer to the source, and supported by the people who built the model. The course earns its length only if you intend to read it in order.

Maintenance, Updates, and What the Preprint Adds

There are no tagged releases, so there is no upgrade path in the conventional sense. You either track main or you fork a copy at the moment you teach the course. For a classroom, forking is the sane move: it freezes the material for the term and lets you patch a broken cell without pulling in unrelated changes mid-semester. The cost is that you now own the divergence.

The preprint, listed in the README as arXiv 2511.02128 and titled DL4Proteins Jupyter Notebooks Teach how to use Artificial Intelligence for Biomolecular Structure Prediction and Design, describes the pedagogical framework, the motivation, and the learning outcomes behind each notebook. If you are adapting this for a course, that document is the place to look for the intended scope of each chapter rather than inferring it from the notebook titles. The README does not summarize its contents.

Licensing is MIT for the repository. That permits reuse and modification with attribution. It says nothing about the licences of AlphaFold, RFDiffusion, ProteinMPNN, or any dataset a notebook downloads at runtime, and those terms are set by their own projects. This is not legal advice; if you are packaging the material commercially or redistributing it, read the upstream licences yourself.

Editorial conclusion

Adopt DL4Proteins if you are teaching a protein structure or ML course and want ten runnable Colab chapters with a preprint describing the pedagogy, or if you are a structural biologist who wants to see what a diffusion model does before installing one. Do not adopt it as a production pipeline, a maintained codebase, or a substitute for the upstream tools. Before committing a syllabus to it, open Chapter 9 in Colab, confirm the RFDiffusion and ProteinMPNN cells still execute against current upstream versions, and check that your institution's Colab tier can carry the runtime load.

Official sources

1. Graylab/DL4Proteins-notebooks on GitHub
2. Issues
3. License: MIT
4. README