In the winter of 2024, a research group at the Technical University of Munich dusted off a Fortran subroutine that had last been compiled on a machine with a fraction of the memory in a modern smartphone. The routine, written in 1993, forms the core loop of a turbulence simulator used to model fluid flows in engineering and atmospheric science. Recompiling it took three weeks of patient work, not because the code was wrong, but because the world around it had changed. Compilers, hardware, and even the definition of floating-point arithmetic had shifted under its feet. The episode is a vivid example of what computational scientists call software archaeology: the slow, often tedious process of resurrecting code that still holds scientific value but no longer runs as written.

A 1993 Fortran Routine That Refuses to Die

The routine in question computes the time evolution of a turbulent velocity field using a spectral method. It was written by a doctoral student at the Technical University of Munich who later moved into industry and lost track of the code. The routine survived because a former colleague saved a tarball of the project to a departmental server, then to a personal drive, then to a cloud archive that no one remembered paying for. When the group needed a reference implementation to validate a new GPU-based solver, they found the old file intact.

Fortran’s persistence in scientific computing stems from its design for numeric calculation. The language’s array operations and loop structures map cleanly onto the hardware of the 1970s and 1980s, and decades of investment produced heavily optimized compilers that still generate some of the fastest executable code for dense linear algebra and partial differential equations. The turbulence simulator’s core loop, written in Fortran 77, was never ported because it never needed to be: it ran fast enough, and the scientists who maintained it understood it deeply.

The recompilation effort was not a simple matter of running a modern compiler on the old source. Fortran 77 code often relies on implicit typing, fixed-form line lengths, and assumptions about memory layout that modern compilers handle differently. The group’s first attempt produced a binary that ran, but the results diverged from the original published benchmark after roughly 1,000 time steps. The divergence was small, on the order of 1e-12 in the velocity field, but for a turbulence simulation, small errors grow exponentially. The team needed bit-for-bit identical output to trust the new solver.

This kind of work is rarely visible in published papers. It happens in the background, in the weeks before a submission deadline, when a researcher realizes that the reference code from a 2015 paper no longer compiles. The turbulence simulator’s case is unusual only in the age of the code and the fact that the original author was still reachable. Most dead code stays dead, and the science built on it becomes harder to verify.

Why Fortran Outlived Its Obituaries

Fortran has been declared obsolete roughly once a decade since the 1980s. Each time, a newer language with better abstractions, better memory safety, or better tooling has promised to replace it. C, C++, Python, Julia, and Rust have all been proposed as successors. Yet as of 2024, a substantial fraction of the world’s climate models, weather prediction systems, and computational fluid dynamics codes still run Fortran at their core. For example, the Community Earth System Model at the National Center for Atmospheric Research, the ECMWF’s Integrated Forecasting System, and the MIT General Circulation Model all rely on Fortran for their dynamical cores. The reasons are practical. Fortran compilers produce tight loops with minimal overhead, and the language’s array semantics allow compiler optimizations that are difficult to achieve in languages with pointer aliasing. The massive legacy codebase, estimated at hundreds of millions of lines across government labs and universities, represents an investment that no single institution can afford to rewrite. Domain scientists, who are experts in fluid dynamics or atmospheric chemistry rather than software engineering, are comfortable reading and modifying Fortran. Learning a new language is a cost that few are willing to pay without a clear benefit. Performance comparisons vary by workload, but for dense matrix operations and stencil computations, Fortran often matches or beats C, and it can outperform Python by orders of magnitude without additional libraries. The gap narrows with careful use of modern frameworks, but the default path for a researcher is still to write the hot loop in Fortran and wrap it with a Python interface. The turbulence simulator’s original authors never felt the need to migrate, and their successors have not found a compelling reason either.

The slow migration to newer languages is not a failure but a rational response to incentives. A scientist’s career advances through publications, not through rewrites. A ported code that produces slightly different results invites skepticism; a well-tested Fortran routine that matches published benchmarks does not. As one researcher put it, the safest code is the code that has already been debugged for two decades.

The Recompilation Challenge: Bits, Compilers, and Standards

Recompiling old code sounds trivial until you try it. The first obstacle is the compiler. Modern Fortran compilers, such as gfortran and Intel’s ifort, support the Fortran 2018 standard but have largely dropped or altered behavior for some Fortran 77 constructs. Fixed-form source, where columns 1 through 72 are significant, is still accepted with a flag, but the defaults have changed. The original code used a nonstandard extension for dynamic memory allocation that no longer compiles without modification.

Hardware changes compound the problem. The 1993 code was written for a single-core processor with 32-bit registers and a specific model of floating-point arithmetic. Modern CPUs use 64-bit registers, wider SIMD units, and fused multiply-add instructions that change the order of operations. Even when the same arithmetic is requested, the compiler may reorder operations to improve speed, producing results that differ in the last few bits.

Precision and rounding are the subtle enemies of reproducibility. The IEEE 754 standard defines how floating-point numbers should be rounded, but it leaves room for implementation choices in extended precision and in the order of multiply-add. A routine that worked with one compiler and hardware combination may produce slightly different results on another. For the turbulence simulator, a difference of one unit in the last place (ULP) in the initial condition grew to a visible discrepancy after 10,000 time steps.

The team spent most of the three weeks debugging bit-level discrepancies. They used binary comparison tools to find the first time step where the old and new results diverged, then worked backward to identify the operation that caused it. In one case, the culprit was a compiler optimization that replaced a division with a reciprocal and a multiply, a mathematically equivalent transformation that is not bit-identical. The fix was a compiler flag that disabled the optimization for a single loop.

How the Routine Resurfaced and Was Rescued

The routine was found in an archived repository that the university had migrated from an old Solaris server. The tarball contained the source code, a Makefile, and a set of input files, but no documentation beyond the comments in the code itself. The original author, now in his late fifties, was located through a departmental alumni list and agreed to answer questions over email.

His first response was blunt: he did not remember writing the routine, but he recognized the style. Over the course of several exchanges, he clarified the assumptions that were implicit in the code: the grid size was always a power of two, the boundary conditions were periodic, and the time step was fixed by the Courant condition rather than adapted. These details, obvious to the original author, were invisible to the new team until he pointed them out.

The rescue strategy was gradual modernization rather than a rewrite. The team kept the Fortran 77 core intact, but wrapped it in a modern module system and replaced the nonstandard memory allocation with a standard-compliant equivalent. They added a test harness that compared the output against the original benchmark data, which had been preserved in a printout from 1994. The harness allowed them to verify that each change preserved the bit-level behavior.

Interoperability with modern frameworks came last. The team wrote a C interface that allowed the Fortran routine to be called from Python, so that the new GPU solver could use the old code as a reference. The interface was deliberately thin, passing arrays of doubles without copying. The result is a hybrid system: the new solver runs on GPUs, but its output is validated against the 1993 routine on a single CPU core.

The episode took three weeks, but the team estimates that a full rewrite would have taken months and introduced new bugs. The old code was not elegant, but it was correct, and correctness is the scarcest resource in scientific computing.

What This Means for Reproducibility in Science

The turbulence simulator’s case is a reminder that reproducibility is not just about publishing data and code. It is about preserving the environment in which the code runs: the compiler version, the hardware, the operating system, and the libraries. A paper that includes code but not the toolchain is only partially reproducible. The scientific community has begun to address this through containers and virtual machines, which bundle the entire execution environment into a single artifact.

Containerization is not a perfect solution. A container built for x86 hardware will not run on ARM without emulation, and the performance penalty can be significant for compute-intensive workloads. Some research groups have adopted a hybrid approach: publish the source code and a container, but also maintain a reference implementation that runs on minimal hardware. The turbulence simulator’s team is considering adding a container to their repository, but they are aware that containers themselves become obsolete as base images are deprecated.

Software citation is another piece of the puzzle. The 1993 routine was never published in a software journal, and the original author received no formal credit for it. The team has since added a citation to the paper that describes the code, but the citation is a pointer to a paper, not to the code itself. The community is moving toward software citation standards that recognize code as a research output, but adoption is slow.

Long-term data and code stewardship is an institutional problem. University repositories are often underfunded and staffed by librarians who are not trained in software. National efforts, such as the Software Heritage archive, aim to preserve source code for the long term, but they cannot preserve the hardware or the compiler. The team’s experience suggests that the most reliable preservation strategy is to keep the code simple and well-documented, so that future scientists can recompile it with the tools of their era.

Lessons for Today’s Computational Scientists

The first lesson is to document assumptions. The original author knew that the grid size was a power of two, but he did not write it down. That single fact, recovered through email, saved the team days of debugging. A comment in the code, or a paragraph in a README, would have made the recompilation trivial.

The second lesson is to use version control from day one. The 1993 routine survived because someone saved a tarball, but the tarball was not versioned. The team could not tell which version of the code produced the 1994 benchmark. A version control system would have answered that question immediately.

The third lesson is to write for clarity, not only for speed. The original code was optimized for a machine that no longer exists. The team had to reverse-engineer the intent of several loops before they could modify them safely. Clear variable names and short functions would have reduced the reverse-engineering effort. Performance matters, but clarity is what survives.

The fourth lesson is to plan for future hardware changes. The team’s GPU solver is state of the art today, but it will face the same recompilation challenges in 2050. Writing portable code, avoiding hardware-specific intrinsics, and testing on more than one architecture are habits that pay off later.

The final lesson is to embrace community archives. The routine was saved by an individual, but it could easily have been lost. Institutional repositories, software journals, and community archives such as Zenodo provide a safety net for code that outlives its authors. The cost of depositing code is small; the cost of losing it is a three-week recompilation, or worse, a retracted paper.

The turbulence simulator’s core loop will not be recompiled again in another thirty years. It has been integrated into a modern framework, tested against benchmarks, and documented. But the next routine, written today by a graduate student, will face the same fate unless the community changes its habits. The tools for preservation exist, yet their adoption remains uneven. Funding agencies rarely mandate code deposit, and tenure committees seldom weigh software maintenance as a contribution. Until preservation becomes a recognized part of scientific practice, the cycle of rediscovery and recompilation will continue.