Bibliography

Sources are grouped by confidence tier, following the book's citation-honesty policy (see any chapter's further-reading, or _style-bible.md). Tier 1 are works we are confident exist; Tier 2 are real ideas whose exact publication we have not pinned down; Tier 3 are constructed teaching examples, labeled where they appear.

Tier 1 — Verified canonical sources

• "VTK File Formats" (Kitware documentation) — the authoritative specification of the legacy .vtk format and the XML formats (.vti, .vtr, .vts, .vtu, and parallel variants); the primary source for the exact legacy STRUCTURED_POINTS header (magic string, DATASET, DIMENSIONS/ORIGIN/SPACING, POINT_DATA, SCALARS/LOOKUP_TABLE) and the XML ImageData structure used in §26.1–26.2. Available from the VTK/Kitware site (also distributed as the "VTK File Formats" PDF).
• Anderson et al., LAPACK Users' Guide, SIAM — authoritative LAPACK reference incl. the routine naming scheme and calling conventions; reference pages mirrored at netlib.org/lapack.
• Ayachit, The ParaView Guide (Kitware) — the official ParaView manual; the loading-data and animation chapters are the source for the §26.3 ParaView workflow (Apply, color-by, the time series and slider). Free PDF from the ParaView site.
• Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, Prentice Hall — source of the chapter epigraph ("The only way to learn a new programming language is by writing programs in it… hello, world"), from its opening chapter. Canonical and verifiable.
• Brian W. Kernighan and P. J. Plauger, The Elements of Programming Style — source of the chapter epigraph; classic on writing debuggable code.
• Brian W. Kernighan and Rob Pike, The Practice of Programming, Addison-Wesley — the "Debugging" and "Testing" chapters; the method Case Study 1 applies.
• CF (Climate and Forecast) Metadata Conventions, cfconventions.org — the standard for units (UDUNITS), coordinate variables, standard_name/long_name, _FillValue, and the global provenance attributes of Section 25.5.
• CMake documentation, cmake.org/documentation — the build system large cross-platform scientific codes use.
• Compiler Explorer (godbolt.org) — real, free tool; supports gfortran; used for the assembly-inspection guidance (packed …pd vs scalar …sd). Confident.
• Compiler Explorer, godbolt.org (gfortran) — inspect how pure/elemental affect generated code.
• Compiler Explorer, godbolt.org (gfortran) — view the vectorized instructions emitted from whole-array statements and compare the two loop orders of a 2D sweep.
• Compiler Explorer, godbolt.org (with gfortran) — view the indirect dispatch emitted for a polymorphic call versus the inlined/vectorized monomorphic equivalent.
• Compiler Explorer, godbolt.org — select gfortran with -fopenmp -O3 to see how !$omp parallel do` and `!$omp simd change the generated code.
• Compiler Explorer, godbolt.org — supports gfortran; view generated assembly.
• Compiler Explorer, godbolt.org — view the assembly a contiguous promise unlocks (gfortran).
• Compiler Explorer, godbolt.org — with gfortran selected, shows how selected_real_kind(15, 307) resolves to a concrete kind.
• David B. Kirk & Wen-mei W. Hwu, "Programming Massively Parallel Processors," Morgan Kaufmann — canonical GPU-architecture text (warps, coalescing, occupancy, divergence, tree reductions); code is CUDA C but concepts transfer.
• David Goldberg, "What Every Computer Scientist Should Know About Floating-Point Arithmetic," ACM Computing Surveys, 1991 — the canonical, freely available treatment of IEEE 754, rounding, epsilon, and cancellation.
• Edsger W. Dijkstra, "Go To Statement Considered Harmful," Communications of the ACM 11(3), 1968 — the structured-programming argument behind exit/cycle/named loops replacing goto; source of the chapter epigraph.
• Epigraph — Harold Abelson & Gerald Jay Sussman, Structure and Interpretation of Computer Programs (MIT Press). "Programs must be written for people to read, and only incidentally for machines to execute." A canonical, widely reproduced line from the SICP preface; wording is confident but verify the exact edition/preface before print.
• FFTW manual, fftw.org — the FFT library and its Fortran interface.
• findent — open-source fixed-form to free-form converter/reindenter (Willem Vermin). Confident it exists; confirm current home/URL.
• FORD, github.com/Fortran-FOSS-Programmers/ford — the documentation generator.
• Fortran Discourse (fortran-lang.discourse.group) — community threads on -ffpe-trap, gdb-with-Fortran, and error-handling design.
• Fortran Discourse, fortran-lang.discourse.group — real-world threads on allocatable-vs-pointer components and PDT compiler bugs.
• Fortran Package Manager (fpm), fpm.fortran-lang.org — scans use statements and derives compile order automatically.
• Fortran stdlib (stdlib.fortran-lang.org) — a maintained library's dynamic containers (the growable-array idea, hardened).
• Fortran stdlib (stdlib.fortran-lang.org) — community error-handling utilities (error_stop, check, optval, logger) as idiomatic modern patterns.
• Fortran stdlib, stdlib.fortran-lang.org — community library whose array/statistics modules model idiomatic modern array code.
• fortran-lang.org (Learn tutorials + in-browser playground) — runnable intros to branching and loops; used for "predict the output" checks.
• fortran-lang.org (Learn) — current community tutorials on formatted I/O and file handling.
• fortran-lang.org and the Fortran Discourse (fortran-lang.discourse.group) — community discussion of allocatable-vs-pointer and growable arrays.
• fortran-lang.org LAPACK/BLAS tutorials and the Fortran stdlib linear-algebra module (stdlib.fortran-lang.org, stdlib_linalg: solve, eig, svd, lstsq) — modern, type-checked wrappers over the raw LAPACK calling convention.
• fortran-lang.org — "Learn" pages and mini-book sections on derived types and OOP, with runnable snippets.
• fortran-lang.org — coarray tutorials and the Discourse forum.
• fortran-lang.org — community docs on kinds, iso_fortran_env (real32/real64/real128), and precision.
• fortran-lang.org — community documentation, tutorials, and the ecosystem context (fpm, stdlib) for using NetCDF/HDF5 from Fortran.
• fortran-lang.org — community MPI/coarray/OpenMP tutorials and the Discourse forum.
• fortran-lang.org — community parallel/GPU tutorials and Discourse forum.
• fortran-lang.org — interoperability tutorials and the modern toolchain; the best free starting point after the NumPy docs.
• fortran-lang.org — learning pages on modules and submodules; compilable examples; the module procedure shorthand shown beside the full form.
• fortran-lang.org — learning resources / Quickstart tutorial covering procedures and modules; actively maintained community docs.
• fortran-lang.org — learning resources and the Discourse forum; current examples of modern-Fortran string handling and parsing.
• fortran-lang.org — modern-style guidance and modernization discussions.
• fortran-lang.org — OpenMP and parallel-programming tutorials with runnable examples, and the Discourse forum.
• fortran-lang.org — parallel-programming tutorials (do concurrent, coarrays, OpenMP) and the Discourse forum.
• fortran-lang.org — the "Derived Types" and "Type-Bound Procedures" learning pages; concise, runnable, current.
• fortran-lang.org — the "Learn" and "Get Started" pages: installing a compiler and compiling a first program on each platform.
• fortran-lang.org — the "Learn" tutorials and mini-book cover variables, types, and operators with runnable snippets.
• fortran-lang.org — the "Learn"/Quickstart resources for the modern side of every mapping (modules, derived types, array features); actively maintained community docs.
• fortran-lang.org — the C-interoperability tutorials / mini-book; example-driven, with compile commands.
• fortran-lang.org — the community hub, including "migrating from older Fortran" and best-practices material.
• fortran-lang.org — the community hub: fpm, stdlib, the playground, and the discourse forum.
• fortran-lang.org, "Learn → Arrays and loops" — concise current tutorial on this chapter's topics with runnable snippets.
• fpm (fpm.fortran-lang.org) and FORD — packaging and documentation for the reproducibility package (§38.6, Case Study 2 Phase 5).
• fpm documentation and repository, github.com/fortran-lang/fpm — manifest reference (fpm.toml keys), project-layout conventions, dependency handling.
• fpm — the Fortran Package Manager, fpm.fortran-lang.org — the app/src/test convention, fpm.toml, and automatic compile-order derivation from use statements.
• fprettify — open-source Fortran source formatter. Confident it exists; confirm current home/URL.
• Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley — source of the chapter epigraph ("show me your tables…"); the canonical statement that data structure is primary. Quote is well known and verified.
• GCC / gfortran documentation (GNU Fortran manual) — the I/O and edit-descriptor pages documenting the compiler's actual formatting behavior used throughout (i0 minimum width, iw.m zero-padding, f0.d self-sizing, the unlimited-repeat * and the : colon descriptor).
• GCC / gfortran documentation (GNU Fortran manual) — the intrinsic-procedure and I/O pages document the compiler's actual behavior, including the edit-descriptor width rules used here (i0 minimum width; iw.m zero-padding; asterisk-fill on field overflow).
• GCC / gfortran documentation (the GNU Fortran manual) — do concurrent support, and the warning/check flags (-Wall, -Wsurprising, -fcheck=all).
• GCC / gfortran documentation (the GNU Fortran manual) — authoritative for gfortran's processor-defined choices: units of recl, default formatted-output rounding, newunit, and the exact form of list-directed and namelist output.
• GCC / gfortran documentation (the GNU Fortran manual) — compiler-specific behavior for intent diagnostics, the F2018 recursive-by-default default, -Wall, and -fcheck=all.
• GCC / gfortran documentation (the GNU Fortran manual) — supported Fortran 2003/2008 OOP features; notes the corners of finalization support in particular.
• GCC / gfortran documentation (the GNU Fortran manual) — the -std=legacy and -std=f2018 dialect flags, and the diagnostics for deleted features; the practical bridge between reading old code and compiling the new.
• GCC / gfortran documentation (the GNU Fortran manual) — the free compiler used throughout the book.
• GCC / gfortran documentation — "Intrinsic Procedures" and the ISO_FORTRAN_ENV sections; the authoritative behavior of selected_real_kind, precision, range, mod, modulo, etc., and the kind numbers this compiler assigns.
• GCC / gfortran documentation — -std=legacy, -std=f2018, -Wall, -fcheck=all; the list of obsolescent/deleted features.
• GCC / gfortran documentation — .mod/.smod handling and the -I/-J module-search flags behind the compile-order rule.
• GCC / gfortran documentation — Fortran 2003/2008 feature-status pages; the honest reference for what is supported, especially the incomplete PDT support.
• GCC / gfortran documentation — module file search (-I, -J), .mod/.smod behavior, and the exact "Cannot open module file" diagnostic.
• GCC / gfortran documentation — supported features and standard conformance for pointers, contiguous, is_contiguous, move_alloc.
• GCC / gfortran documentation — the "Fortran Dialect" / legacy pages document exactly what -std=legacy accepts and how fixed-form is parsed.
• GCC / gfortran documentation — the real kinds, the ieee_arithmetic module, and the -ffpe-trap/-ffpe-summary flags as implemented by the book's compiler.
• GCC / gfortran manual — "Mixed-Language Programming" and "Interoperability with C" sections; documents the compiler's name mangling and the ISO_Fortran_binding.h descriptor header.
• GCC / gfortran manual, "Code Gen Options" and "Debugging Options" — the reference for -fcheck, -ffpe-trap, -fbacktrace, -finit-real, -fsanitize.
• GCC / gfortran manual, "Optimize Options" — the authoritative list of what each -O level enables, what -ffast-math permits, and the full -fopt-info family used in §27.1 and §27.5. Behavior described (vectorization at -O3, no loop unrolling without -funroll-loops, inlining at -O2/-O3) is per the GCC docs; confident, though exact enablement can shift across GCC versions.
• GCC / gfortran OpenMP documentation — the -fopenmp flag, the omp_lib module, supported OpenMP version, gfortran-specific notes.
• GCC gfortran manual (gcc.gnu.org/onlinedocs/gfortran) — the compiler whose behaviour the examples target.
• GCC/gfortran documentation — the -fcoarray option (single/lib), coarray support notes and known limitations; primary source for what a given gfortran supports.
• GCC/gfortran OpenACC documentation, gcc.gnu.org (OpenACC wiki) — reference for gfortran's -fopenacc support (the no-NVIDIA path to compile the OpenACC examples).
• GDB manual (sourceware.org/gdb), incl. Fortran-language notes — breakpoints, inspecting variables and array slices, backtraces.
• Gene H. Golub & Charles F. Van Loan, Matrix Computations, Johns Hopkins University Press — canonical reference for the algorithms under LAPACK: LU with partial pivoting, QR, the symmetric eigenproblem, the SVD, and conditioning.
• Gene M. Amdahl, "Validity of the single processor approach to achieving large scale computing capabilities," AFIPS Conference Proceedings, 1967 — the original statement of Amdahl's Law.
• Georg Hager & Gerhard Wellein, Introduction to High Performance Computing for Scientists and Engineers, CRC Press — honest performance measurement, scaling, and memory-bandwidth reasoning (§38.4).
• George E. P. Box — the aphorism "Essentially, all models are wrong, but some are useful" (chapter epigraph). A genuine, widely-cited Box line (from his work on empirical model-building, e.g. Box & Draper, Empirical Model-Building and Response Surfaces, Wiley, 1987, p. 424, and the 1976 JASA paper "Science and Statistics"). Confident it is real.
• GNU binutils, nm and objdump — tools to list object-file symbols and see mangled vs bind(c) names side by side (used in §14.2).
• GNU Make manual, gnu.org/software/make/manual — targets, prerequisites, and module dependency order in hand-written Fortran Makefiles.
• gnuplot official documentation — the splot, pm3d, and set palette sections behind §26.4's three-line heat map.
• Golub & Van Loan, Matrix Computations, Johns Hopkins University Press — the algorithms inside LAPACK (LU, QR, eigenvalues, SVD).
• Gordon E. Moore, "Cramming more components onto integrated circuits," Electronics, 1965 — Moore's Law.
• Gregory Ruetsch & Massimiliano Fatica, "CUDA Fortran for Scientists and Engineers," Morgan Kaufmann/Elsevier — the definitive CUDA Fortran book (kernels, device memory, launch config, atomics, reductions). Verify current edition.
• Hennessy & Patterson, Computer Architecture: A Quantitative Approach (Morgan Kaufmann) — the standard reference for caches, the memory hierarchy, and the roofline model behind §27.2 and Case Study 2. Confident.
• Herb Sutter, "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software," Dr. Dobb's Journal, 2005 — the essay naming the end of automatic clock-speed gains. (Also the epigraph of the Part VIII intro.)
• IEEE Std 754-2019, IEEE Standard for Floating-Point Arithmetic — the primary source for encoding, rounding modes, and exception behavior.
• ISO/IEC 1539-1 (current Fortran standard, 2018/2023) — its "obsolescent features" annex is effectively a table of contents for this chapter.
• ISO/IEC 1539-1 (the Fortran standard, 2018 edition) — the normative account of obsolescent vs deleted features (collected in the standard's annex) and the source of truth for the status claims in §19.5.
• ISO/IEC 1539-1:2018 (Fortran 2018 standard) — authority on construct meaning and on obsolescent vs deleted features.
• ISO/IEC 1539-1:2018 (Fortran 2018 standard) — clauses on derived-type definition, type-bound procedures, structure constructors, and allocatable components; the final word on the rules.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — definitive semantics for pointer association, associated, move_alloc, is_contiguous, and contiguous.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — definitive semantics of type extension, polymorphic assignment, the select type matching rules, deferred bindings, and when finalization occurs.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — primary source for use association, public/private, separate module procedures, submodules, and host association.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — primary source for normal vs error termination, stop codes, and error_unit/iostat_end/stat_failed_image.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the authoritative rules for procedures, dummy-argument intents, pure/elemental requirements, assumed-shape, and the "recursive by default" change.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the authority on all control constructs, do concurrent semantics, and forall's obsolescent status.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the primary source for the no-aliasing rule (the clause restricting entities associated with dummy arguments, forbidding aliasing a defined/written argument with another accessed entity). The document is Tier 1; the exact clause number is NOT pinned in prose (see Tier 2 note).
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the reference for reshape/order, matmul/dot_product/transpose semantics, external-procedure argument association (why LAPACK calls are unchecked), and error stop with a stop-code.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the reference for storage_size, iso_fortran_env (real64, int64), and integer-kind ranges used in the size-estimate examples.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — the standard -std=f2018 enforces; the authority for implicit none, free-form source, and list-directed vs formatted output.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard), Clause 16 — primary source for the guaranteed behavior of the array intrinsics.
• ISO/IEC 1539-1:2018 (the Fortran standard), Clause 18, "Interoperability with C" — the primary source for what is guaranteed and required of an interoperable entity.
• ISO/IEC 1539-1:2018, the Fortran standard — normative definition of images, coarrays, segments, synchronization, collectives, and teams.
• John L. Gustafson, "Reevaluating Amdahl's Law," Communications of the ACM, 1988 — the scaled-speedup (weak-scaling) reframing.
• John L. Hennessy & David A. Patterson, "Computer Architecture: A Quantitative Approach," Morgan Kaufmann — the canonical text on the power wall, multicore, and Amdahl's Law in architecture.
• Kernighan & Ritchie, The C Programming Language, 2nd ed., Prentice Hall — source of the chapter epigraph; the reference for reading C prototypes, const, pointer decay, and struct layout.
• LAPACK online documentation and reference source, netlib.org/lapack — primary source for each routine's interface; the man pages read in Section 21.4.
• LAPACK Users' Guide, 3rd ed. (E. Anderson, Z. Bai, C. Bischof, S. Blackford, J. Demmel, J. Dongarra, et al.), SIAM — the definitive guide to the naming scheme, calling sequences, and per-argument semantics (including lda and info) for dgesv, dsyev, dgesvd, dgtsv, dgels.
• Lloyd N. Trefethen & David Bau III, Numerical Linear Algebra, SIAM — clear graduate text on conditioning, stability, pivoting, and the SVD; directly supports Case Study 1 (pivoting) and Case Study 2 (normal-equations conditioning).
• Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley — canonical treatment of changing working code without changing behavior; source of the chapter epigraph ("Any fool can write code that a computer can understand…").
• matplotlib documentation — the imshow/pcolormesh/contour references and the "Choosing Colormaps" guide, behind §26.4–26.5, including the perceptual-uniformity discussion motivating viridis/inferno.
• Meson and Ninja build tools (mesonbuild.com) — the build backend modern f2py uses on Python 3.12+.
• Metcalf, Reid & Cohen, Modern Fortran Explained (Oxford University Press) — the definitive reference; its appendices enumerate the obsolescent and deleted features that underlie §19.5's "Status" column, and it is the authority for the COMMON/EQUIVALENCE/statement-function translations.
• Metcalf, Reid & Cohen, Modern Fortran Explained, Oxford University Press — the definitive language reference.
• Michael Feathers, Working Effectively with Legacy Code, Prentice Hall — the standard reference on getting a test harness around untested legacy code (the discipline of Case Study 2).
• Michael L. Overton, Numerical Computing with IEEE Floating Point Arithmetic, SIAM — a short readable book devoted entirely to the standard; an ideal next step at this chapter's level.
• Michael Metcalf, John Reid & Malcolm Cohen, Modern Fortran Explained, Oxford University Press — the reference for the Fortran I/O (unformatted/stream, Ch. 7) that Section 25.1 scales up, and for storage_size/iso_fortran_env intrinsics.
• Milan Curcic, Modern Fortran, Manning — modern-style I/O in the context of real programs.
• Milan Curcic, Modern Fortran: Building Efficient Parallel Applications, Manning — modern, project-driven treatment.
• Milan Curcic, Modern Fortran (Manning) — practical modern-Fortran patterns for building real programs and wiring in external libraries.
• MPI Standard, mpi-forum.org — the message-passing specification, including Fortran (mpi_f08) bindings.
• Netlib BLAS pages, netlib.org/blas — reference BLAS and the definition of Levels 1/2/3.
• Nicholas J. Higham, Accuracy and Stability of Numerical Algorithms, SIAM — the definitive reference on rounding-error analysis, conditioning, and stability (the rigorous version of Section 20.5).
• NumPy f2py documentation — the Chapter 15 tool that automates the interface written by hand here.
• NumPy documentation — array flags, strides, C- vs F-contiguity, dtypes, and the C-API notion of an extension module. Foundation for §15.3.
• NumPy f2py user guide (official NumPy documentation) — the authoritative reference for the -c -m workflow, intent/depend/!f2py directives, .pyf signature files, .f2py_f2cmap, and the current build backend (distutils vs Meson). Version-specific; trust the docs for the installed NumPy.
• NVIDIA HPC SDK documentation, incl. the CUDA Fortran Programming Guide, docs.nvidia.com — primary source for nvfortran, the device/global/value attributes, <<<>>> launch syntax, one-based thread indexing, and the -acc/-cuda/-Minfo=accel flags.
• Open MPI (open-mpi.org) and MPICH (mpich.org) — the two dominant open-source MPI implementations; documentation for the mpif90/mpirun wrappers and process placement.
• OpenBLAS project documentation, openblas.net — the tuned, open-source drop-in BLAS/LAPACK implementation and its build/threading controls.
• OpenCoarrays project, opencoarrays.org — the open-source runtime that gives gfortran multi-image execution, and the caf/cafrun wrappers; documents install and the honest feature/support state (including teams).
• ParaView (paraview.org) and matplotlib (matplotlib.org) — the visualization tools of §38.5 (Fortran computes; these draw).
• Patrick J. Roache, Verification and Validation in Computational Science and Engineering, Hermosa Publishers — the standard-setting treatment of V&V and order verification; source of the "solving the equations right / solving the right equations" framing used in §38.3.
• Peter Pacheco, "An Introduction to Parallel Programming," Morgan Kaufmann — MPI, OpenMP, and CUDA side by side; supports the part's "same solver, several models" framing.
• pFUnit, github.com/Goddard-Fortran-Ecosystem/pFUnit — the unit-testing framework (NASA Goddard).
• Press, Teukolsky, Vetterling & Flannery, Numerical Recipes, Cambridge University Press — finite-difference, stability, and convergence background under the heat solver.
• Python ctypes documentation (Python standard library) — CDLL, restype/argtypes, byref, numpy.ctypeslib.ndpointer. The §15.4 mechanism.
• Richard Hamming, Numerical Methods for Scientists and Engineers, McGraw-Hill/Dover — source of the epigraph "The purpose of computing is insight, not numbers" (a canonical motto of the book; exact page/edition to confirm).
• Richard P. Feynman — Case Study 1 epigraph, "The first principle is that you must not fool yourself — and you are the easiest person to fool" (Caltech commencement address, 1974, "Cargo Cult Science"); Case Study 2 epigraph, "If it disagrees with experiment, it is wrong…" (The Character of Physical Law, 1965; also the Feynman Lectures). Both genuine, widely quoted.
• Richard W. Hamming, Numerical Methods for Scientists and Engineers (1962) — source of the chapter epigraph, "The purpose of computing is insight, not numbers"; used as the book's motto/epigraph by Hamming himself.
• Robert H. Dennard et al., "Design of Ion-Implanted MOSFETs with Very Small Physical Dimensions," IEEE Journal of Solid-State Circuits, 1974 — the source of "Dennard scaling."
• Samuel Williams, Andrew Waterman & David Patterson, "Roofline: An Insightful Visual Performance Model for Multicore Architectures," Communications of the ACM 52(4), 2009 — the roofline model and arithmetic intensity of §38.4.
• Schroeder, Martin & Lorensen, The Visualization Toolkit (Kitware) — the book behind VTK; its early chapters define the data model (points, cells, attributes, dataset types) that underlies the "which format?" decision in §26.1.
• SciPy and NumPy source trees — production f2py usage at scale (e.g., scipy/linalg LAPACK wrappers); the most instructive real examples.
• stdlib documentation and repository, github.com/fortran-lang/stdlib — module-by-module API and the current fpm dependency instructions.
• Stephen Chapman, Fortran for Scientists and Engineers, McGraw-Hill — the widely adopted teaching text.
• Steve McConnell, Code Complete, Microsoft Press — the defensive-programming chapter (assertions, pre/postconditions).
• The Fortran Discourse, fortran-lang.discourse.group — community help, especially for install problems.
• The Fortran Playground (linked from fortran-lang.org) — run the chapter's small programs in-browser to confirm hand-predicted outputs.
• The Fortran Standard Library (stdlib), stdlib_strings and stdlib_string_type — community split, replace_all, to_lower, starts_with, and a string_type; the higher-level routines this chapter builds by hand. Docs at stdlib.fortran-lang.org.
• The GCC documentation, "Options to Request or Suppress Warnings" — the precise contents of -Wall/-Wextra/-Wpedantic.
• The GNU Fortran (gfortran) manual, "Invoking GNU Fortran" — the authoritative reference for every compiler flag (-std, -Wall, -O, -g, -fcheck, -c, -o).
• The HDF Group HDF5 documentation (with Fortran bindings).
• The HDF Group, HDF5 documentation: the HDF5 User's Guide and the HDF5 Fortran Reference Manual (docs.hdfgroup.org, support.hdfgroup.org) — the primary reference for the h5*f interface used in Section 25.3 (h5open_f/close_f, h5fcreate_f/open_f/close_f, h5screate_simple_f, h5dcreate_f/write_f/read_f, h5pcreate_f/set_chunk_f/set_deflate_f/set_shuffle_f, h5gcreate_f/gn_members_f, the hid_t/hsize_t kinds, and the H5T/H5F_/H5P_ constants).
• The MPI Standard, MPI Forum (mpi-forum.org) — the authoritative specification of every routine, argument, and datatype used in this chapter (point-to-point, collectives, non-blocking, MPI-IO). MPI-1.0 was released in 1994; the current standard is MPI-4.x.
• The MPI standard, mpi-forum.org — read beside the OpenMP spec to feel the shared-memory (Ch. 33) vs distributed-memory (Ch. 34) split.
• The MPI standard, mpi-forum.org — the collectives (MPI_Allreduce, MPI_Bcast) that co_sum/co_broadcast mirror; referenced for the Ch.34 comparison.
• The OpenACC specification, openacc.org — authoritative definition of every !$acc directive/clause used (parallel loop, data, copyin/copyout/copy/create/present, update, reduction, collapse).
• The OpenMP Application Programming Interface specification, openmp.org — the primary source; the data-sharing and scheduling rules of §33.3–33.4 are defined here, with Fortran examples. The companion "OpenMP Examples" document is a guided tour of every construct.
• The OpenMP reference guide / "cheat sheet" from the OpenMP Architecture Review Board (openmp.org/resources) — a two-page card of every directive and clause.
• The OpenMP specification (openmp.org) and the MPI standard (mpi-forum.org) — primary sources for the two shared/distributed workhorses named in §31.3.
• The OpenMP specification (openmp.org) — referenced for the hybrid MPI+OpenMP model (one MPI rank per node × OpenMP within), developed in Ch. 33.
• The OpenMP specification, openmp.org — the target/map offload directives, the standardized alternative to OpenACC.
• The OpenMP standard (openmp.org) and the MPI standard (mpi-forum.org) — primary sources for the parallel back-ends assembled in §38.1 and analyzed in §38.4.
• TOP500 project, top500.org — supercomputer rankings and statistics.
• TOP500 project, top500.org — the scale (millions of cores) that makes weak scaling matter.
• Unidata / UCAR, NetCDF documentation: the NetCDF User's Guide (data model, classic vs netCDF-4, ncdump/ncgen) and the NetCDF Fortran-90 Interface Guide (docs.unidata.ucar.edu/netcdf-fortran) — the primary reference for every nf90_ routine used in Sections 25.2, 25.4, 25.5 (nf90_create/def_dim/def_var/put_att/enddef/put_var/get_var/open/inq_varid/inquire_dimension/get_att/strerror, and the NF90_ constants).
• Unidata NetCDF user guide (with its Fortran interface section).
• Unidata NetCDF User Guide, and The HDF Group HDF5 documentation — the self-describing scientific formats introduced ahead of Chapter 25.
• Universal Ctags, ctags.io — the tags index enabling definition-jumping and "find all callers" navigation (§36.4).
• valgrind and gfortran -fcheck=all — tools that catch leaks, use-after-free (dangling), and many pointer misuses (developed in Ch. 13).
• Valgrind documentation (valgrind.org), the Memcheck manual — leak reports and invalid-access diagnostics.
• VisIt User Manual (Lawrence Livermore National Laboratory) — the official VisIt documentation; the counterpart workflow (database grouping, Pseudocolor plots, time controls) referenced in §26.3.
• William Gropp, Ewing Lusk & Anthony Skjellum, "Using MPI: Portable Parallel Programming with the Message-Passing Interface," MIT Press — the definitive tutorial, by MPI's own authors; mirrors this chapter's model → point-to-point → collectives → decomposition progression.
• William Gropp, Torsten Hoefler, Rajeev Thakur & Ewing Lusk, "Using Advanced MPI," MIT Press — non-blocking and one-sided communication, MPI-IO, derived datatypes, communicators; the sequel for latency hiding and parallel I/O.

Tier 2 — Attributed (specifics unverified)

• "0.30000000000000004.com" — a one-page cross-language demonstration that 0.1 + 0.2 gives the same result everywhere (floating point is a hardware standard, not a language quirk); community-maintained, confirm URL.
• "10× (several-fold) loop-order penalty," "50–100× pure-Python vs Fortran," "typically 4 real(dp) per AVX instruction / 32-byte vectors" — illustrative orders of magnitude, NOT measured (gfortran not installed; no code run). Framed throughout as "typical; measure it yourself." All performance/speedup numbers in the chapter are Tier 2 illustrative per the style-bible honesty rule.
• "MPI is the assembly language of parallel computing" — the chapter epigraph. A widely repeated HPC adage; genuinely folkloric, with no single reliably attributable origin, so framed in the text as "a common saying among HPC programmers" rather than credited to a person.
• "Type-bound procedure calls are free without polymorphism / dispatch costs only under true polymorphism" — a correct general characterization of compiler behaviour, but the exact inlining outcome is compiler- and optimization-level-dependent (framed as such).
• ACM "Artifact Review and Badging" policy (acm.org) — the reviewer-facing reproducibility checklist as a publication requirement; an evolving policy, confirm current wording.
• AddressSanitizer documentation (LLVM/GCC) — the faster compile-in alternative to Valgrind; exact flag behavior varies by compiler version, so confirm against your toolchain.
• Agner Fog, optimization manuals (agner.org/optimize) — real, free, well-known x86 optimization references. Confident they exist; specifics not cited.
• Alan H. Karp & Horace P. Flatt, "Measuring Parallel Processor Performance," Communications of the ACM, 1990 — source of the experimentally-determined serial fraction (Karp–Flatt metric) used in Case Study 1. Confident it exists; exact volume/issue/pages should be verified by the reader. (The formula itself is a direct algebraic inversion of Amdahl's Law and is self-evidently correct regardless of citation.)
• All worked code arrays and hand-computed outputs (385.00; the 1e20 reassociation; sum(1..10)=55; checksum 200.00 / 600.00; e-to-16-digits agreement) — constructed for clarity, computed by hand, never run.
• ANSI X3.9-1978 (the FORTRAN 77 standard) — the original definition of the dialect being read; harder to obtain than the modern standard, cited historically. Designation stated from memory; the reader should confirm before citing formally.
• Array-of-Structures vs Structure-of-Arrays: treated in vendor optimization guides (Intel, NVIDIA) and many HPC course notes. Used here for the memory-layout intuition previewed for Part VII; the "cache line is typically 64 bytes" figure is standard but hardware-dependent.
• Brian Kernighan & Rob Pike, The Practice of Programming, Addison-Wesley — not Fortran, but the clearest short argument for parsing by content over fragile fixed-column parsing (the Case Study 1 lesson).
• C. A. R. Hoare, "Null References: The Billion Dollar Mistake" (talk, QCon London 2009) — source of the chapter epigraph; a reflection on the cost of unchecked references. Wording quoted from widely reproduced transcripts; confirm exact phrasing against a primary recording.
• C99 restrict rationale — the C standards committee's rationale genuinely frames restrict as recovering Fortran-style aliasing optimization. Substance confident; not quoting a specific document line.
• Cache line "commonly 64 bytes" — typical of current x86-64; some architectures use 128-byte lines. Framed as typical.
• CamFort — academic Fortran analysis/refactoring tool (associated with Cambridge/Kent; Orchard, Rice, et al.). Real project; specific features/status not verified here.
• Case-study epigraphs: Feynman ("you must not fool yourself…", Caltech commencement, 1974) — genuine; Kohn on reproducibility — attributed loosely and labeled "treat the wording as illustrative."
• cffi documentation — the third-party C Foreign Function Interface (originally from the PyPy project); real and widely used, but confirm the current API/version.
• Chapman, Jost & van der Pas, "Using OpenMP: Portable Shared Memory Parallel Programming," MIT Press — thorough, example-led OpenMP treatment by authors close to the standard. Confident it exists; verify the edition. A sequel, "Using OpenMP — The Next Step," covers tasks and SIMD.
• Chapter epigraph, "Data is a precious thing and will last longer than the systems themselves," attributed to Tim Berners-Lee — a widely circulated attribution; not verified against a primary source. Flag before quoting in print.
• Compression ratios (smooth scientific fields ~3–4x under deflate; shuffle improves the ratio further), the deflate level-vs-speed table (levels 4–6 as the sweet spot, 9 for little extra ratio at high CPU), and text-vs-binary reload/conversion timings — all illustrative orders of magnitude, not benchmarks. Actual figures depend on the data, the machine, and the I/O subsystem; measure on your own data before committing an archive.
• Core-count orders of magnitude ("dozens of cores per socket," "a hundred or more per node," "thousands of nodes") — illustrative current-hardware ranges, not a specific machine's spec.
• CPython interpreter-overhead explainers (talks/posts by core developers) on why pure-Python loops are slow (bytecode dispatch, boxing, dynamic typing) — real background for §15.5, but no specific talk is pinned here.
• Crameri, Shephard & Heron, "The misuse of colour in science communication," Nature Communications (2020) — the widely cited case that rainbow/jet colormaps distort data and disadvantage colorblind readers; motivates §26.5's perceptually-uniform default. Author list, journal, and year are confident; the exact article/DOI number to be confirmed by the reader.
• David Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules" (1972) — the source of the chapter epigraph and the information-hiding argument behind public/private. A genuine, widely reprinted classic; EXACT epigraph wording ("The connections between modules are the assumptions which the modules make about each other.") is quoted from memory and should be verified against the original before print, as should the reprint venue.
• Double-precision atomicadd in CUDA Fortran requires compute capability ≥ 6.0 (Pascal, 2016). Confident; verify against current CUDA docs for the exact floor.
• Douglas McIlroy, on the Unix philosophy — the epigraph, "Write programs to handle text streams, because that is a universal interface." Genuinely his and very widely reproduced (the three-clause Unix-philosophy summary); exact original venue/wording to be confirmed by the reader.
• Epigraph — Edsger W. Dijkstra, "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." Widely attributed to Dijkstra's 1972 ACM Turing Award lecture "The Humble Programmer" (CACM 15(10)); a genuine Dijkstra quote, but the exact venue/wording should be verified before print.
• Epigraph: Alan J. Perlis, "Optimization hinders evolution," Epigrams on Programming, SIGPLAN Notices, 1982 (epigram #58). Believed genuine; flagged for verification.
• evtk (Python) — a small library that writes VTK files from NumPy arrays; named as an alternative in §26.2. Existence confident; API details not specified.
• Exact nvfortran/ifx flag spellings in the Case Study 30.2 profile table (-check all, -Mbounds, -Kieee, -fast) — orientation from vendor docs / PGI lineage; explicitly flagged to verify per version.
• f2py authorship/history — f2py was written by Pearu Peterson and folded into NumPy around the turn of the millennium; the broad provenance is well documented, but exact dates/venues should be verified by the reader before being asserted.
• findent and fprettify — open-source Fortran source formatters that automate the fixed-form → free-form conversion of §19.4 (reflow continuations, indentation). Real, widely used tools; exact feature sets vary by version.
• Fixed-to-free-form / re-indentation tools (findent, fprettify, and similar) — mechanical reformatters useful for cosmetic modernization steps only; confirm the current tool and its limits before use.
• fortls package name and the "Modern Fortran" editor-extension pairing — real, but install steps and package names drift; verify against current tooling docs.
• Fortran language server (fortls) — editor LSP integration for symbol navigation; a real, actively developed tool (exact package name/repo to confirm currently).
• Fortran Wiki (fortranwiki.org) — community-edited articles on COMMON, EQUIVALENCE, statement functions, and transfer; cross-check surprising claims against the standard.
• Fortran Wiki, fortranwiki.org — short articles on pure, elemental, optional/keyword arguments, assumed-shape; community-edited, cross-check surprising claims.
• FortranCon and national-laboratory HPC presentations — video archives; specific talks not pinned down here.
• Gauss–Seidel converging in "roughly half" the sweeps of Jacobi (Exercise 18.24) — a standard order-of-magnitude fact for this model problem (spectral radii related by a factor ~2 for the smoothing rate); treated as illustrative, not a precise guarantee.
• gfortran optimization-report message wording ("optimized: loop vectorized using N byte vectors"; "missed: not vectorized: possible dependence between data-refs") — REPRESENTATIVE, not verbatim from a run; exact text varies by GCC version. Explicitly flagged in §27.5 as version-dependent.
• gfortran's exact behavior on a statement function under -std=f2018 (warning vs hard error) is version-dependent and was not executed; the chapter says "cannot rely on it compiling," which is safe either way. Flagged.
• gfortran's historical incompleteness of finalization (gaps for function results and some assignment cases across versions) — reported in gfortran bug tracking and Discourse; verify against the specific compiler version in use before relying on finalization in an exotic case.
• gfortran's specific mangling (foo → foo_; module m's foo → __m_MOD_foo) — documented and stable in practice, but compiler-specific; readers should confirm against their own nm output.
• gfortran/OpenCoarrays TEAMS support being "incomplete or absent" at time of writing — true as broadly reported for gfortran versions current to the book's baseline (gfortran 10–13 era); support evolves, so the text says "verify on your version" rather than pinning a release. Collectives (co_sum etc.) support in gfortran+OpenCoarrays is solid and stated as such.
• GPU vs bus bandwidth figures: GPU on-board memory bandwidth ~hundreds of GB/s to >1 TB/s; host–device bus (PCIe) ~tens of GB/s; ratio ~10–30×. Illustrative current-hardware orders of magnitude, not a specific device's spec.
• Greg Wilson et al., "Good Enough Practices in Scientific Computing," PLOS Computational Biology, 2017 — practical reproducibility guidance (§38.6); open access, confirm the citation.
• Hamming, Numerical Methods for Scientists and Engineers (the epigraph, "The purpose of computing is insight, not numbers.") — genuinely Hamming's, from the book's preface/motto and very widely reproduced; exact page not pinned.
• Historical dates: the Level-1 BLAS paper (Lawson, Hanson, Kincaid & Krogh) is widely cited as 1979 (ACM TOMS); LAPACK's first public release is widely reported as 1992, with LINPACK and EISPACK as its 1970s Fortran predecessors and Jack Dongarra and Jim Demmel among its principal authors. Attributed from common knowledge; the precise years/attributions are Tier-2 unless checked against the LAPACK Users' Guide.
• Homebrew documentation, brew.sh — on macOS, brew install gcc carries gfortran (no separate gfortran formula); the binary may be version-suffixed (e.g. gfortran-14). Version-dependent; verify.
• IEEE-754 bit visualizers (e.g. float.exposed and similar) — interactive sign/exponent/fraction toggling; confirm the current URL.
• Intel ifort deprecation in favor of ifx, and Intel's relaxed -fp-model fast default — reported from Intel's documentation; flagged as version-dependent in the text.
• Intel oneMKL (Math Kernel Library) documentation and the MKL Link Line Advisor — the fastest BLAS/LAPACK on Intel hardware and the tool that generates its (nontrivial) link flags. Vendor documentation; specifics to be confirmed against the current release.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — clauses on intrinsic types and expressions define type ranking in mixed-mode arithmetic, integer division (truncation toward zero), and mod vs modulo semantics. Obtain via a library or ISO; committee drafts of later revisions circulate publicly via J3.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard) — clauses on the character type, intrinsic procedures, and data transfer (internal files). The last word on edge cases (empty substrings, all-blank strings); formal access varies, drafts circulate freely.
• ISO/IEC 1539-1:2018 (the Fortran 2018 standard), Clause 12 (input/output) and Clause 13 (I/O editing) — the authoritative semantics; exact clause numbers vary by edition and should be verified.
• Jean-Michel Muller et al., Handbook of Floating-Point Arithmetic, Birkhäuser — comprehensive reference on the standard and its algorithms (compensated summation, correctly-rounded functions); exact edition to confirm.
• John Backus, "The History of FORTRAN I, II, and III" — a first-hand account by Fortran's creator (reprinted in several history-of-computing collections); exact edition/venue to be confirmed by the reader.
• Kent Beck — the aphorism used as the Case Study 1 epigraph ("First make the change easy … then make the easy change") is widely attributed to Beck (originally a 2012 tweet); attribution is real but the exact venue is not pinned here.
• Kind numbers reported as 8 for selected_real_kind(15, 307)/real64 and 4 for default real — true on gfortran (kind = byte count) and on most mainstream compilers, but the exact numbers are compiler-defined and are stated as such in the text.
• LFortran maturity characterization ("still maturing; not a drop-in replacement for gfortran on production code today") — accurate as a general statement but a moving target.
• LINPACK/EISPACK (1970s), the three BLAS levels (Level 1 ~1979, Level 2 ~1988, Level 3 ~1990), and LAPACK's first release (early 1990s) — historical facts stated softly in prose; the precise years are Tier 2 and should be verified before being asserted as hard dates.
• Linux distro package names — gfortran (Debian/Ubuntu), gcc-gfortran (Fedora/RHEL), gcc-fortran (Arch). Correct at time of writing; verify per distro/version.
• Meson build system, mesonbuild.com — modern build system with Fortran support; current extent of Fortran support to be confirmed at the source.
• Microsoft WSL documentation — installing the Windows Subsystem for Linux; steps drift with Windows versions.
• Moreland, "Diverging Color Maps for Scientific Visualization" — the origin of ParaView's default cool-to-warm diverging colormap; venue (a Visual Computing / ISVC paper) not pinned here.
• MSYS2 documentation, msys2.org — Windows toolchain setup. The package mingw-w64-ucrt-x86_64-gcc-fortran (UCRT64 environment) is believed current as of writing, but MSYS2 package names drift — verify. (Flagged in continuity.)
• NetCDF history: Unidata developed NetCDF c. 1988–1990; netCDF-4 (data stored inside an HDF5 file) arrived c. 2008. Widely reported dates, not primary-checked.
• NVIDIA Developer blog posts on CUDA Fortran and OpenACC (many by Ruetsch/Fatica) — practical technique articles; verify against current tooling.
• NVIDIA released CUDA in 2007 (birth of general-purpose GPU computing / GPGPU) — widely reported date.
• OpenACC motto/epigraph "More science, less programming" — widely used as the OpenACC tagline; attributed in the epigraph to "the OpenACC initiative." Exact wording/provenance should be verified.
• OpenMP history: the first OpenMP specification (1.0) was published in 1997 and was the Fortran binding; the C/C++ binding followed in 1998. Widely documented; the exact month (commonly cited as October 1997) should be confirmed.
• Parallel HDF5 and parallel NetCDF user guides (The HDF Group; Unidata) — the practical route to MPI-IO used in §34.5 and the case studies; confirm the current guide/version. The claim that most codes reach MPI-IO through these libraries is Tier 2 (widely true, not a single citation).
• Parallel-region fork/join overhead "on the order of a microsecond" — an illustrative order of magnitude, not a measured figure; real values vary by runtime, thread count, and hardware.
• plusFORT (Polyhedron Solutions) — commercial Fortran toolkit including restructuring (SPAG). Real product; specific capabilities/version not verified here.
• PyVista and meshio (Python packages, fortran-lang-adjacent ecosystem) — real, widely used libraries for reading/writing VTK and other mesh formats from Python; named in §26.2's Python Comparison. Capabilities described at an orders-of-magnitude level, not a specific version.
• Representative gfortran --version banner and error-message wording/layout (caret + line number) — illustrative of recent gfortran; exact text varies by version and platform. Not asserted as version-exact in the text.
• Robert W. Numrich and John K. Reid, "Co-Array Fortran for Parallel Programming," ACM Fortran Forum, 1998 — the original design paper introducing coarrays as a Cray extension. Confident the paper exists (real authors, title, approximate year and venue); exact volume/issue/pages should be verified by the reader. The chapter's epigraph is quoted from it ("a small extension to Fortran… for parallel processing"): the wording is a faithful rendering of the paper's characterization but the EXACT verbatim string and punctuation should be verified against the original — flagged Tier 2. The historical facts (Numrich & Reid as designers; Cray T3D/T3E origin; 1990s; adoption into Fortran 2008) are well established.
• Rolf Rabenseifner's hybrid MPI+OpenMP tutorial materials — widely used course notes on the hybrid model named in §34.5; verify the current source/URL.
• Russ Rew & Glenn Davis, "NetCDF: An Interface for Scientific Data Access," IEEE Computer Graphics and Applications (1990) — the original design description of NetCDF; cited from common knowledge, exact volume/issue/pages to be confirmed against the primary source.
• Seymour Cray, "Anyone can build a fast CPU. The trick is to build a fast system." (chapter epigraph) — very widely attributed to Cray and on-point for a chapter arguing that system factors (memory, the compiler), not raw arithmetic, set performance. Attribution confident at the "widely attributed" level; exact original venue not pinned. Tagged Tier 2.
• Sparse-solver documentation: SuiteSparse (UMFPACK/KLU, sparse.tamu.edu), SuperLU, MUMPS, Intel MKL PARDISO, and PETSc (Argonne) — the standard direct and iterative sparse solvers referenced in Section 21.6. Real projects; exact API details left to the reader's current version.
• Specific version/tag strings (e.g. a stdlib tag = "v0.7.0") — used illustratively; the exact current tag/branch must be confirmed from stdlib's own README (releases evolve).
• Standard-status specifics flagged for verification against the exact ISO/IEC 1539-1 clause: statement functions "removed in Fortran 2018"; COMMON / EQUIVALENCE / BLOCK DATA "obsolescent in Fortran 2018"; arithmetic IF and computed GOTO "obsolescent"; assigned GOTO/ASSIGN, PAUSE, and Hollerith "deleted (Fortran 95)". These are stated in the chapter as guidance with an explicit "verify the clause" caveat; the teaching (translate them) is status-independent.
• Struct sizes on "LP64" (24, 32, 40 bytes for the example structs) — these follow the System V AMD64 / AArch64 ABIs used on mainstream Linux and macOS. The Fortran standard guarantees a bind(c) type matches the companion C compiler's layout (so c_sizeof == C sizeof), but the specific byte counts are platform-typical, not universal.
• Sunita Chandrasekaran & Guido Juckeland (eds.), "OpenACC for Programmers: Concepts and Strategies," Addison-Wesley — focused OpenACC treatment. Confident it exists; verify exact citation/edition.
• The "-fcheck=all build can run several times slower than -O2" claim — a Tier 2 illustrative order of magnitude, not a benchmarked figure; the actual factor depends on the code.
• The "50–100x faster than pure Python for element-wise loops" figure — a commonly reported order of magnitude, not a benchmarked promise.
• The "a dynamically dispatched call costs on the order of tens of cycles and blocks inlining/vectorization" figure — a widely reported order of magnitude, not a benchmarked promise; the direction (dispatch in a hot loop is costly) is certain, the exact cycle count is platform-dependent.
• The "few gigahertz" mainstream clock ceiling, and the ~90 nm / 65 nm process generations at which leakage became significant — approximate, widely reported; verify exact figures against a hardware history if precision is needed.
• The "kappa ~ 10^k costs about k of ~16 double-precision digits" rule of thumb — a standard conditioning heuristic, stated as an order-of-magnitude guide (see Trefethen & Bau, Golub & Van Loan).
• The "one-based threadIdx/blockIdx in CUDA Fortran vs zero-based in CUDA C" fact — from the CUDA Fortran Programming Guide; stated as a correctness point and worth a reader's confirmation against the guide, since it is the most error-prone detail in §35.3.
• The "pure-Python element loops run ~10–100× slower than compiled Fortran" figure — a commonly reported order of magnitude, NOT a benchmarked promise; framed throughout as illustrative and reader-measured.
• The "tuned BLAS beats a hand-written matrix multiply by roughly 10x (and up)" figure — an illustrative order of magnitude; the true factor depends on matrix size, cache, and compiler, and is measured properly in Chapter 29.
• The "two strong oxen or 1024 chickens" epigraph — widely attributed to Seymour Cray, but the attribution is part of HPC folklore and hard to source to a primary document; framed in the text as "attributed to."
• The "~10x from loop order alone" figure for cache-friendly vs cache-hostile 2D sweeps — an illustrative order of magnitude; the true factor depends on array size, cache, and compiler. Measured properly in Chapter 27.
• The "~4× memory for a linked list vs a plain array" and "order-of-magnitude faster contiguous sweep" figures — illustrative orders of magnitude (Tier 2), depend on element size, padding, allocator, cache, and compiler; not benchmarked promises.
• The co_sum↔MPI_Allreduce / co_sum(result_image=)↔MPI_Reduce / co_broadcast↔MPI_Bcast correspondences — standard and correct mappings; presented as analogies for teaching.
• The Case Study 2 epigraph ("Legacy code is code we have gotten value from that we are afraid to change.") — a community definition of legacy code, variously attributed; left unattributed rather than misattribute.
• The chapter epigraph — the OpenMP ARB's one-line description of the API ("supports multi-platform shared-memory parallel programming in C/C++ and Fortran"), quoted near-verbatim from openmp.org; confirm exact current wording before print.
• The claim that coarrays are "the only standardized in-language parallel model among mainstream languages" — accurate to the author's knowledge and widely stated in the Fortran community, but a comparative superlative; framed as such, not pinned to a survey.
• The claim that Jacobi needs ~O(N^2) sweeps on an N×N grid (Exercise 17.27) — a standard order-of-magnitude result for the unaccelerated method; framed as an order of magnitude, not a precise bound.
• The claim that NumPy/MATLAB/R "call down into LAPACK/BLAS" — true in general, but the specific BLAS backend depends on the build (OpenBLAS, MKL, Accelerate, …).
• The claim that submodules "avoid recompilation cascades" and that editing a submodule body does not force recompilation of the parent module's users — this is the standard, documented design rationale for submodules (F2008), but the precise rebuild behavior depends on the build system/compiler; framed as the intended benefit, not a measured figure.
• The date of the clock-speed plateau / breakdown of Dennard scaling — placed here at "around 2005"; the real transition is a soft boundary across roughly 2004–2006. Attributed as such, not pinned to a single year.
• The dating "most of the modern tooling built since ~2020" — broadly correct but an approximate attribution, not a precise release history.
• The eager-vs-rendezvous protocol transition and a "typical ~16 KB eager threshold" (§34.2 pitfall, Case Study 1) — implementation-specific; the existence of the transition is standard behaviour of standard-mode mpi_send, but the specific threshold value is illustrative and varies by MPI implementation and interconnect. Framed as "a typical threshold," not a fixed figure.
• The exact clause NUMBER of the F2018 dummy-argument aliasing restriction (historically ~15.5.2.13; older numbering ~12.5.2.13) — NOT stated in the chapter prose to avoid a wrong citation; the reader is pointed to the standard's "restrictions on entities associated with dummy arguments." Flagged: confirm number against a copy of the standard.
• The exact wording of gfortran runtime error messages (bounds errors, SIGFPE backtraces, Attempting to allocate already allocated variable) — representative and version-dependent; shown in the chapter as illustrative, not as executed output.
• The Fortran 2003 standard and its rationale documents — object orientation entered the language in 2003; the rationale explains the design choices (passed-object dummies, class, abstract interfaces). Locate the specific rationale document to confirm details.
• The Fortran Discourse (fortran-lang.discourse.group) — practitioner discussion of do concurrent vs do and why forall fell out of favor; specific threads not pinned here.
• The K&R epigraph, "C is not a big language, and it is not well served by a big book." — from the Preface to The C Programming Language (2nd ed.); confident of the wording, but verify the exact edition/page before print.
• The single-vs-double speedup claim (≈2× for a memory-bandwidth-bound loop; 2× SIMD lanes) — a widely reported order of magnitude for memory-bound numerical kernels, framed as illustrative, not a benchmarked promise (rigor deferred to Ch. 20/27).
• The VTK file-format documentation (Kitware) — how to write output that ParaView/VisIt can read; used in Chapter 26. Exact URL/version to be confirmed by the reader.
• Tuned-BLAS-vs-reference-BLAS speedups ("many times faster") — a commonly reported order of magnitude, hardware-dependent, not a benchmarked promise.
• Ulrich Drepper, "What Every Programmer Should Know About Memory" (2007) — the deep "why" behind column-major performance (cache lines, access patterns); exact venue/PDF to be located by the reader.
• William Kahan's lecture notes and essays (UC Berkeley) — first-hand material by the principal architect of IEEE 754; specific documents/URLs not pinned here. The "father of IEEE 754" / Turing Award attribution is well documented.
• William L. Oberkampf & Christopher J. Roy, Verification and Validation in Scientific Computing, Cambridge University Press — comprehensive modern V&V; confirm the edition.
• Williams, Waterman & Patterson, "Roofline: An Insightful Visual Performance Model" (Communications of the ACM, ~2009) — the roofline paper behind the arithmetic-intensity table in Case Study 2. Author list/topic confident; exact issue/DOI not pinned.
• WRF (Weather Research and Forecasting model), CESM (Community Earth System Model), and Quantum ESPRESSO — named as large, open-source, modular Fortran codes at the STRUCTURAL level only. Claims made: they are large (10^5–10^6+ lines), Fortran, modular, and organized into layered source trees (foundation/utilities, core, physics or dynamics, I/O, driver). NO specific internal module names, file counts, or line numbers are asserted — those evolve between versions and were deliberately left general per the honesty rule. Readers are directed to clone the repositories and verify structure firsthand.
• WRF, CESM, and other production codes described as "Fortran + MPI" — accurate in broad strokes (these are Fortran codes parallelised with MPI, per Ch. 1's Tier-2 framing); the specific decomposition details are not pinned to a primary source here.
• WRF, CESM, VASP, Quantum ESPRESSO — named production Fortran codes; their scale and provenance are as publicly documented, but specific line counts and version details should be verified.

Tier 3 — Illustrative / constructed (labeled in text)

• (none) — all in-chapter numbers are exact hand-computed program outputs or explicit order-of-magnitude estimates in the exercises (4.21 ≈ 100 s on one core; 4.23 ≈ 20 iterations), labeled as estimates in place.
• thermex (Case Study 1) — a fully constructed, composite stand-in for "a large open-source thermal-transport code," used to demonstrate navigation moves without asserting anything about a specific real code. Its alpha-as-module-variable bug mechanism is illustrative.
• All ! Expected output: values throughout the chapter — computed by hand, not executed (per the no-code-execution rule); readers verify by compiling.
• All Amdahl and Gustafson speedup, efficiency, and Karp–Flatt numbers are computed from the exact formulas; the inputs (p = 0.95, 0.98, 0.90, 0.75; s = 0.05, 0.10; core counts) are round numbers chosen for clear arithmetic. The outputs are exact math, not benchmarks — no hardware was timed.
• All coarray program outputs (example-01/02/03, project-checkpoint, exercise-solutions, both case studies) are hand-computed by tracing the code, NOT run. Key anchors: squares 1/4/9/16; co_sum(1..4)=10, co_max=4; sum of i^2, i=1..12 = 650 (image-count independent); the plate field after 2 steps (100 top row; interior 28/32/32/28 then 4/4/4/4; the 32 requires the halo); the 1D rod after 3 steps (0,0,1.5625,12.5,45.3125,100) with global residuals 25→12.5→7.8125. Every value is a dyadic fraction reproducible by pencil; worth a compile-check on a machine, but the arithmetic is certain.
• All expected outputs are hand-computed from exact arithmetic and NO code was executed: the reduction sum (5050), sum of squares (385), the 5×5 heat grids (matching Ch. 24), the max-change (12), the L2 residual (5), the dot product (500500), the row-normalize values.
• All hand-computed program outputs (examples 1–3, project checkpoint, exercise solutions, both case studies) — derived by hand, NOT executed, per the book's no-code-execution rule; verify by compiling.
• All hand-worked storage estimates, constructed for exact hand-verifiability and labelled as such: * example-01 / §25.1: 100x100 real64 => 80,000 binary bytes vs 240,000 text bytes (24 chars/value) => ratio 3.00. * Case Study 1 audit_cost: 2048^2 = 4,194,304 values; x8 bytes x2000 snaps = 67.1 GB binary; x25 chars = 209.7 GB text. * Case Study 2 archive_payoff: 1024^2 x8 = 8,388,608 bytes/snap; x1000 = 8.4 GB raw; /3 = 2.8 GB compressed. * exercise-solutions solve_storage / Ex 25.29: 1000^2 x8 = 8,000,000 bytes/snap; x1000 = 8.0 GB raw; /4 = 2.0 GB. * Ex 25.28: 2048^2 x8 = 33,554,432 bytes/snap; 500 snaps; 16.8 GB raw; /3 = 5.6 GB.
• All ncdump -h and h5dump -H headers shown in the chapter and case studies are constructed to match the exact code that would produce them (not captured from a run — no code is executed).
• All numerical outputs in this chapter (stats example 4.000/1.265; relax 0/50/90; Kelvin conversions; factorial 1..720; gcd 12/21; the 4×4 heat-step fields; the case-study values) are constructed teaching examples with round inputs, hand-computed for clarity — not measurements of any real system.
• All process-scheduling and interleaving statements ("line order not deterministic") — correct qualitative behaviour, not a measured outcome.
• All program outputs are hand-computed, never executed (book rule). Key values re-derived by hand: example-01 cells 4*4 = 16; example-02 iters = 2, center = 25.00 (a 3x3 single-interior-cell MINIMAL instance, clearly labeled, not PLATE's answer); example-03 avg4 = 20.00, row = [0,12,0,8,0]; plate-legacy / project-checkpoint "converged in 25 iterations" with interior 37.5/12.5; CS-02 hot_cell = 37.50; CS-01 trapezoid(x^2,0,3,3) = 9.50 (endpoints 4.5 + interior 1 + 4 = 9.5, x h=1); exercise-solutions 1681 / 0 / 37.50 (T(2,2)=a) / 0.00 (cold corner).
• All small hand-worked arrays (the 10i+j matrix, the pi-digit vector [3,1,4,1,5,9,2,6], the u=i*3 Laplacian field, the Game-of-Life blinker): constructed for hand-verifiability, labeled as such.
• All small hand-worked linear systems, constructed for exact hand-verifiability and labeled as such: * example-02 / §21.3: A=[[1,1,1],[0,2,5],[2,5,-1]], b=[6,-4,27] -> x=(5,3,-2); every LU step is an exact binary fraction, so the residual is exactly 0. * example-03 / §21.4: symmetric tridiagonal [[2,1,0],[1,2,1],[0,1,2]], eigenvalues 2±sqrt(2), 2 (closed form 2 + sqrt(2)cos(kpi/4)); shown to 4 decimals. * project-checkpoint: A=[[3,-1],[-1,3]], rhs=[1,0] -> (3/8, 1/8) = (0.3750, 0.1250). * quiz Q18: [[1,1],[0,2]] x=(3,4) -> (1,2). * Case Study 1: [[2,1],[1,3]] (works), [[0,1],[1,1]] (zero pivot -> NaN), [[1e-20,1],[1,1]] (tiny pivot -> silently wrong) — the classic pivoting failure trio (cf. Trefethen & Bau, Golub & Van Loan). * Case Study 2 / Ex 21.28: least-squares fits with normal equations A^T A = [[4,6],[6,14]] etc.; quadratic recovery of y = 2 + 3x + x^2 from exact samples. * exercise-solutions: 21.9 (1,2); 21.16 (8/21,1/7,1/21); 21.26 (1,-1,2); 21.28 (0.8, 2.3).
• All specific timing numbers in the chapter and case studies — benchmark.py (~1.5 s / ~0.01 s / ~100×), Case Study 1 (~3.0 s / ~0.005 s), and the Case Study 2 relative-time table — are ILLUSTRATIVE round numbers, explicitly labeled as such and never presented as measurements the book made (no code was executed).
• ALL timing / speedup / scaling numbers in §38.4 and the case studies are ILLUSTRATIVE (Tier 2 per the style bible): the parallel fraction f = 0.98, the "~10 flops/cell / tens of bytes / ~0.3 flop/byte" intensity, the "20x", the "100 GB/s, 1000 GFLOP/s, balance ~10 flop/byte" node figures, and the memory-bandwidth-plateau claim. Framed throughout as "run it yourself"; no code was executed. The Amdahl speedups and efficiencies (50x ceiling; S(2)=1.96, S(4)=3.77, S(8)=7.02, S(16)=12.31 at f=0.98; and S(2)=1.90, S(4)=3.48, S(8)=5.93, ceiling 20 at f=0.95) are EXACT arithmetic from the Amdahl formula, hand-verified.
• All timing/speedup numbers are computed from round illustrative inputs, NOT benchmarks, and no hardware was timed: the SAXPY (n=8), example-03 doublings, the Case Study 1 audit (2000×2000 = 32 MB field, 16 GB/s bus, 5000 steps, 0.4 ms GPU sweep / 4.0 ms CPU sweep → broken 22 s vs CPU 20 s vs fixed 2 s, ~10×), the exercise transfer/intensity/crossover/Amdahl-with-transfer figures (0.5 ms one-way, K≥2 crossover, 0.125/0.375 flops/byte, 14.45× vs 16.89× ideal). Outputs are exact arithmetic from the stated inputs.
• Analytical solution u = sin(pi x) sin(pi y) exp(-2 alpha pi^2 t): verified by substitution to satisfy the 2D heat equation, zero-Dirichlet edges, and the initial condition. EXACT.
• Arithmetic-intensity figures in the Case Study 2 table (triad ≈0.08, 5-pt stencil ≈0.4, matmul ≈ n/12 flop/byte) — computed from the flop and byte counts shown, illustrative and rounded; the counting method is given so the reader can reproduce it.
• Back-of-envelope memory/speedup figures (Exercises 15.14, 15.21, 15.22; Case Study 2 Phase 1 ~5 GB) — round illustrative numbers for order-of-magnitude arguments.
• Canonical 5x5 two-step demo (dx=dy=1, alpha=1, dt=0.2, r=0.2): after step 2 the interior is 28/32/28 and 4/4/4, max 100 — IDENTICAL to Chapter 24/33/36's published output; hand-verified.
• Case Study 1's "buggy_norm" run-to-run values (650, 573, 456) — CONSTRUCTED to illustrate a lost-update race; a real race has no defined output, so these are labeled as "a typical session," not a prediction, and the text is explicit that the value is undefined.
• Case Study 1's "works at 100×100, hangs at 2000×2000" scenario and Case Study 2's convergence run — constructed to illustrate the deadlock/ordering bugs and the allreduce/non-blocking redesign; the row lengths and the tolerance are illustrative, and NO timing is presented as measured.
• Case Study 2's overhead figures (5 µs sweep, 1 µs fork, ~17%) and the "large grid vs 5×5" work estimates are round Tier-3 numbers chosen for the reasoning.
• Constructed data fields, chosen so the round-trip sum is exact by hand: * temperature(i,j) = 10*i + j on a 4x3 grid => sum = 324 (examples 02/03, Ex 25.12). * temperature(i,j) = i + j on a 3x3 grid => sum = 36 (quiz Q19).
• Discrete stencil eigenvalue lambda_h = -(8/h^2) sin^2(pi h/2); amplification factor G = 1 - 8 r sin^2(pi h/2); the discrete mode is an EXACT eigenvector, so u^K = G^K u^0 exactly. Verified analytically and cross-checked numerically (Python) during authoring.
• Eigenvalue convergence (continuous -2 pi^2 = -19.739209): h=1/2 -> -16.000000 (err 3.739209); 1/4 -> -18.745166 (0.994043); 1/8 -> -19.486840 (0.252369); 1/16 -> -19.675873 (0.063336). Ratios 3.76/3.94/3.99 -> order 2. EXACT.
• example-01 one-step center (h=1/4): numerical G = 0.765685, exact = 0.781344, |error| = 0.015658. EXACT.
• exercise 38.25 eigenvector check at (2,3): direct FTCS = 0.541421 = G * 0.7071068. EXACT.
• Exercise 38.7's error triple (1.60e-2, 4.05e-3, 1.01e-3) is a constructed illustrative convergence sequence chosen to give observed orders 1.98 and 2.00.
• Full-solution max error at T=0.05, alpha=1, r=0.2 (|G^K - exp(-2pi^2 T)|, exact = 0.372708): h=1/2 -> 0.172708 (K=1); 1/4 -> 0.028990 (K=4); 1/8 -> 0.006762 (K=16); 1/16 -> 0.001663 (K=64). Ratios 5.96/4.29/4.07 -> order 2. EXACT (closed form).
• gfortran error-message wording shown in §8.2/§8.5 ("Missing actual argument…", "Fatal Error: Cannot open module file 'kinds.mod'…", "Symbol '…' … not found in module …") — reproduced from memory as representative gfortran diagnostics; exact wording/format may vary by version.
• Illustrative numbers chosen for clarity, not from any specific code: the 56-byte particle and the 56 MB / 134 MB memory estimates (Exercises 9.24–9.25); the 3-body swarm and its center-of-mass/momentum (Case Study 1); the sample [2,4,4,4,5,5,7,9] with mean 5, variance 4 (Exercise 9.15 / Case Study 2 extension); the ~7/8-wasted-bandwidth and "~8×" AoS-vs-SoA ratio (Exercise 9.26) — an order-of-magnitude argument from the cache-line stride, not a benchmark.
• Round-number back-of-envelope figures in Exercises 21.19–21.21 (the (2/3)n^3 LU flop count, 2n^3 matmul, 8n^2-byte memory, 1e10 flop/s core rate): standard textbook order-of-magnitude values used illustratively, consistent with the Chapter 5 estimates.
• The "100,000 lines, read ~0.05%" figures (§36.4, Case Study 1, Exercise 36.23) — round illustrative numbers chosen to make the "navigate, don't read" point; not a measurement of any specific code.
• The "20x faster" heat-solver MANUSCRIPT in Case Study 1 is a fully CONSTRUCTED composite teaching example (no real paper, no authors, no journal), explicitly framed as such — a composite of common first-draft mistakes (missing convergence study, undisclosed baseline, discarded NaN runs from a CFL violation). Not a real result.
• The "5-hour run, 80% hot, 10× on the hot part" Amdahl estimate in Exercise 27.23 — round illustrative numbers for order-of-magnitude reasoning, explicitly framed as such.
• The "80 GB copied over the run" figure in Exercise 6.23 is an illustrative order-of-magnitude arithmetic result from the round inputs (1000×1000 grid, 10⁴ steps), not a benchmark.
• The "one significant digit lost per 10^6 operations" error model (Exercise 3.22) — a deliberately crude, pessimistic illustration for an order-of-magnitude argument about single vs. double precision, not a claim about real error growth (which is usually sub-linear).
• The "wrong, run-to-run-varying" numbers shown for the shared-accumulator race (e.g. 4128, 4873, 498211) are explicitly illustrative of the kind of garbage a race produces; the actual values are unrepeatable by nature.
• The "~24 bytes per double as full-precision text vs 8 bytes as binary," "~100 ns per value to convert to text vs ~1 ns to copy as binary," and the derived size/time ratios in §7.5, Case Study 1, and Exercises 7.20-7.21 — round illustrative figures chosen for an order-of-magnitude argument, explicitly labeled as such, not benchmarked measurements. The exact numbers depend on the format, compiler, and hardware.
• The 1-D RODEQ kernel (Case Study 1) and its 0/25/50/75/100 profile — a constructed illustrative legacy example; the "40 sweeps at tol 1e-6" count is illustrative (convergence ratio ≈ 0.707) and not asserted precisely in the prose.
• The 1000 x 1000 x 100 real(dp) field memory estimate (Exercise 5.22): round illustrative numbers for an order-of-magnitude footprint argument, not any specific code's configuration.
• The 1000 × 1000 × 100 grid weather-model floating-point estimate (Case Study 1 and Exercise 1.18) — round illustrative numbers chosen for an order-of-magnitude argument, not any specific operational model's real configuration.
• The 10^6-step / 10^9-operation error budgets (Section 20.2, Project Checkpoint, Exercises 20.22–20.23, 20.28) — round illustrative step counts for order-of-magnitude round-off arguments, not any specific run's configuration.
• The 200-files-×-3-seconds rebuild estimate (Exercise 8.24) and the 6-year-old COMMON bug narrative (Case Study 1) — round illustrative numbers and a representative (not real, not attributed) scenario chosen to make an order-of-magnitude/qualitative point.
• The 2×2 linear system A = [[2,1],[1,3]], b = [3,5], x = [0.8,1.4] (Case Study 1) — constructed for a hand-verifiable multiply-back check.
• The 37.5/12.5 interior is a genuine theorem for the 4x4 one-hot-edge plate (steady state gives 3a-b=100 and a=3b, hence b=12.5, a=37.5), established and hand-proved in Chapter 18 and reproduced here; not an empirical timing. Aligned to Ch. 18's canonical PLATE (see continuity/ch19.md).
• The 3×2 demo field (values 0–5) and the 4×4 hot-top-edge plate used in the examples, Project Checkpoint, and case studies — constructed illustrative data chosen so every VTK/CSV/gnuplot output line can be hand-verified against the format skeleton; not from any real run.
• The 3×3 heat-plate numbers (top edge 100, r = 0.1, interior 0 → 10 → 16 → 19.6 → 21.76 → 23.056; relaxation → 25) — constructed illustrative example with hand-computed arithmetic, chosen so a single interior point makes the steps transparent; not a real simulation configuration.
• The 3×3 hot-center heat-step numbers (100 → 60 → 36) and the 4000×4000 transpose traffic figures (128/256 MB per pass, 2560 GB over 10,000 steps) — round illustrative numbers chosen for hand-computation, not any real run.
• The 3×3 plate / hot-top-edge / u(2,2) = 25.0 example (Project Checkpoint, Case Study 2, project-checkpoint.f90) — a constructed, hand-computed illustration; the real finite-difference numerics are Chapter 24.
• The 4×4 PLATE test grid (top 100°, three edges 0°) and its steady state 37.5°/12.5°, the 25-iteration convergence count, the dyadic-exactness claim — a constructed illustrative example; the numbers are hand-derived and cross-checked (see continuity note), chosen so the arithmetic is exact.
• The 5x5 two-step heat-solver result (Project Checkpoint) and one-step u(2,2)=20 (Case Study 2) — exact and hand-computed, matching the canonical Chapter 24 output.
• The 5×5 / 4×4 hot-top-edge plates, the 1000×1000 timing grid, the a(i,j)=10i+j fill, the 2**20-element triad, and the 2×2×2 pattern in the solutions — constructed illustrative data chosen so every CORRECTNESS value (interior=20 or 25, sum=5,505,500,000 / 1332, maxval=100, checksum=14) is exactly hand-computable against the arithmetic. Not from any run.
• The .pvd timesteps (0.0000, 0.0500, 0.1000 from dt = 0.0005, save_every = 100) and the save_every/frame-count figures in the back-of-the-envelope exercises — illustrative round numbers, not measurements.
• The DO 5 I = 1.100 -> DO5I = 1.100 fixed-form example (§2.6 history callout) — a real, well-known illustration of fixed-form + implicit typing. The popular story that a typo of this kind crashed an early NASA space probe is APOCRYPHAL and is explicitly flagged as such in the text (the actual Mariner 1 failure traced to a transcription error of a superscript/overbar in a guidance equation, not a Fortran DO-loop typo).
• The dsp.c, particle_t, params_t, and heat_bridge programs — constructed for teaching; representative, not from a specific library.
• The FILTER 3-point smoother (Case Study 1) — a constructed undocumented routine; its spike-input result [0, 10, 10, 10, 0, 0] is hand-traced.
• The heat_NNNNNN.vtk six-digit naming convention and the 999,999-step ceiling — an illustrative choice for the project; the width is a design decision, not a standard requirement.
• The PLATE kernel (plate-legacy.f) — the constructed FORTRAN 77 teaching program shared across Chapters 17–19; the 4×4 hot-edge steady state (upper interior 37.5, lower 12.5, 25 Jacobi sweeps at tol 1.0D-6) is hand-derived by symmetry and exact in double precision (all dyadic). Matches Chapter 18's canonical listing.
• The {1.0e8, 1.0e8 + 1} variance dataset (Case Study 2) — chosen so the one-pass formula's cancellation is exactly hand-computable (naive gives 0.0, true is 0.25); a representative failure, not from any real study.
• The {1e17, -1e17, 1.0, 1.0} reordering example (Case Study 1) — constructed so absorption is unambiguous (1.0 < half a ULP at 1e17), giving 2.0 vs 0.0 by order.
• The {2,4,4,4,5,5,7,9} dataset (Case Study 2) — the classic textbook set with mean 5 and population variance 4; small integers, all exact in double.
• The back-of-envelope rebuild-time figures (3 s and 40 s per build, 150 builds/day, Exercise 2.27) — round illustrative numbers for the edit-compile-run argument, not measured.
• The chunk-shape guidance table (Case Study 2 Phase 3) and deflate-level table (Phase 4) are illustrative design heuristics, not measured results.
• The collectives example values (bcast 100.0; allreduce sum of rank+1 = 10 and max = 4 at -np 4; = 36 and 8 at -np 8; general N(N+1)/2 and N) and the point-to-point example (sum of [10,20,30] = 60) — exact arithmetic from the code.
• The communication/computation ratios (1D rod ~2P/M; 2D plate ~2P/N; 3D ~2P/N) — order-of-magnitude surface-to-volume scaling arguments, exact in leading order, presented as scaling reasoning not benchmarks.
• The constructed examples: the 3→2→1 linked list, the buffer capacity sequence (1,2,4,4,8), the callback returning 9.0 / -3.0, and the 10^6 / 10^7-element memory estimates — round illustrative numbers chosen for clean hand-computation, not measurements of any real code.
• The constructed hand-computed examples: the 4×4 heat grid (top row 100, alpha*dt = 0.1 → interior 0,10,10,0), the 5-element and 7-element smoother inputs, the 5-cell 1-D rod, and the [3,4]→5 norm — constructed for hand-verifiability; each result was derived by hand, not run.
• The cos fixed point (Exercise/solution 17.22) — the Dottie number 0.7390851…, the unique real solution of cos(x)=x; a known mathematical constant, printed to 4 decimals (0.7391). Not computed by running code.
• The dispatch-cost back-of-envelope estimates in Exercises 10.22–10.24 (≈8 flop/cell, ~20-cycle dispatch, ~4× vectorization loss) — illustrative order-of-magnitude figures for a teaching estimate, explicitly labeled as such.
• The energy/L2 diagnostics (total 600, sum of squares 52640, L2 ≈ 229.43) are exact arithmetic on the constructed post-step-2 field.
• The exact wording of the Dijkstra epigraph ("The quality of programmers is a decreasing function of the density of go to statements in the programs they produce.") is quoted from memory of the 1968 CACM letter and should be checked against the primary source before print. The paper's existence and thesis are certain (Tier 1); only the verbatim string needs confirmation.
• The Fahrenheit/Celsius, projectile-free distance, and quadratic examples — constructed textbook numbers chosen so every printed value is exactly hand-verifiable.
• The heat-solver 5×5 output (after step 2) is reproduced exactly from Chapter 24's hand-traced result; the GPU offload is asserted to match it (a correct offload reproduces the serial result; at f8.2 display the values are identical).
• The heat-solver problem parameters (5×6 plate, top row 100, alpha=1, dx=dy=1, dt=0.2 so r=0.2; 1D rod r=0.25, ends 0/100) — round illustrative numbers chosen so every step is hand-verifiable and consistent with the Chapter 24 stencil; a real run uses a finer grid and a CFL-derived dt.
• The heat-solver profile in the Project Checkpoint and Case Study 2 (setup 2 s, 196 s of stencil sweeps, 2 s of VTK I/O; p = 0.98) — round illustrative numbers to drive the model; a real profile will differ.
• The heat-solver Project Checkpoint problem (5-wide × 6-tall plate, top edge 100, alpha = 1, dx = dy = 1, dt = 0.2 so r = 0.2, 2 processes × 2 rows, 3 steps) and ALL its temperatures (step 1: 20; step 2: 28/32/28 and 4/4/4; step 3: 32.8/38.4/32.8, 7.2/8.8/7.2, 0.8/0.8/0.8; global max changes 20.0, 12.0, 6.4) — exact arithmetic, hand-computed and cross-checked, not measured. Chosen to reproduce Chapter 24's numbers and to make the halo's effect visible at step 3. Deterministic across process counts by construction.
• The IEEE-754 single-precision encoding of 1.0 shown as 1065353216 / 0x3F800000 in §19.1 (the transfer example) is a standard, exact bit pattern (sign 0, exponent 127, zero mantissa); presented illustratively, full treatment deferred to Ch. 20.
• The illustrative flop-rate figures (40 Gflop/s tuned, 2 Gflop/s reference) in §16.1 and Exercise 16.20 — round numbers chosen for an order-of-magnitude argument, not any specific machine's measurement.
• The illustrative overflow/performance estimates in the exercises (e.g. the ~1290 cubic-side overflow threshold, the 6×10^12 bounds-comparison count) — round numbers chosen for an order-of-magnitude argument. The 1290/1291 threshold and the 1500³ = 3,375,000,000 → wrapped −919,967,296 values are exact and hand-checked.
• The instrument-log lines (S12 23.5 OK, S3 100.25 FAIL) in Case Study 1 and the heat-solver config block in Case Study 2 — constructed illustrative data chosen to expose the fixed-column failure mode and to exercise the parser; not from any real instrument or code.
• The per-value byte estimate (~9 ASCII bytes) and disk-bandwidth figure (500 MB/s) in exercises 20–23 — round illustrative values for order-of-magnitude reasoning, explicitly framed as such.
• The plate edge-average estimate (25 C from a 100/0/0/0 plate, §2.7) — an illustrative first approximation chosen for hand-computability; it is NOT the true PDE steady-state field (that is the destination of Ch. 24), and the text says so.
• The plate's physical constants — alpha = 1.0e-4_dp m^2/s, length = 1.0_dp m, nx = 101, giving dx = 0.01 m, tau = 1.0e4 s, dt_max = 0.25 s — are illustrative round numbers chosen for clean hand-computation, not any specific material or apparatus.
• The regress.f90 sample comparison (max abs 0.001, max rel 1e-5, verdict PASS at atol 1e-2) — constructed, hand-computed.
• The regression-harness values (Case Study 2) — round illustrative numbers (tolerance 1e-3, a 5-degree injected regression) chosen for clarity.
• The shape areas (circle r=2 → 4π; rectangle 3×4 → 12; triangle base 4 height 5 → 10) and the conductivity models (constant k0=2; linear k0=2, β=0.01, T=100 → 4) — round illustrative numbers chosen for transparent hand computation.
• The solver's "~98% parallel → 50× ceiling → ~7× on 8 threads" Amdahl figures are inherited from Ch. 31's illustrative profile, not a measurement.
• The surface-to-volume estimates (comm/comp = 2P/N; 1% at P≈5, comparable at P≈500 for N=1000; 1D vs 2D halo 2000 vs 500 reals, a 4× factor at P=64) in §34.4 and exercises 34.21–34.23 — order-of-magnitude models with round inputs, not benchmarks.
• The two scaling studies in Case Study 1 (baseline T1 = 8000 s; Code A and Code B time tables) — constructed so that Code A has an exactly constant Karp–Flatt fraction (0.05) and Code B a monotonically rising one, to contrast a fixed serial fraction against growing overhead. Not measurements of any real code.
• The ~10–30× valgrind slowdown figure — a commonly cited order of magnitude, not a benchmark; the direction (valgrind is much slower) is reliable, the exact factor is not.
• The ~2 n^3 flop count for an n x n matmul (Exercise 5.23) and the 1e10 flop/s core rate: standard textbook order-of-magnitude figures used illustratively, consistent with the Chapter 1 estimates.
• THERMASIM (Case Study 2), REACTOR-scale line counts and module counts — constructed illustrative scenario for the migration-at-scale narrative; round numbers chosen for clarity.
• Toy datasets for mean/std ([2,4,4,4,6]; [1,2,3,4,5]; [2,4,6,8]) — chosen so the statistics come out to clean, hand-checkable values.