Chapter 38 — Teaching Notes

One-line purpose. Take students across the line from "a program that runs" to "a result they can defend": assemble the forty-chapter solver, VERIFY it against an analytical solution with a convergence study, analyze its performance honestly, and present it as a computational-science paper. This is the book's climax; the emotional beat is "look what you built, and now make the world believe it."

Key ideas to emphasize

  • The result is not the code — it is the code plus the argument that it is right. This is the whole chapter in one sentence. Students want to be done when the code runs; the profession is not done until the code is verified, measured, and presented. Land this hard.
  • A convergence study is how you prove correctness. The single most transferable skill in the chapter. Refine the grid; if the error falls at the theoretical order (2 here), the discretization is right; if it does not, you have a bug. Drill the mechanics: observed order $= \log_2(e_\text{coarse}/e_\text{fine})$.
  • Verification $\ne$ validation. "Solving the equations right" vs "solving the right equations." Students conflate them constantly. The chapter does verification and is honest it is not validation — model that honesty. Comparing to an analytical solution is verification; comparing to a lab experiment is validation.
  • The frozen interface is why the program could grow. Tie back to Ch. 6/8: step's signature never changed while its body went serial → OpenMP → MPI. This is the deepest software-engineering idea in the book, and the capstone is where it pays off visibly.
  • Honest performance. Amdahl is a ceiling, not a promise; a memory-bound kernel plateaus below it as bandwidth saturates. And a speedup with no baseline is meaningless. The "20×" in Case Study 1 is the teaching moment — it exceeds the Amdahl ceiling, so the baseline must have been unoptimized.

Misconceptions to preempt

  • "The heat map looks like diffusion, so the code is correct." (No — a buggy solver produces plausible heat maps too. Only a convergence study rules out a bug. This is the whole point of Case Study 1.)
  • "We validated the solver against the analytical solution." (No — that is verification. Validation needs experiment. The words are not interchangeable and reviewers notice.)
  • "Order 1 where we expected order 2 is close enough." (No — it is a bug signature: a dropped $1/h^2$, a lopsided stencil, or mixed time levels. The wrong order is a diagnosis, not a rounding issue.)
  • "More cores = proportionally faster." (No — Amdahl caps it, and for this memory-bound kernel bandwidth caps it lower. Efficiency erodes as cores rise.)
  • "Bigger flop count = longer runtime." (Not for a memory-bound kernel — bandwidth, not arithmetic, sets the time. Ex. 38.21 is built to surface this.)
  • "The abstract is written first." (Write it last, to the evidence you actually have. An abstract written before the verification tends to overclaim.)

A live demonstration (10-15 minutes) — the convergence study, live

Project code/example-02-convergence-factors.f90 (or cs02-convergence.f90). Walk the discrete eigenvalue $\lambda_h = -(8/h^2)\sin^2(\pi h/2)$ approaching $-2\pi^2$, and compute the ratio column live with the class: $3.76, 3.94, 3.99 \to 4$, so order $\to 2$. Then do the dramatic part: break the stencil on the projector — drop the $1/h^2$, or make it lopsided — and show the ratio collapse away from 4. The class sees a convergence study catch a bug in real time. That single demo teaches verification better than any lecture. (Do NOT execute — hand-trace or use the pre-computed values, per the book's convention. The numbers are in the files' ! Expected output: blocks.)

Time budget (a ~3-hour session, or two 90-min)

  • 20 min — §38.1 assembly + the frozen-interface threshold concept (recap the whole solver; a triumphant tour).
  • 15 min — §38.2 the method write-up (paper voice; what a methods section must contain).
  • 40 min — §38.3 V&V + the convergence study (the core; do the live demo here).
  • 30 min — §38.4 performance (Amdahl exact, roofline intuition, memory-bound; the "20×" audit).
  • 20 min — §38.5–38.6 results, figures, paper structure, reviewer checklist.
  • 25 min — Case Study 1 (referee the manuscript) as a group activity (see Discussion Guide).
  • 10 min — Project Checkpoint: the mini-paper; assign the write-up.

Prerequisites to review before class

  • Ch. 24: the five-point stencil, FTCS, CFL ($r \le 1/4$), and the von Neumann amplification factor $G$ — the chapter leans on all of them.
  • Ch. 22: order of accuracy / truncation error ($O(h^2)$) — the theory the convergence study confirms.
  • Ch. 31: Amdahl's Law and strong/weak scaling — reused wholesale in §38.4.
  • Ch. 33/34: the OpenMP and MPI step bodies — the "same interface, many bodies" payoff.
  • Ch. 36/37: the src/app/test package and the regression-test discipline — the architecture and reproducibility.

Assessment notes

  • The natural capstone deliverable is the mini-paper (Project Checkpoint): 2-4 pages, the seven sections, the convergence table, and a README. Grade it like a reviewer: is there a convergence study, does it hit order 2, is there a stated baseline, is every claim scoped to its evidence?
  • Watch for the two most common failures: (1) a "results" section with heat maps but no convergence study (correctness unproven), and (2) a performance claim with no baseline. Both are the exact mistakes Case Study 1 dissects — students who did that case study should not make them.