Chapter 40: The Fortran Career — Where Fortran Programmers Work and What They Build

"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." — attributed to Tony Hoare

Overview

Forty chapters ago, in Chapter 1, you were told that Fortran is not a dead language — that it predicts the weather, models the climate, simulates reactors, and runs the numerical heart of the world's fastest computers. Then you were asked to do something small and quietly consequential: to write down, in one sentence, your own answer to "why learn Fortran?" and seal it away, so that a later version of you could break the seal and see how far you had come. That was Exercise 1.28. You are now that later version. Before you finish this chapter, go find that sentence.

Between then and now you have installed a compiler and printed Hello, world; learned that arrays are first-class objects and that column-major order is worth a factor of ten; built derived types and modules and a small object-oriented framework; read and modernized crusty FORTRAN 77; called LAPACK to solve $A\mathbf{x} = \mathbf{b}$; discretized the heat equation and marched it forward in time; profiled it, optimized it, and made it run in parallel across cores and nodes; wrapped it for Python; tested it, documented it, and presented it as a paper in the capstone (Chapter 38). You did not just read about Fortran. You built something real in it, one increment at a time, and you understand every line.

This closing chapter answers the last question the book owes you: so what? Where does this competence lead? Who pays for it, what do they build, and how do you present what you now know so that the world recognizes it? The honest answer is more encouraging than most people, including many working programmers, would guess — because the sectors that depend on Fortran are enormous and consequential, and the number of people who can actually do what you can now do is, by many accounts, smaller than the number of jobs that need them. This chapter is your map to that landscape, and then it is a send-off.

In this chapter, you will learn to:

• Point to the specific institutions — the national laboratories, the weather and climate services, the aerospace and energy companies, the university research groups — where Fortran is a working tool and not a museum exhibit, and say what each of them actually builds.
• Tell apart the career roles that Fortran fluency opens — computational scientist, research software engineer, HPC engineer, domain scientist — and locate yourself on the spectrum from "scientist who codes" to "engineer who does science."
• Understand the shortage of Fortran programmers for what it honestly is — a widely reported, not precisely measured, imbalance between the jobs and the people — and why it hands you leverage.
• Put Fortran on your résumé the right way: as a high-performance-computing asset, paired with Python and C and the HPC toolchain, never as a lonely legacy keyword.
• Package your solver as a portfolio piece an employer or an open-source project can see, and take the first step toward contributing to a real scientific code.

Learning Paths

How to read this chapter by track. This is a beginner-level chapter with no code to master, so read whichever parts serve where you are headed. - 🔬 Scientist ("I want my science to run fast") — §40.1 and §40.2 name the places and the roles that let you do computational science for a living; §40.5 is your on-ramp to a first contribution. - 📖 Standard — read straight through; this is the coda, and it is short. - 🔧 Legacy ("I maintain old code") — §40.3 is written for you: the shortage is sharpest exactly where large validated codes need people who can read and modernize them, the skill of Part IV. - ⚡ HPC ("I want to work on the big machines") — §40.1's national-lab and weather-service sections and §40.4's "pair it with the HPC toolchain" are your path onto a cluster team.

40.1 Who Employs Fortran Programmers

Start with the fact that surprises people: the places that use Fortran are not obscure. They are among the most consequential computing institutions on the planet — the ones that forecast tomorrow's storm, certify a reactor, design an aircraft, and project the climate of the next century. What they have in common is the shape of their computing: enormous floating-point calculations over enormous arrays, repeated over enormous numbers of steps, where a factor of two in speed is the difference between a result this week and a result next month. That is the shape Fortran was built for, and it is why these institutions keep their flagship codes in it. Here is the landscape, sector by sector.

The national laboratories. In the United States, the Department of Energy runs a constellation of national laboratories — Oak Ridge, Lawrence Livermore, Los Alamos, Argonne, Sandia, and others — that between them operate several of the fastest supercomputers in existence and employ thousands of people to run science on them. Fusion plasmas, the aging of materials, the behavior of a nuclear stockpile without testing it, the formation of galaxies, the design of new batteries and catalysts from quantum mechanics first principles — these are their workloads, and a very large share of the code that does the arithmetic is Fortran, some of it decades old and validated against decades of measurement, much of it modern and actively developed. Other nations run their own: the picture repeats wherever a government funds large-scale science.

💡 Intuition: a national lab is, from a programmer's point of view, a place where the computation is the product. Nobody there is shipping an app; they are running the largest calculation they can afford, to answer a question no experiment can. That is precisely the environment in which Fortran's single virtue — speed on big numerical arrays — outweighs everything a general-purpose language offers, and it is why the labs are the densest concentration of Fortran work in the world.

Weather and climate services. Every night, the national weather services run enormous simulations of the atmosphere so that a forecast can exist in the morning. The European Centre for Medium-Range Weather Forecasts (ECMWF) runs one of the most respected forecast models in the world, and it is Fortran. The UK Met Office's Unified Model — used for both weather and climate — is Fortran. In the United States, NOAA's forecast and climate models, including the ocean and atmosphere components developed at its Geophysical Fluid Dynamics Laboratory, are Fortran. This is not a coincidence of history that anyone is racing to undo: these are living codes, maintained and extended by teams who choose Fortran again every year because it is fast, portable across the supercomputers they must run on, and close to the physics they encode.

Aerospace. When an engineer simulates air flowing over a wing, or the plume of a rocket engine, or the stresses in a wing spar, the heavy arithmetic is very often Fortran. NASA develops and releases computational-fluid-dynamics codes written in Fortran; the aircraft manufacturers and their suppliers run CFD and structural-analysis codes, many descended from lineages that reach back to the origins of finite-element analysis. The domain is a natural fit: aerodynamics and structural mechanics are, at bottom, partial differential equations discretized on grids — the exact computation you built a small version of in this book.

Energy. The energy sector is a quiet giant of scientific computing. Oil and gas companies turn petabytes of seismic echoes into three-dimensional images of the subsurface, and simulate how fluids move through a reservoir over decades — computations done, overwhelmingly, in Fortran on large clusters. The nuclear industry runs reactor-physics and neutron-transport codes, some first written in the 1960s and validated ever since, to design reactors and certify their safety. Fusion research and wind-energy CFD add to the demand. Wherever the product is energy and the method is simulation, Fortran is close by.

Academia and the community codes. Universities are where much scientific Fortran is written, taught (too rarely), and released to the world. The great community codes — CESM for the climate, Quantum ESPRESSO and VASP for the electronic structure of materials, and a long tail of astrophysics, combustion, and engineering codes — are developed by academic groups and used by thousands. A graduate student in a computational field who can genuinely write and modernize Fortran is unusually valuable to their group, and that value follows them into industry or a lab afterward.

Finance. The least expected entry on the list, and a real one. Parts of banking and insurance run legacy quantitative systems — pricing engines, risk models, actuarial calculations — in Fortran, for the same reason the reactor codes persist: the code works, it is validated, and it is numerically fast. This is a smaller and more specialized market than the others, but it is not zero, and it pays well.

🔗 Connection — the codes you have already met. You did not learn these names for the first time just now. WRF, CESM, VASP, Quantum ESPRESSO, and the LAPACK/BLAS libraries under NumPy were all introduced in Chapter 1, §1.2, and you have been building a miniature of exactly their kind of code — a finite-difference PDE solver — ever since. The distance from your heat solver to a production weather model is one of scale and validation, not of kind. You already know the shape of the work these employers do.

⚠️ Common Pitfall — do not oversell it, to others or to yourself. It is tempting, having learned that Fortran runs the weather and the reactors, to tell a recruiter that "Fortran runs everything." It does not, and the overstatement invites the eye-roll that ends the conversation. The honest and still-strong claim is the one Chapter 1 taught you: for the dense numerical kernels at the heart of scientific and engineering computing, Fortran remains one of the dominant languages, and often the fastest, and the institutions that depend on those kernels are among the most important in the world. That is enough. It does not need embellishment, and the people doing the hiring will trust you more for stating it precisely.

Notice what threads through every sector: Fortran is not dead — it is infrastructure, the load-bearing kind you only notice when it fails, which is why the public never notices it at all. The employers are real, their work matters, and the skill you have built is the one they are looking for.

40.2 The Roles: Computational Scientist, Research Software Engineer, and the Spectrum Between

Knowing where the work is leaves open what the work is called and what, day to day, it asks of you. The job titles in scientific computing are less standardized than in mainstream software, and the same person may be called different things at different institutions, but the roles cluster along a single spectrum: at one end, a scientist whose instrument happens to be a computer; at the other, an engineer whose product happens to be scientific software. Where you sit on that spectrum is mostly a question of what you want to spend your day thinking about — the science, or the software — and you can move along it over a career.

Definition (computational scientist). A scientist or engineer whose primary research tool is large-scale computation: someone who poses a scientific question, chooses or devises the numerical method to attack it, writes and runs the simulation, and interprets the results as science. A computational scientist typically holds an advanced degree in a domain — physics, atmospheric science, chemistry, mechanical engineering — and is a capable programmer because the computation is how they do their science, not a separate craft. They live at the science end of the spectrum: the code serves the question.

Definition (research software engineer). Often abbreviated RSE: a professional who combines genuine software-engineering expertise with enough research understanding to build and maintain the software that research depends on. The RSE is a recognized and growing career track — with its own professional societies and, increasingly, its own job ladder at universities and labs — created precisely because research increasingly runs on software too large and too long-lived to be maintained well by scientists coding on the side. An RSE lives at the software end of the spectrum: the science sets the requirements, and the engineering — architecture, testing, performance, reproducibility — is the craft.

Between and around those two poles sit two more familiar shapes:

The HPC engineer deserves its own mention because it is where much of the raw-Fortran, make-it-fast work lives. An HPC engineer (sometimes "performance engineer" or "scientific software engineer") is the person a research group or a lab brings in when a code needs to run faster, scale to more nodes, or move onto a GPU. This is the role that lives inside Part VII and Part VIII of this book: profiling to find the hot loop, reordering it for the cache, vectorizing it, parallelizing it with OpenMP or MPI or coarrays, offloading it to an accelerator. If the chapters on why Fortran is fast, on profiling, and on parallelism were the ones that made you lean forward, this is your role.

💡 Intuition: think of a spectrum with a dial. Turn the dial toward science and your day fills with the domain — the physics, the chemistry, the atmosphere — and the code is a means to it. Turn it toward software and your day fills with architecture, performance, and correctness, and the science is the requirement the software must meet. Most real jobs sit somewhere in the middle and let you turn the dial a little over time. The book has equipped you for the whole range: the numerical chapters (Part V) for the science end, the performance, parallel, and software-engineering chapters (Parts VII–IX) for the software end.

The practical upshot is that you do not have to choose now. A domain scientist who keeps sharpening their software skills drifts toward RSE; an RSE who goes deep into one domain becomes a computational scientist in it. What every point on the spectrum shares is the thing this book gave you: the ability to write, read, and reason about fast numerical code in Fortran, and to connect it to the wider world of Python, C, and the HPC toolchain.

🔄 Check Your Understanding. 1. Your friend has a physics PhD, runs an existing astrophysics code to answer research questions, and modifies it only lightly. Which role best fits, and which end of the spectrum is it on? 2. A university hires someone whose whole job is to maintain and speed up the software several research groups depend on, with software engineering as the core skill. What is this role called? 3. Name two skills, from this book, that matter most to the "HPC engineer" end of the role spectrum.

Answers

(1) A domain scientist — furthest toward the science end; the code is a tool they run and lightly adapt, not something they primarily build. (2) A research software engineer (RSE) — the role created for exactly this need, with software engineering first and enough domain to serve it. (3) Any two of: profiling and benchmarking (Chapter 28), optimization for cache and vectorization (Chapter 29), and parallelism with OpenMP/MPI/coarrays (Chapters 32–34). Performance and parallelism are the HPC engineer's core.

40.3 The Fortran Programmer Shortage — and What It Means for You

Here is the part that ought to change how you feel about the last thirty-nine chapters. In several of the sectors above — national laboratories, weather and climate agencies, aerospace, energy — there are, by many accounts, more positions that need a Fortran programmer than there are people able to fill them. This is widely reported within the community that does this work, and you should hold it exactly as Chapter 1 taught you to hold such claims: as a real and encouraging pattern, not as a precise statistic. Nobody has a clean, audited count of "open Fortran jobs versus qualified applicants," and you should distrust anyone who quotes one to two decimal places. What is genuinely and repeatedly observed is an imbalance, and its causes are easy to understand.

Why the shortage exists. Three forces combine:

1. Universities largely stopped teaching it. A generation of computer-science and engineering curricula moved to C, Java, Python, and web technologies, so most new graduates have never written a line of Fortran and, worse, believe it is obsolete. The supply of new Fortran programmers shrank.
2. The codes did not go anywhere. The weather models, the reactor codes, the CFD packages, the climate models — millions of lines of validated science — are still running, still being extended, and still need people to maintain, modernize, and speed them up. The demand held steady or grew.
3. The experts are retiring. Much of the world's scientific Fortran was written by people who are now at or past retirement age, and they are taking with them not just the ability to write Fortran but the institutional memory of why the code does what it does. Replacing them is urgent and hard.

Put a shrinking supply against a steady demand and a wave of retirements, and you get exactly the imbalance that gets reported: jobs that stay open, teams that cannot find people, and managers who will happily train a smart newcomer who already knows the language because so few of them exist.

🚪 Threshold Concept — scarcity is leverage. The ordinary way to think about a skill is "will it get me a job?" The more powerful way, once you see it, is "how many other people can do this, and how much does someone need it done?" Mainstream skills — a little Python, a React front end — are valuable but abundant; you compete with a crowd. The ability to walk into a two-hundred-thousand-line validated Fortran code, navigate it (Chapter 36), and modernize it without breaking the science (Part IV) is rare and badly needed. Rarity plus need is leverage — over which jobs you can get, over what they pay, and over how much your judgment is trusted. You have spent this book acquiring a scarce, needed skill on purpose. That is worth more than a longer list of common ones.

What it means for you — honestly. The shortage is an opportunity, not a guarantee, and the difference matters. It does not mean that knowing Fortran alone will hand you a job; every one of these roles also wants domain understanding, general software skills, and the ability to work with Python and the HPC toolchain (which is the subject of the next section). What the shortage does mean is that Fortran fluency is a genuine differentiator — the thing on your résumé that makes a hiring manager in these sectors stop and read, precisely because so few candidates have it. You are not entering a crowded field. You are entering a field that is quietly worried about where its next generation of programmers will come from, and you are one of them.

⚠️ Common Pitfall — the shortage is a tailwind, not a free ride. Do not read "shortage" as "I can stop here." The candidates who convert the shortage into offers are the ones who pair Fortran with the rest: Python for orchestration and analysis, C for interoperability, OpenMP/MPI for scale, git and testing and reproducibility for credibility. Fortran gets your résumé read; the pairing gets you hired. Think of the shortage as removing your competition, not your obligation to be good.

A note on compensation, kept honest. Salaries in scientific computing vary enormously by country, sector, seniority, and whether the employer is a government lab, a university, or a company, so this book will not quote you a number — any single figure would be misleading, and a fabricated one would be worse. What is true and checkable is that these are skilled, credentialed roles that pay accordingly; that US national labs and federal science agencies post openings publicly (on the operating contractors' career sites and, for federal civil-service posts, on USAJOBS) with the pay bands stated; and that European centers like ECMWF and the Met Office publish their vacancies and terms as well. When you want real numbers, get them from those primary sources for the specific role, sector, and country you are considering — not from a textbook's guess.

🔄 Check Your Understanding. 1. Why is the "Fortran programmer shortage" framed in this book as widely reported rather than as a hard statistic? 2. Give the three forces that combine to produce the shortage. 3. True or false, with a reason: "Because there is a shortage, learning Fortran alone is enough to get one of these jobs."

Answers

(1) Because the imbalance is genuinely and repeatedly observed within the field, but no one has a clean, audited count of open positions versus qualified applicants — so it is honest to report the pattern and dishonest to quote a precise number. (2) Universities largely stopped teaching Fortran (shrinking supply); the large validated codes are still running and growing (steady or rising demand); and the original expert authors are retiring (loss of both skill and institutional memory). (3) False. The shortage makes Fortran a strong differentiator that gets your résumé read, but the roles also require domain understanding, general software skills, and the Python/C/HPC toolchain. Fortran opens the door; the pairing gets you through it.

40.4 Presenting Fortran on a Résumé: An Asset, Not an Embarrassment

Somewhere along the way, a lot of programmers absorbed the idea that Fortran on a résumé is faintly embarrassing — a confession that you learned to program a long time ago, or in an unfashionable corner. Put that idea down. In the sectors of §40.1, Fortran is not a confession; it is a credential. The mistake is not listing Fortran — it is listing it badly, alone and unframed, so that it reads as "legacy only" instead of as "high-performance computing." This section is about framing it right.

Frame it as high-performance computing, not nostalgia. The word "Fortran" by itself, on a line by itself, invites the wrong picture — punch cards, GOTO, uppercase. The same skill framed as modern high-performance scientific computing, with the surrounding toolchain named, invites the right one: someone who can make numerical code run fast on serious hardware. The content is identical; the framing decides which mental image the reader forms. This is the theme of the whole book turned into a résumé line: modern Fortran is a modern language, and you should present it as one.

Pair it — the winning profile is polyglot. No one in these roles writes only Fortran, and no résumé should suggest you would want to. The valuable and marketable profile is the one this book deliberately built: the hot numerical kernel in Fortran, the orchestration and analysis in Python, interoperability through C, and scale through the HPC toolchain. That combination — not any single language — is what the work actually looks like, and it is what the hiring manager is hoping to find.

🐍 Python Comparison — the pairing is the point (theme six). Throughout this book we have insisted that Fortran and Python are better together: write the kernel where it must be fast in Fortran, wrap it with f2py (Chapter 15), and orchestrate, analyze, and visualize in Python. On a résumé, that same pairing is your single strongest line, because it signals something rare: you know where the boundary is — which work belongs in a fast compiled language and which belongs in a productive scripting one — and you can move data across it. A candidate who writes "Fortran" reads as a maintainer of old code. A candidate who writes "high-performance numerical kernels in modern Fortran, wrapped for Python with f2py, parallelized with OpenMP and MPI" reads as an HPC engineer. Same person; the second framing is true and gets interviews.

Show impact, and name the real things. Scientific-computing résumés are more convincing when they name concrete libraries, methods, and — carefully, honestly — outcomes. "Solved linear systems" is weak; "solved dense linear systems by calling LAPACK (dgesv) from Fortran" (Chapter 21) is specific and checkable. "Made a code faster" is weak; "profiled a finite-difference solver, reordered its stencil loop for column-major access, and parallelized the update with OpenMP" names real skills a specialist recognizes. If you can honestly attach a measured speedup, attach it — and label it as what it is, a measurement on specific hardware, never a universal promise. (Every benchmark number in this book was framed that way for the same reason.)

Here are illustrative résumé lines — templates to adapt to your real work, not claims to copy:

Skills (illustrative — adapt to your own experience):
  Modern Fortran (2018), Python (NumPy/matplotlib), C interoperability (iso_c_binding)
  HPC: OpenMP, MPI, coarrays; profiling (gprof), cache/vectorization optimization
  Numerical methods: finite differences, linear algebra (LAPACK/BLAS), ODE/PDE solvers
  Software engineering: git, unit + regression testing, CI, reproducible builds

Project line (illustrative):
  Built a modular, parallel 2-D heat-equation solver in modern Fortran: finite-difference
  core, OpenMP/MPI parallelism, f2py Python driver, VTK output, pFUnit tests, and CI.

Every item in that first block is a chapter of this book, and the project line is the thing you built across all of them. You are not inventing a profile; you are describing one you already have.

⚠️ Common Pitfall — three ways to frame Fortran wrong on a résumé. (1) Alone and unqualified — "Languages: Fortran, Java" reads as legacy. Say "modern Fortran (2018)" and surround it with the toolchain. (2) Apologetically — never write "some old Fortran"; you either know it or you don't, and you do. (3) Overstated — do not claim a benchmark you did not run or a scale you did not reach. In these sectors the reader can tell, and a single unsupportable claim discredits the honest ones beside it. The discipline the whole book modeled — state what is true, precisely, and label the illustrative as illustrative — is the same discipline that makes a résumé credible.

🔧 Modern vs Legacy — the same fact, two framings. The identical experience, written two ways:

text Legacy-only framing (invites the wrong picture): "Maintained Fortran code."

text HPC framing (invites the right one): "Modernized and optimized a validated Fortran simulation code: added modules and intent, replaced GOTO-based control flow, parallelized the hot loop with OpenMP, and added regression tests to guarantee bit-for-bit-equivalent results."

The second is not embellishment — every clause is a skill from Part IV, Part VII, and Part IX. It is the same work, described so the reader sees what it actually required. Legacy code is not a burden to hide — it is validated infrastructure, and the ability to improve it safely is one of the most valuable things you can claim.

40.5 Where to Go Next: Open Source, Your Portfolio, and the Rest of Your Career

You have the skill and you know who wants it. The last question is how to turn a finished textbook into momentum, and the answer has two parts: contribute to something real, and show what you have built.

Contribute to an open-source scientific code. The fastest way to convert private competence into public evidence — and to keep learning — is to contribute to an open code that others can see you contributing to. The barrier feels high and mostly is not. The fortran-lang community maintains projects designed to be approachable: the Fortran standard library (stdlib) and the Fortran Package Manager (fpm), both of which you met in Chapter 16 and Chapter 39, take contributions from newcomers and label issues that are good starting points. Beyond those, the domain community codes — climate, astrophysics, materials, CFD — are increasingly open on GitHub and increasingly glad of help.

Everything you need to make a first contribution is in this book. You learned to read a large unfamiliar code — find the entry point, build a module map, follow the data — in Chapter 36. You learned to test and document it — pFUnit, regression tests, FORD, CI — in Chapter 37. A good first contribution is often not new physics at all: it is a fixed typo in the docs, a missing test, a clarified error message, a small performance fix in a hot loop you profiled. Small, correct, well-tested contributions are how you earn the standing to make bigger ones — and every one of them is a public, linkable record that you can do this work.

💡 Intuition — a contribution is a conversation, not an exam. Newcomers freeze at the idea of touching a famous code, imagining they must arrive with a brilliant, complete change. Maintainers see it the opposite way: a small, clear, well-tested pull request that does one thing correctly is a gift, and the review that follows is how you learn the project's conventions. Read the contributing guide, pick the smallest real improvement you can verify, test it the way Chapter 37 taught you, and open the conversation. That is the whole loop, and it only gets easier.

Your solver is your portfolio. The other half of momentum is the thing you have been building since Chapter 1: the heat-equation solver. It is no longer a toy. By the capstone (Chapter 38) it is modular, validated, optimized, parallel, and visualized — which is to say it is exactly the shape of the real codes in §40.1, only smaller. That makes it a genuine portfolio piece: concrete, complete, and completely understood by you, which is more than can be said for most of what ends up on a résumé. The Project Checkpoint below is where you package it to be seen.

🔗 Connection — the whole book was building an artifact. Every Project Checkpoint, from choosing your domain in Chapter 1 to the paper-style writeup in Chapter 38, was quietly assembling one thing you could show an employer. Performance is not accidental, and neither is a portfolio: it is the accumulated result of doing the small increments well. You did the increments. Now collect them into something with your name on it.

And then — keep going. The appendices of this book are a reference you will return to for years; the Fortran 2023 chapter points at where the language is heading; the fortran-lang community is welcoming and active. Fortran fluency is not a box you have now checked but a capability you will deepen — across a career spent, if you like, doing some of the most consequential computing there is.

Project Checkpoint

This is the final checkpoint, and it does not add a line of physics. It does something more useful: it turns the solver you built across thirty-eight chapters into a portfolio piece — the thing you put on GitHub, link from your résumé, and show an employer. A working program in a folder is private evidence. A packaged program — with a README that explains it, a license that lets others use it, a figure that shows what it does, and an abstract that describes it in a paragraph — is public evidence. Four small artifacts do the whole job.

1. The README. The first thing anyone sees. It states, in order: what the code solves, the physics (the heat equation, $\frac{\partial u}{\partial t} = \alpha\nabla^2 u$, on a square plate with fixed-temperature edges), how to build and run it (fpm build && fpm run), what output it produces, and — the mark of real scientific software — how it is validated (it reproduces the analytical steady state; its stencil converges at the expected order, from Chapter 22). The repository already has the shape a reader expects, laid down in Chapter 36:

heat-solver/
├── README.md          what it solves, the physics, build/run, results, validation
├── LICENSE            the terms others may use it under (e.g. MIT for the code)
├── fpm.toml           the build manifest
├── src/               kinds, heat_types, heat_solver, heat_io, timers
├── app/main.f90       the driver
├── test/              pFUnit + regression tests (Chapter 37)
└── figures/           the steady-state heat map (below)

2. The license. Code without a license is, legally, code no one may reuse. Add one deliberately. A permissive license such as MIT or BSD-3-Clause lets others build on your code with minimal friction and is conventional for a portfolio project; the choice is yours, but the presence of a LICENSE file is what signals you understand that software is something other people use. (This book's prose is CC-BY-SA-4.0; your code can carry its own terms.)

3. One figure. A picture earns the second glance a wall of text does not. Your solver already writes VTK per timestep (Chapter 26); open the final state in ParaView and export one clean image.

Described Figure — the steady state. A square domain. The top edge glows at the fixed hot temperature ($100$), the other three edges are held cold ($0$). Inside, color grades smoothly from hot at the top to cold at the bottom and sides — warm oranges near the hot edge relaxing through yellows and greens to deep blue in the cold corners — the visible signature of heat diffusing inward until it settles. A colorbar labels the temperature scale. One image; it says "this program simulates a physical process and produces a correct, recognizable result" faster than any paragraph.

4. The abstract. One paragraph, the elevator description a reviewer or a hiring manager reads first:

A modular, parallel two-dimensional heat-equation solver written in modern Fortran (2018). The code discretizes the diffusion equation with a five-point finite-difference stencil and marches it forward with explicit, CFL-stable time stepping. It is organized into clean modules (precision, field type, solver, I/O), parallelized with OpenMP and MPI, validated against the analytical steady-state solution, and writes VTK output for visualization in ParaView. Built and tested with the Fortran Package Manager (fpm) under continuous integration.

Every clause of that abstract is a chapter you completed, and every one is true of the code you actually wrote. code/project-checkpoint.f90 is the finished solver assembled into a single self-contained file, carrying exactly this framing in its header — the same validated $5\times5$ result you first hand-computed in Chapter 24, now presented as the artifact you show the world. From the two-sentence problem statement you sealed in Chapter 1's checkpoint to this — a real simulation you built, understand completely, and can hand to an employer — is the whole arc of the book, finished. That was the plan from the first page. You built the thing.

Summary

This closing chapter mapped the world your new skill opens and sent you into it.

The two things worth remembering from this chapter: first, that the sectors depending on Fortran are real, important, and — by many accounts — short of the people who can do the work, which makes your skill a genuine differentiator rather than a crowded one. Second, that Fortran belongs on your résumé framed as what it is: modern, high-performance, and paired with Python and the HPC toolchain — the profile the work actually requires and the one that gets you hired.

Spaced Review

The book's final review is a broad one, spanning Parts I–IX — a last synthesis of the arc you have travelled. Answer from memory before opening the details; if any question is fuzzy, the linked chapter is where to refresh it.

1. (Parts I & VII — the core "why.") Name the two 1950s design decisions that let Fortran compilers produce exceptionally fast numerical code, and for each, say in one line why it helps.
   

   Answer

   (1) Arrays are first-class objects — the compiler knows an array's shape and layout, so a whole-array operation like a = b + c hands it the structure it needs to vectorize and parallelize (Chapters 5, 27). (2) Procedure arguments are assumed not to alias — the compiler may assume two array arguments do not overlap in memory, freeing it to reorder loads and stores for speed, which C could not do until it added restrict (Chapter 27, the no-aliasing advantage). Both trace to Chapter 1.

2. (Part I — the trap that bites everyone.) What is $7/2$ in Fortran when both operands are default integers, and what one change makes it $3.5$?
   

   Answer

   3 — integer division truncates toward zero (Chapter 3). Make at least one operand real — e.g. 7.0_dp/2 or real(7,dp)/2 — and the result is 3.5. This is one of Fortran's sharpest edges and the reason the book uses real(dp) literals with kind suffixes everywhere.

3. (Parts II & IV — organization, old and new.) In modern Fortran, what construct replaced the FORTRAN 77 COMMON block for sharing state, and name two concrete advantages it brings.
   

   Answer

   The module (Chapter 8; the legacy contrast is Chapter 17). Advantages (any two): it is typed and checked by the compiler rather than an untyped memory overlay; it gives an explicit interface for its procedures for free; it supports public/private access control; and it can be reasoned about in isolation. This is the "modules replace the global mess of COMMON" threshold concept.

4. (Parts V & VIII — the project's spine.) In one or two sentences each: what does the five-point stencil compute in the heat solver, and what does the CFL condition constrain?
   

   Answer

   The five-point stencil approximates the Laplacian $\nabla^2 u$ at each interior grid point from its four neighbors and itself, giving the spatial part of the finite-difference heat equation (Chapter 24). The CFL condition constrains the time step: for explicit stepping, $\Delta t$ must be small enough (relative to $\alpha$ and the grid spacing) or the simulation goes unstable and blows up (Chapter 24). Parallelizing the update is the work of Part VIII (OpenMP, coarrays, MPI).

5. (Parts III & IX — the pairing and the practice.) Why does the Fortran-plus-Python combination make such a strong professional profile, and name the tool that bridges them.
   

   Answer

   Because it matches how the work is actually done: the hot numerical kernel goes in fast compiled Fortran, while orchestration, analysis, and visualization go in productive Python — and knowing where that boundary is is exactly the judgment these roles need (Chapter 15). The bridge is f2py, which wraps a Fortran routine as an importable Python extension module. This is the sixth theme: Fortran and Python are better together.

What's Next — Beyond This Book

There is no forty-first chapter. This is the last page, and the honest thing to say on it is that the book is over but the work is not — it is just beginning, and now it is yours.

Go find the sentence you sealed in Exercise 1.28, back in Chapter 1, when "why learn Fortran?" was a question you could only answer on faith. Read it now, with a compiler on your machine, a parallel solver in your repository, and forty chapters of understanding behind you. Maybe your answer was right and you can now say why it was right. Maybe it was thin and you would replace it with something specific and hard-won. Either way, the gap between that sentence and the answer you would give today is the exact measure of what you have learned — and it is a larger gap than you probably expect.

You started at Hello, world. You end with the ability to write modern, fast, parallel, tested scientific Fortran; to read and modernize the code the world already depends on; and to pair all of it with Python and the HPC toolchain. That is a rare and needed skill, in service of some of the most consequential computing there is — the weather, the climate, the reactors, the aircraft, the stars. The institutions that do that work are looking for people who can do what you can now do, and there are fewer of you than there are of them.

So package your solver. Open your first pull request. Apply for the thing that looked out of reach forty chapters ago. Fortran is not dead — and neither, it turns out, is the future of the people who take the trouble to learn it well. You took the trouble. Now go build something that matters, fast.

Thank you for reading. Welcome to the field.