Chapter 8 — Teaching Notes

One-line purpose. Give students the module — the container that makes large Fortran possible — and the judgment to organize code into a clean, buildable hierarchy, so that every later chapter (types, numerics, performance, parallelism) has a place to live.

Key ideas to emphasize

  • The module is a WALL, not just a folder. The transformative idea (the 🚪 Threshold Concept of §8.4) is that a module encapsulates — private state is genuinely unreachable, not merely discouraged. Keep returning to this; it is what separates modules from "a file with some subroutines in it."
  • Explicit interface for free (§8.2). This is the load-bearing payoff and the one students under-value. Drive home that intent, keyword args, optional args, and assumed-shape arrays — everything they liked in Ch. 6 — only work across files because the procedure is in a module. Modules are what make Ch. 6 real.
  • Compile order is a topological sort (§8.5). Almost every student hits "Cannot open module file" once. Pre-empt the panic: it means out of order, not broken code. Have them provoke it deliberately.
  • COMMON → module (§8.4). The single most valuable modernization move; frame it as removing a class of bug, not tidying. Case Study 1 is the vivid version.
  • Submodules are about BUILD time, not run time (§8.3). Correct the common misconception that submodules make code faster to run. They make it faster to rebuild.

Misconceptions to preempt

  • "A .mod file is the compiled module." (No — it is the interface; the code is in the .o, which must still be linked.)
  • "Submodules speed up the program." (No — identical generated code; they cut rebuild cost.)
  • "use is like C's #include." (No — use imports named, typed, checked entities; INCLUDE pastes text. This is precisely the §8.4 improvement.)
  • "Module variables reset each call." (No — implicitly save; they persist for the whole run.)
  • "Private is just a convention." (No — the compiler enforces it; a private name does not exist outside.)
  • "Circular dependencies are a Fortran limitation to work around." (No — they signal a design problem; the rejection is a feature.)

A live demonstration (8 minutes)

Compile the three-file project checkpoint (kinds.f90, heat_solver.f90, heat_io.f90, heat.f90) live. 1. Build it correctly, in order — it runs. 2. Now gfortran heat.f90 kinds.f90 … (driver first) → the "Cannot open module file 'kinds.mod'" error. Let the class see it and diagnose it. Fix by reordering. (This inoculates them against the #1 confusion.) 3. Add call step(field, alpha) (drop dt) → compile error, caught because step is in a module. Point out this would have been silent garbage with an external procedure. That contrast is the chapter.

Class-time budget (~50 min)

  • 8 min: the sharing problem; the module; use ... only: (§8.1).
  • 12 min: public/private, the encapsulated-counter demo, and "explicit interface for free" (§8.2).
  • 8 min: submodules — interface vs implementation, the build-time win (§8.3).
  • 8 min: COMMON→module, the 🚪 Threshold Concept, live compile-order demo (§8.4–8.5).
  • 8 min: designing the hierarchy; the heat-solver split (§8.6 + Project Checkpoint).
  • 6 min: wrap-up, spaced review of Ch. 6/7, bridge to derived types.

Prerequisites to review

Ch. 6 (procedures, intent, assumed-shape, keyword/optional args, internal procedures) is essential — the whole "explicit interface" argument builds on it. Ch. 7 (namelist, newunit, iostat) for heat_io. Ch. 3 (kinds/dp) and Ch. 5 (arrays, column-major) are used throughout. If students are shaky on Ch. 6's assumed-shape arrays, review that first — §8.2 leans on it hard.

Connections

Backward: Ch. 3 (kinds), Ch. 5 (arrays), Ch. 6 (procedures/interfaces), Ch. 7 (I/O). Forward: Ch. 9 (the field_t type lives in a module built here), Ch. 13 (implicit-save trap; error handling), Ch. 16 (fpm derives the compile order), Ch. 17–18 (COMMON→module modernization), Ch. 24 (the real stencil replaces the placeholder step behind the same interface), Ch. 36 (real large-code hierarchies), Part VIII (parallel step variants behind the frozen interface). Chapter 8 is where the book's software-engineering spine starts.