Thursday: Compute, Docking, and Project Planning

Historical day 4 · connect model behavior to hardware, scoring limits, and a defensible capstone plan

Overview

Thursday preserves the final taught day of the original workshop: PyTorch foundations in the early morning, a CPU/GPU activity in the morning, docking at mid-day, and a capstone roundtable in the afternoon. The asynchronous version keeps that order while replacing the live discussion with short artifacts that make your reasoning inspectable.

By the end of Thursday, you’ll be able to:

Explain tensors, devices, autograd, vectorization, and data-transfer overhead in the context of this week’s tools.
Read a timing result without assuming a GPU is automatically faster.
Distinguish docking sampling, scoring, ranking, and validation.
Explain why a favorable score or predicted pose is not proof of binding.
Choose a docking/design tool for a stated question and name the evidence it cannot supply.
Convert the week’s outputs into a scoped, staged, and reproducible capstone plan.

Thursday contract

	Core path	Full bootcamp
Active effort	3–5 hours	6–8 hours
Compute time	Usually under 30 minutes for the notebooks	Add repeated benchmark sizes/devices and optional analyses
Compute	Browser + Google Colab is sufficient; a GPU runtime is recommended for comparison	Colab or local Python/PyTorch with a visible CUDA device
Output	Tensor/autograd notebook note, benchmark plot, docking decision memo, and capstone plan	Core evidence plus recording notes, repeated measurements, and broader tool comparison
Finished when	Your plan names the question, stages, evidence, stop conditions, fallback, and next action	You can also explain how compute and scoring choices constrain interpretation

Choose a Thursday route

Core path

Complete the four modules in order. Run the notebooks, then spend at least as much time interpreting results as executing cells. In the docking lesson, choose a tool for your capstone question and explicitly list what that tool’s score cannot establish. Finish by writing the capstone plan described in the roundtable.

Full-bootcamp path

Add all workshop recordings/slides, repeat the CPU/GPU benchmarks across sizes and devices, investigate timing variability and transfer overhead, compare several docking families, and answer every roundtable reflection prompt before finalizing the project plan.

Reference path

Need to understand tensor/device errors? Use PyTorch Foundations.
Need evidence for a CPU/GPU choice? Use CPU vs. GPU Computing.
Need to reason about sampling or scores? Use Molecular Docking.
Ready to scope a project? Use Reflection and Capstone Planning, then the capstone stages.

Watch → Read → Do → Check

Module	Active time	Watch	Read	Do	Check / artifact
1. PyTorch Foundations	45–75 min	Optional original workshop recording/slides	Tensors, devices, autograd, the training loop, and links to protein models	Run the notebook; change one tensor shape/device or differentiable operation; predict the result first	Short note explains tensor shape/device and what gradient was computed, not just that the cell ran
2. CPU vs. GPU Computing	60–90 min	Optional original workshop recording/slides	Loops, vectorization, CPU/GPU architecture, and transfer overhead	Run the notebook on CPU and GPU; preserve raw timings; plot or tabulate results	Caption identifies crossover behavior, variability, transfer cost, and what should be benchmarked next
3. Molecular Docking	45–75 min	Optional original workshop recording/slides	Sampling, scoring, types of docking, limitations, and common tools	Write a tool-choice memo for one capstone question; sketch the input → candidates → scores → validation flow	Memo names at least two failure modes and evidence required beyond the docking score
4. Reflection and Capstone Planning	60–90 min	Optional original workshop recording/slides	Workflow connections, target choices, planning, and documentation prompts	Choose a target and draft the staged project brief	Plan includes question, target/epitope, tools, resources, artifacts, stop conditions, fallback, and first smoke test

Interpret the benchmark before generalizing

A useful CPU/GPU result answers more than “which number is smaller?” Record:

operation and tensor shape;
dtype and device;
warm-up strategy and synchronization;
number of repeats and variability;
whether transfer/allocation time is included; and
the workload range over which the conclusion holds.

Small or transfer-heavy workloads can be faster on a CPU. Large, parallel tensor operations often favor a GPU. The result does not automatically transfer to a different model, sequence length, batch size, or GPU.

A docking decision is a chain of evidence

biological question
      ↓
entities + constraints
      ↓
pose sampling
      ↓
scoring / ranking
      ↓
structure and interface inspection
      ↓
independent computational checks
      ↓
experimental validation

At each arrow, record what can be lost or biased. A top-ranked pose may reflect limited sampling, an imperfect scoring function, an unrealistic starting conformation, missing cofactors/waters, or a target state that is not biologically relevant.

Thursday evidence checkpoints

PyTorch note predicts and explains a tensor/device/autograd result from the practice notebook
Benchmark artifact preserves raw CPU/GPU results and explains vectorization, transfer overhead, variability, and the valid scope of the conclusion
Docking memo selects a method for a stated question, diagrams the evidence chain, and names at least two failure modes
Capstone brief names the target question, constraints, stages, artifacts, compute, stop conditions, fallback, and next smoke test

Next step

Do not begin a large design campaign until the Thursday capstone brief exists. The capstone page turns that brief into seven staged artifacts, a rubric, and a final selection memo.

← Wednesday

Capstone: Computational Binder Design →