💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — Fortran is Dead, Long Live Fortran

Mention Fortran in 2026 and two reactions follow. First, "Why?" Second, "Is it still alive?" Both are the wrong question. The right one is: **"Why has Fortran refused to die after 70 years since 1957?"**

The answer is simple. Scientific computing is fundamentally about array operations, and no language does array operations better than Fortran. Compilers have accumulated 70 years of optimization, BLAS/LAPACK/ScaLAPACK/PETSc were written in Fortran, and ECMWF's IFS, NCAR's CESM, RIKEN's NICAM, and every CMIP6 climate model still runs in Fortran. Half the Top500 supercomputers list Fortran as their primary supported compiler.

But the 2026 landscape is not Fortran alone. Python's NumPy/SciPy/Pandas/Polars stack has become the de facto standard for data analysis, Julia 1.11 approaches Fortran performance as a dynamic language, JAX blurs ML and scientific computing through autodiff and XLA, and Mojo aims at Python syntax with SIMD/GPU. The APL family — J, K, BQN, Uiua — shows the extreme of array thinking.

This essay maps that entire terrain. The novelty of the Fortran 2023 standard, eight compilers (gfortran/LFortran/Flang/NVIDIA HPC/ifx/AOCC/XLF/Cray), HPC parallelism (OpenMP/MPI/CAF/DO CONCURRENT), climate and engineering model codebases, Python/Julia/R/MATLAB ecosystems, the APL family, GPU and quantum, supercomputers (Fugaku/Nurion/Frontier), and data formats (HDF5/NetCDF/FITS) — by the end, you have the 2026 map of scientific computing in hand.

Chapter 1 · Why Fortran Refuses to Die — 70 Years of Inertia

Let's clear up the most common misconceptions first.

**"Fortran is for old people."** Half true, half wrong. The average age of Fortran programmers is high. But the *code itself* has not aged. ISO/IEC 1539:2023 (Fortran 2023) was released in December 2023, and the 2018, 2008, 2003, and 95 standards successively introduced OOP, coarrays, submodules, and concurrent execution. Fortran in 2026 is a different language from Fortran in 1990.

**"Python replaced it all."** At the *language* level, yes. But the internals of NumPy and SciPy are written in C and Fortran (LAPACK). So the accurate claim is not "Python killed Fortran" but "Python taught us how to use Fortran without writing the frontend ourselves."

**"New projects all start in Julia or JAX."** New scientific ML projects, yes. But the *production* climate models operated by NCAR, ECMWF, NASA, JAXA, KMA, and NOAA are million-line Fortran codebases. Nobody has the resources to rewrite them in a new language.

The real reasons Fortran does not disappear are three.

1. **Array vocabulary.** A single line like `A(:,2:N) = B(:,1:N-1) + C(:,1:N-1)` unfolds into explicit loops with automatic compiler vectorization. NumPy's vocabulary is a copy of this origin.

2. **Numerical accuracy and ABI stability.** The Fortran standard nails down IEEE 754 floating point, cross-compiler calling conventions, and module interfaces. 2003 Fortran code runs *as-is* on 2026 compilers.

3. **HPC library legacy.** BLAS (1979), LAPACK (1992), ScaLAPACK, FFTW, PETSc, Trilinos — hundreds of thousands of functions written with the Fortran calling convention as the premise. The cost of throwing them away is astronomical.

So people who *learn to call* Fortran far outnumber people who *learn to write* Fortran. NumPy users are effectively calling LAPACK, JAX goes through LAPACK via BLAS and XLA recompiles. Fortran moved from a language you write directly to the *bedrock*.

Chapter 2 · The Fortran Standard Evolution — 77, 90, 95, 2003, 2008, 2018, 2023

Let's see the standard timeline at a glance.

1957 FORTRAN I IBM 704, John Backus, the first compiler

1966 FORTRAN 66 First ANSI standard

1978 FORTRAN 77 Structured IF/DO, CHARACTER type

1991 Fortran 90 Free form, array notation, modules, dynamic alloc

1997 Fortran 95 FORALL, WHERE, PURE

2004 Fortran 2003 OOP, C interop, procedure pointers

2010 Fortran 2008 CoArrays, submodule, DO CONCURRENT, BLOCK

2018 Fortran 2018 Teams, events, additional CAF features

2023 Fortran 2023 CONDITIONAL expr, token, additional array ops

The key turning point is Fortran 90 in 1991. Up through FORTRAN 77 is "old Fortran"; from Fortran 90 onward is "modern Fortran." With free-form source, modules, array slicing, and dynamic allocation, abstraction comparable to C++ or Python became possible.

Fortran 2003 brought OOP. The `type, extends :: shape` class inheritance, abstract interfaces, polymorphism, and type-bound procedures became standard. ISO_C_BINDING came in and standardized C library calls.

Fortran 2008 brought parallelism. CoArrays (`real :: x[*]`) for multi-node data sharing, DO CONCURRENT for safe parallel loops, and submodule for compilation unit separation.

The new features of Fortran 2023 are small but symbolic. A conditional expression more intuitive than `merge` like `if (cond) then val1 else val2`, token enhancement, and improved array operations. Modern Fortran is no longer a 90s language.

Chapter 3 · Eight Fortran Compilers — The 2026 Lineup

Fortran compilers are diverse, but only eight see meaningful production use in 2026.

| --- | --- | --- | --- |

**gfortran** is part of GCC; 14.x was released in May 2025. It supports nearly all of Fortran 2008, most of Fortran 2018, and parts of Fortran 2023. In academic and research settings it is effectively the default.

**LFortran 0.50** (2025) is the most interesting newcomer. Started in 2022 by Ondrej Certik under the MIT license, it has an **interactive mode**. The `lfortran` command brings up a REPL where you execute Fortran line by line — the Python experience, in Fortran. Backends include LLVM, C, x86, and WASM. The ASR (Abstract Semantic Representation) intermediate form is clean and makes it a good foundation for other tools.

**Flang (LLVM)** is the LLVM project's Fortran frontend. The previous PGI-based "Classic Flang" was deprecated in 2023, and the new Flang starting from "F18" sits in the LLVM 18+ mainline. It entered serious production use from 2025.

**NVIDIA HPC Compiler** comes from the PGI acquisition and is the de facto standard implementation of **CUDA Fortran** and **OpenACC**. To run code directly on GPU, this is effectively what you use. The command is `nvfortran`.

**Intel ifx** is the successor to old ifort, LLVM-based. From 2024, ifort was placed in deprecation, and ifx became standard. It extracts top performance from AVX-512 SIMD instructions on Intel CPUs. Bundled with oneAPI, so it is free.

**AMD AOCC** is the LLVM Flang base optimized for AMD Zen architecture. It is often 5–15% faster than gfortran on EPYC servers.

**IBM XLF** is the standard Fortran compiler for POWER systems and z/OS, with a commercial license. Parts of finance and climate models are tied here.

**Cray Fortran (CCE)** is the optimal compiler for HPE Cray EX systems — exascale supercomputers like Frontier, Aurora, and El Capitan. Without it, you cannot extract maximum performance from the Top500 number-one machine.

Chapter 4 · A Deep Look at LFortran — Fortran's IPython Moment

As of 2026, LFortran is the most interesting Fortran project. Why?

First, the **interactive REPL**. For 70 years Fortran has enforced a compile-execute cycle. LFortran breaks it.

$ lfortran

LFortran 0.50.0

>>> integer :: i, n

>>> n = 10

>>> do i = 1, n

... print *, i*i

... end do

100

A Jupyter kernel exists. Fortran notebooks are now possible. This is why education has reacted explosively.

Second, the **modular architecture**. LFortran cleanly separates frontend (parser/AST) and backend (LLVM/C/x86/WASM). The ASR (Abstract Semantic Representation) intermediate form unifies every backend. Other tools can read ASR to do Fortran code analysis and transformation.

Third, **WebAssembly output**. `lfortran --backend=wasm` yields a .wasm binary. Fortran can run in the browser — significant meaning for education and demos.

Fourth, the **MIT license**. Unlike gfortran (GPL), LFortran is free for commercial use and integration. Suitable for embedded systems or cloud services that need to embed a Fortran compiler.

Limits are also clear. As of May 2026, LFortran implements parts of Fortran 90 and parts of 2008. CoArray, OpenMP, and OpenACC are unfinished. It is too early to compile actual HPC code. But it shows large progress every six months, so by 2027 it has a high chance of reaching production use.

Chapter 5 · fpm — Fortran's Cargo / pip

Fortran's weakest link was the build system. While C++ had CMake and Conan, Rust had Cargo, and Python had pip, Fortran sat in the Makefile + autoconf era.

**fpm (Fortran Package Manager)** changed this. Started in 2020 by the fortran-lang.org community, 1.0 came out in 2024.

fpm.toml

name = "my_project"

version = "0.1.0"

[dependencies]

stdlib = { git = "https://github.com/fortran-lang/stdlib" }

fftpack = { git = "https://github.com/fortran-lang/fftpack" }

[[executable]]

name = "myapp"

source-dir = "app"

main = "main.f90"

$ fpm build

$ fpm run

$ fpm test

$ fpm install

Nearly the same experience as Cargo. Dependencies are pulled by Git URL, builds parallelize automatically, the test framework is integrated, and a package index (fpm-registry) exists.

Thanks to fpm, the Fortran library ecosystem is alive again. Active projects like **fortran-lang/stdlib** (standard library), **fortran-lang/fftpack**, **fortran-lang/fortuno** (testing), **awvwgk/json-fortran**, **jacobwilliams/json-fortran**, and **certik/fastGPT** are growing on the fpm base.

Chapter 6 · OpenMP, MPI, CoArray, DO CONCURRENT — Fortran's Four Parallelism Models

The real strength of Fortran is parallelism. How do you choose among four models?

+----------------------------------------------------------------+

| Fortran Parallelism — 4 Models |

| |

| OpenMP Single node, multi-thread, shared memory |

| !$omp parallel do |

| |

| MPI Multi-node, message passing, distributed mem |

| call MPI_Send / MPI_Recv |

| |

| CoArray (CAF) Distributed, expressed in Fortran syntax |

| a[5] = a[3] + b[1] |

| |

| DO CONCURRENT Compiler-auto-parallel safe loop |

| do concurrent (i=1:N) |

+----------------------------------------------------------------+

**OpenMP 5.2** (2021) is the single-node multi-thread model. A one-line directive parallelizes a loop.

!$omp parallel do reduction(+:s)

do i = 1, N

s = s + a(i) * b(i)

end do

!$omp end parallel do

It is the easiest and the most widely used. gfortran, ifx, and NVIDIA HPC all support OpenMP 5.x. OpenMP 5.2 standardized GPU offload — the `!$omp target` directive lets you launch code on GPU without CUDA/HIP/SYCL.

**MPI 4.1** (2023) is the multi-node message passing standard. The standard communication scheme for supercomputers. Implementations vary: OpenMPI, MPICH, Intel MPI, Cray MPICH. MPI 4.1 brought partial datatypes, persistent collectives, and the session model.

**CoArray Fortran (CAF)** is the standard distributed model that entered Fortran 2008. Without separate library calls, it expresses multi-node data sharing in *language syntax*.

real :: a(100)[*] ! All images hold a(100)

a(:) = a(:)[3] ! Copy image 3's a into my a

sync all ! Synchronize all images

CAF has the steepest learning curve but is the most elegant. OpenCoArrays is a library that implements CAF on top of GFortran/gcc using MPI.

**DO CONCURRENT** (Fortran 2008) is a safe loop the compiler auto-parallelizes.

do concurrent (i = 1:N) local(tmp)

tmp = a(i)**2

b(i) = tmp + c(i)

end do

Because the *language guarantees* no dependency between loop iterations, the compiler is free to vectorize, multi-thread, or GPU-offload. NVIDIA nvfortran automatically lifts DO CONCURRENT to GPU — without OpenMP or OpenACC directives.

Chapter 7 · BLAS, LAPACK, PETSc — The HPC Library Ecosystem

You may not write Fortran directly, but nearly everyone uses BLAS and LAPACK. NumPy, MATLAB, R, Julia, Octave, SciPy — for all of them, LAPACK calls are the core.

+----------------------------------------------------------------+

| HPC Numerical Library Stack |

| |

| +------------------------------------------+ |

| | Apps: SciPy, NumPy, MATLAB, Julia, R | |

| +------------------------------------------+ |

| | LAPACK (1992) — Linear algebra (solvers) | |

| +------------------------------------------+ |

| | BLAS (1979) — Vector/matrix primitives | |

| +------------------------------------------+ |

| | ScaLAPACK/PETSc — Distributed extension | |

| +------------------------------------------+ |

+----------------------------------------------------------------+

**BLAS (Basic Linear Algebra Subprograms)** started in 1979 as a standard interface. Three levels: Level 1 (vector-vector), Level 2 (matrix-vector), Level 3 (matrix-matrix). Level 3 is the most important — the `gemm` (general matrix multiply) function became the standard supercomputer benchmark.

Implementations vary. **OpenBLAS** (open source, most popular), **Intel MKL** (Intel CPU optimized, free use), **AMD AOCL** (AMD optimized), **BLIS** (research, modular), **Apple Accelerate** (M-series), **NVIDIA cuBLAS** (GPU).

**LAPACK** implements linear algebra algorithms on top of BLAS. LU, QR, SVD, eigenvalues — nearly every matrix problem dissolves into a single LAPACK call. 350K lines of Fortran, polished over 30+ years since the 1992 first release.

**ScaLAPACK** is the distributed-memory version of LAPACK. It runs on MPI and decomposes matrices across hundreds of thousands of supercomputer cores.

**PETSc (Portable Extensible Toolkit for Scientific Computation)** is Argonne National Lab's PDE-solving library. It unifies sparse matrices, nonlinear solvers, time integration, and mesh management. Callable from Fortran and C, it is the backbone of large-scale simulation (CFD, electromagnetics, quantum chemistry).

**Trilinos** is Sandia National Lab's PETSc alternative. More modular and C++-based, but it provides Fortran-compatible interfaces.

**FFTW (Fastest Fourier Transform in the West)** is MIT's FFT library. Its self-tuning algorithm generates hardware-matched code at runtime. Essential in signal processing, astrophysics, and quantum mechanics.

Chapter 8 · Climate Models — NEMO, CESM, ECMWF IFS, CMIP6

Fortran's true kingdom is climate models. Nearly all of the 30+ climate models registered for CMIP6 (Coupled Model Intercomparison Project Phase 6) are written in Fortran.

| --- | --- | --- | --- |

**NEMO (Nucleus for European Modelling of the Ocean)** is the European ocean simulation standard. 500K lines of Fortran 90+, MPI distributed, OpenMP intra-node. Combined with satellite observations and data assimilation, it reproduces real-time ocean states.

**CESM (Community Earth System Model)** is NCAR's comprehensive Earth system model. Composed of atmosphere (CAM), ocean (POP), sea ice (CICE), land (CLM), and coupler (CPL) modules, it exceeds 1.5M lines. The center of the US CMIP6 contribution.

**ECMWF IFS (Integrated Forecasting System)** is the world's most accurate global weather forecast model. Two million lines of Fortran, 8000+ modules, producing forecasts four times daily on Cray supercomputers. As of 2026, IFS 49R3 is the operational production version.

**NICAM (Nonhydrostatic ICosahedral Atmospheric Model)** is RIKEN's icosahedral grid atmospheric model. It runs global simulation at 3.5 km resolution on the Fugaku supercomputer. Symbol of Japan's supercomputer utilization strategy.

Rewriting such code in Python or Julia is unrealistic. Verification, certification, and operational stability took 30+ years to build. Attempts to add partial modules in a new language exist, but the core dynamical kernel stays in Fortran.

Chapter 9 · The Python Scientific Stack — NumPy / SciPy / Pandas / Polars

If Fortran is the *foundation*, Python is the *frontend*. The de facto standard entry point for the 2026 scientific computing workflow is Python.

**NumPy 2.x** (2.0 in 2024, 2.3 in 2026) is the de facto standard for multi-dimensional arrays. Internally it calls LAPACK and BLAS, with decades of optimization condensed into a single ndarray object. A major API cleanup happened in 2.0 (string dtype, scalar promotion changes), and 2.3 is integrating GPU backends.

**SciPy 1.16** (2026) provides scientific computing functions on top of NumPy. Integration, ODE, optimization, signal processing, statistics, sparse matrices, interpolation — it covers nearly every scientific computing area. Its internals are written in Fortran (LAPACK, ODEPACK, MINPACK, FFTPACK) and C.

**Pandas 2.x** (2.0 in 2024, 2.4 in 2026) is the dataframe standard. With 2.0 adopting PyArrow as the backend, performance and memory efficiency improved dramatically. Time-series, categorical, and missing-value handling now surpass R's data.frame.

**Polars 1.x** (1.0 in 2024) is a Pandas alternative written in Rust. Columnar memory, lazy evaluation, automatic parallelism, Apache Arrow native. 5–50x faster than Pandas on large datasets. In 2026 around 1.20 — Pandas-compatible API and GPU backend (cuDF integration) have stabilized.

**NetworkX** (graphs), **scikit-learn** (ML), **statsmodels** (statistics), **xarray** (labeled N-dim arrays, NetCDF-friendly), and **Dask** (distributed NumPy/Pandas) layer on top.

Chapter 10 · JAX, Equinox, Flax — Scientific Computing in the Autodiff Era

**JAX** (Google, 2018) is a library that keeps NumPy's API while adding autodiff and XLA compilation. JAX 0.5/1.0 entered formal stabilization in 2026.

from jax import grad, jit

def loss(x):

return jnp.sum(jnp.sin(x)**2)

grad_loss = jit(grad(loss))

g = grad_loss(jnp.array([1.0, 2.0, 3.0]))

The core features are four transformations.

1. `grad` — automatic differentiation

2. `jit` — XLA compilation

3. `vmap` — automatic vectorization

4. `pmap` — automatic distribution

A function decorated with `@jit` is compiled by XLA and runs as-is on GPU/TPU. It gives the experience of getting 100x speedup without changing a single line of NumPy code.

**Equinox** (ex-Google DeepMind, 2022) adds PyTorch-style model definitions to JAX.

**Flax** (Google, 2020) is JAX's flagship NN framework. It standardizes NN models, training loops, checkpoints, and distribution.

The JAX ecosystem extends beyond ML into scientific computing. **JAX-FEM** (finite elements), **JAX-CFD** (fluid dynamics), and **JAX-MD** (molecular dynamics) are active examples. When autodiff combines with PDE solving, *inverse design optimization* becomes natural — differentiate the input shape to find the geometry that yields the desired output.

Chapter 11 · Numba, Cython, PyPy, Mojo — Four Python Accelerators

Python's weakness is interpreter speed. Four approaches address it.

**Numba** (Anaconda, 2012) is an LLVM-based JIT. A single decorator makes a Python function run at C-level speed.

from numba import njit

@njit

def sum_loop(n):

s = 0.0

for i in range(n):

s += i**2

return s

It pairs well with NumPy and has a CUDA backend. Used more often in scientific computing and simulation than ML.

**Cython** (2007) is an intermediate language between Python and C. A .pyx file with type annotations compiles to a .so binary. Parts of NumPy and the core algorithms of scikit-learn are written in Cython.

**PyPy 7.3** (2026) is a separate JIT Python interpreter. 4–10x faster than CPython but with weaker NumPy/SciPy compatibility. Good for pure-Python business logic.

**Mojo** (Modular, 2023; Chris Lattner) is a new language claiming to be a Python superset. LLVM-based, native SIMD/GPU, optional static typing. 0.7 shipped in 2025 and 1.0 is imminent in 2026. You bring Python code in as-is and gradually add static types to accelerate. Ambition is high but the library ecosystem is thin.

Chapter 12 · Julia 1.11 — The Dynamic-Plus-Fast Promise

**Julia** (2012) launched under the slogan "Walks like Python, runs like C." As of 2026, 1.11 is the LTS, with 1.12 stable in progress.

Julia has four strengths.

1. **LLVM JIT compilation.** A dynamic language with compile-language-level speed.

2. **Multiple dispatch.** Functions have different methods per argument-type combination — natural for scientific computing.

3. **Metaprogramming.** Lisp-level macros make DSL writing easy.

4. **Math-friendly syntax.** Unicode variable names (alpha, beta, gamma), operator overloading.

The ecosystem core is **DifferentialEquations.jl** — the world's best ODE/PDE solver library. Together with SUNDIALS it is the de facto standard. **Flux.jl** (ML), **MLJ.jl** (ML meta-framework), **Symbolics.jl** (symbolic), **Pluto.jl** (reactive notebook), **Plots.jl**, **Makie.jl** (visualization).

**SciML (Scientific Machine Learning)** is Julia's differentiating area. Differential equations + neural networks = "Universal Differential Equations," learning physical laws and data jointly. Julia 1.11 is the de facto standard in this area.

However, Julia's market share is far smaller than Python's. Academic adoption is active but industry adoption remains limited.

Chapter 13 · R 4.5, MATLAB 2026, Mathematica 14 — The Commercial Camp

Beyond open source, commercial tools remain important.

**R 4.5** (2026) is the standard language for statistics. The tidyverse (dplyr, ggplot2, tidyr) ecosystem became standard for data analysis workflow. Posit (formerly RStudio) makes the IDE, cloud service, and Quarto (multi-language notebooks). R 4.5 in 2026 brings ALTREP improvements, parallel BLAS integration, and stabilization of the native pipe `|>`.

**MATLAB R2026a** (MathWorks) is the industry standard for engineering simulation. Simulink is effectively mandatory in automotive, aerospace, and power-system design. The 2026 version introduces MATLAB Copilot (LLM assistant), strengthened GPU Coder, and automatic ROS 2 code generation. The license is expensive but holds industrial certification value.

**Octave 9** (2026) is a near-MATLAB-compatible open source alternative. Sufficient for learning and small-scale research, but lacks Simulink, so areas remain irreplaceable.

**Wolfram Mathematica 14** (2024) is the emperor of symbolic computation. Wolfram Language unifies symbolic, numeric, visualization, and notebooks. LLMFunction officially entered, calling GPT/Claude like functions.

**SageMath 10.4** (2026) is a comprehensive open source CAS bundling SymPy, Maxima, PARI/GP, and GAP. Python-based, so entry is easy.

Chapter 14 · The APL Family — The Extreme of Array Thinking

**APL (A Programming Language)** began with the notation Kenneth Iverson published in 1962. It expresses array operations in special characters (rho, iota, left-arrow, reverse), and the phrase "one line is one page" fits.

"Compute the mean"

mean assignedTo curly{(plusReduce omega) divide tally omega}

mean 1 2 3 4 5

APL is not dead. The 2026 family has actually grown.

| --- | --- | --- | --- |

| J | ASCII | GPL | Iverson successor, free |

| BQN | Unicode | MIT | Modernized, functional |

**Dyalog APL** is the de facto standard commercial APL. Used in finance, insurance, telecom. JetBrains-style IDE support also exists.

**J** (1990) is APL recreated by Iverson in ASCII. Usable without a Unicode keyboard.

**K + kdb+ + q** (Kx Systems) is the de facto standard for financial time-series DBs. q is a SQL-like query language on top of K. Nearly every global bank and HFT firm runs kdb+. Expensive licensing (hundreds of thousands of dollars annually) but irreplaceable.

**BQN (Big Question Notation)** and **Uiua** (2023) are 21st-century APLs. BQN adds the functional paradigm, Uiua is stack-based (Forth-like). Both have active communities.

**Co-dfns** compiles a subset of APL to GPU — possibly the true future of array languages.

The market share of array languages is small but the ideological impact is large. NumPy's broadcasting, Pandas's vectorization, and JAX's functional transformations are all ideas APL showed in 1962.

Chapter 15 · GPU Computing — CUDA / ROCm / oneAPI / Triton / CuPy

In 2026 scientific computing, GPU is no longer a choice but a default.

**CUDA 13** (NVIDIA, 2025) is the de facto standard for GPU computing. CUDA C, CUDA Fortran, CUDA Python (formerly cuda.core), cuBLAS, cuDNN, cuSPARSE, cuSOLVER, cuFFT, and other library stacks. 14 years of optimization and ecosystem.

**ROCm 6.x** (AMD, 2024) is AMD GPU's CUDA alternative. The CUDA-like API called HIP makes code porting relatively easy. The El Capitan (LLNL, AMD MI300) supercomputer is ROCm-based.

**oneAPI** (Intel, 2020) is an Intel GPU programming environment based on the SYCL standard. The Aurora supercomputer (Argonne) uses it.

**Triton** (OpenAI, 2021) is a language for writing GPU kernels in Python. It is higher-level than CUDA and occupies part of the PyTorch backend. Used explosively in learning and research environments.

**CuPy** (Preferred Networks, 2017) is the CUDA replacement for NumPy. A single line `import cupy as np` lifts NumPy code onto GPU.

**OpenACC** is the GPU-friendly cousin of OpenMP. It expresses GPU offload via directives. Pairs best with Fortran and is the workhorse of the NVIDIA HPC Compiler.

The real change in the GPU era is that *the language hides the GPU*. People using JAX, Julia, or CuPy never see what gets launched on GPU; their code runs. Fortran users get automatic GPU offload from a single DO CONCURRENT line.

Chapter 16 · Supercomputers — Fugaku, Nurion, Frontier, El Capitan

**Top500** (announced every June and November) is the supercomputer ranking list. Look at the top of the 2026 machines.

| --- | --- | --- | --- | --- |

**Fugaku** (2020 deployed, Japan RIKEN) is an ARM-based supercomputer that ranked first on Top500 in 2020–2021. Built from 158,976 nodes of Fujitsu A64FX chips (48-core ARM + 512-bit SVE vector). CPU-only it reached 1.4 ExaFLOPS — without GPU. As of 2026 it has dropped to fifth but remains in active operation. The successor "Fugaku-NEXT" is in design with a 2030 target.

**Nurion** (2018, Korea KISTI) is Korea's largest supercomputer, based on Intel Xeon Phi. 25.7 PF placed it 11th on Top500 at deployment. Now further down but the center of domestic weather, bio, and aerospace research. The successor KISTI 6th machine is in deployment in 2026.

**Frontier** (2022, ORNL) is the world's first ExaFLOPS machine. Built from AMD EPYC CPUs and Instinct MI250X GPUs. US base for climate, fusion, and material simulation.

**El Capitan** (2024, LLNL) is the Top500 number-one as of May 2026. Adopting AMD MI300A (APU — integrated CPU + GPU), it achieves 1.74 ExaFLOPS. Primary use: nuclear weapons simulation and climate.

**Aurora** (2024, Argonne) is based on Intel Max GPU. The primary target is AI/HPC fusion workloads.

The overwhelming majority of code running on these machines is Fortran or C++. Supercomputer time trades at tens of thousands of dollars per hour, making "1% performance improvement" enormously valuable. That is why dedicated compilers from Cray, Fujitsu, and NVIDIA survive.

Chapter 17 · Supercomputer Management — Slurm / PBS Pro / LSF / Spack

Supercomputer users usually do not run the machine *directly*. They submit jobs to a queue system and receive results.

**Slurm** (SchedMD, 2003) is the most widely used open source job scheduler. Over 60% of Top500 machines use Slurm.

#!/bin/bash

#SBATCH --job-name=climate_run

#SBATCH --nodes=128

#SBATCH --ntasks-per-node=64

#SBATCH --time=24:00:00

#SBATCH --partition=large

mpirun -n 8192 ./nemo.exe

`sbatch script.sh` submits, `squeue` checks the queue, `scancel` cancels.

**PBS Pro** (Altair) and **LSF** (IBM) are the commercial alternatives. Many older supercomputers run PBS or LSF.

**Spack** (LLNL, 2013) is the HPC environment package manager. Unlike apt/yum, it can install multiple versions and compiler combinations of the same library side by side.

$ spack install petsc@3.19.0 +mpi ^openmpi@4.1.5 %gcc@13.2.0

PETSc 3.19, MPI backend, OpenMPI 4.1.5, built with GCC 13.2.0. On the same system you can also install a PETSc 3.20 / Intel MPI / ifx build separately. Essential for supercomputer operators.

**Easybuild** (KU Leuven, Belgium) is the European competitor to Spack.

Chapter 18 · Scientific Data Formats — HDF5 / NetCDF / FITS / MAT

Large scientific data cannot live in CSV or JSON. Four formats are standard.

**HDF5 (Hierarchical Data Format 5)** is NCSA's self-describing binary format. It holds datasets and metadata in a tree structure and supports compression, chunking, and parallel I/O. Standard in astrophysics, climate, and life sciences.

**NetCDF (Network Common Data Form)** is UCAR's standard format for climate and ocean data. From NetCDF 4 onward it runs on top of HDF5. All model outputs from ECMWF, NCAR, and NOAA are NetCDF.

**FITS (Flexible Image Transport System)** is astronomy's standard format. Standardized in 1981, NASA, ESA, and JWST all distribute data in FITS.

**MAT (MATLAB files)** is MATLAB's native binary. From v7.3 onward it is HDF5-based. SciPy's `scipy.io.loadmat` reads it from Python.

**Apache Parquet** and **Apache Arrow** are big-data camp standards, but NetCDF/HDF5 still dominate scientific computing.

**Zarr** (2018) is a cloud-friendly alternative to NetCDF/HDF5. It stores chunks as S3 objects distributedly, suited for distributed analysis. Combined with xarray.

Chapter 19 · Mojo, LFortran, Next-Generation Scientific Languages

Entering the late 2020s, three candidates have emerged for *next-generation* scientific computing languages.

**Mojo** (Modular, 2023) is by Chris Lattner (creator of LLVM/Swift). It claims to be a Python superset and supports SIMD/GPU natively on LLVM/MLIR. 1.0 is imminent in 2026. Ambition: "Python's usability + C++'s performance + Fortran's array operations."

**LFortran** (2022) is, as seen in Chapter 6, Fortran's IPython moment.

**Bend** (2024) is a GPU-friendly functional language. It automatically parallelizes CPU code to GPU. Still experimental but shows the possibility of a paradigm shift.

Julia 1.x remains a candidate. By locking ABI from 1.11 onward, it is lowering the last barrier to industrial adoption.

The chance that one of these *replaces* Fortran is low. But the chance that one becomes the default for *new scientific projects* exists. The landscape 5–10 years from now will look meaningfully different.

Chapter 20 · Quantum Computing and Science — Qiskit / Cirq / PennyLane

Quantum computers are still at the NISQ (noisy intermediate-scale) stage, but meaningful results are emerging in scientific simulation.

**Qiskit** (IBM) is a Python-based quantum SDK. It uses IBM Quantum hardware (127–1121 qubits) via cloud. Chemistry simulation, optimization, and ML are the main applications.

**Cirq** (Google) uses Sycamore and Willow (105 qubit, 2024) hardware. The tool of the quantum supremacy experiments.

**PennyLane** (Xanadu) is a quantum-ML-specialized framework. Integrates with PyTorch and JAX.

The contact point between quantum computing and Fortran is *classical simulators*. When simulating quantum circuits on classical computers, the core operation is tensor contraction, which is ultimately a BLAS gemm call. Cray, NVIDIA, and Intel quantum simulator backends all depend on BLAS/LAPACK.

This subject is covered more deeply in a separate post. Here we only note that quantum computing also stands on top of *numerical linear algebra*.

Chapter 21 · Korea and Japan in Scientific Computing — KISTI / RIKEN / AIST

**KISTI (Korea Institute of Science and Technology Information)** operates Korea's supercomputers. It runs Nurion (5th machine, 25.7 PF) and Tachyon2 and is deploying the 6th machine in 2026. Korea Meteorological Administration's KIM model and KSTAR fusion simulations run at KISTI.

**Seoul National University Supercomputer** is operated separately. NVIDIA DGX clusters with InfiniBand. AI research is the main workload.

**KAIST**, **GIST**, and **UNIST** each operate their own supercomputer resources.

**RIKEN (Institute of Physical and Chemical Research)** is Japan's flagship science institute. It operates Fugaku, running NICAM climate models, MD simulations, and quantum simulation. The next-generation Fugaku-NEXT targeted for 2030 deployment is being designed.

**AIST (National Institute of Advanced Industrial Science and Technology)** is Japan's applied science research institute. It operates the ABCI (AI Bridging Cloud Infrastructure) supercomputer for AI/HPC fusion workloads. ABCI 3.0 entered operation in 2024.

**JAMSTEC (Japan Agency for Marine-Earth Science and Technology)** operates Earth Simulator. 1st gen (2002), 2nd (2009), 3rd (2015), 4th (2021) — NEC SX-Aurora TSUBASA vector machines, keeping Japan's vector-computing tradition alive.

Korea and Japan share deep traditions in scientific computing. Japan's vector-computer tradition (Earth Simulator, Fugaku) contrasts with Korea's GPU/AI pivot.

Chapter 22 · Notebook Environments — Jupyter / Quarto / Marimo / Pluto

The daily tool of scientific computing is the notebook. The 2026 landscape.

**Jupyter** (2014, formerly IPython) is the de facto standard. It supports 40+ kernels including Python, Julia, R, Fortran (LFortran), Scala. JupyterLab 4.x is the next-generation interface.

**Quarto** (Posit, 2022) is the successor to R Markdown. It produces multi-language documents in Python/R/Julia/JS as PDF/HTML/Word/EPUB. Quarto Manuscripts targets academic paper writing.

**Marimo** (2023) is a reactive Python notebook. Like Pluto.jl, it auto-tracks cell dependencies and saves as a .py file. Git diffs work well and reproducibility is strong.

**Pluto.jl** (2020) is Julia's reactive notebook. Changing one cell automatically re-executes all dependent cells. Strong for education and demos.

**Deepnote**, **Hex**, and **Noteable** are cloud notebook services. Strong on collaboration and SQL/Python integration.

This subject is covered more deeply in a separate notebook post.

Chapter 23 · Scientific Computing Learning Paths — Student / Researcher / Engineer

Finally, let's summarize who should learn what.

**Undergraduates**:

1. Python + NumPy + Matplotlib (basic tools)

2. Jupyter notebook (working environment)

3. Git/GitHub (collaboration)

4. Linear algebra and numerical analysis (theory)

5. Add one of R/Julia/MATLAB by area of interest

**Graduate Students (MSc/PhD)**:

1. Undergrad + SciPy + scikit-learn (applied)

2. PyTorch or JAX (autodiff)

3. Domain-specific libraries (e.g., Astropy for astrophysics)

4. HPC usage (SLURM, Spack)

5. Fortran *reading* skill (understanding existing code)

**Climate / Ocean Researchers**:

1. Fortran *writing* skill required

2. NetCDF/HDF5/xarray

3. Understanding of operational models like NEMO/CESM/IFS

4. MPI/OpenMP parallelization

5. Cray/Intel compiler usage

**Engineers (Simulation)**:

1. MATLAB + Simulink (de facto standard)

2. ANSYS/ABAQUS/COMSOL (commercial tools)

3. Python auxiliary (data processing)

4. Some Fortran (legacy solvers)

**Data Scientists**:

1. Python + Pandas + Polars

2. SQL proficiency

3. scikit-learn to PyTorch/JAX

4. Cloud notebooks (Hex, Deepnote)

5. R optional for statistics

The core is *to keep Python as the base* and add Fortran/Julia/R/MATLAB as the area demands. The era of doing everything with one tool is over.

Chapter 24 · Frequently Asked Questions — Q&A

**Q. Is it worth learning Fortran fresh in 2026?**

A. If you are *starting a new project*, Julia or Python is preferable. However, climate, high-energy physics, and HPC researchers need Fortran *reading* skill. You must be able to understand million-line operational models.

**Q. Is NumPy/SciPy slower than Fortran?**

A. Not a one-to-one comparison, but NumPy's internals are ultimately Fortran (LAPACK) and C (BLAS). If your code is mostly NumPy function calls, the speed is comparable to Fortran. If it is mostly Python for-loops, it is 100x slower. Numba/Cython can accelerate those parts.

**Q. Will Julia replace Fortran?**

A. Not in the short term. The cost of operational code rewrites is too high. Long term, Julia may take a substantial portion of new projects.

**Q. When will LFortran be production-ready?**

A. As of May 2026, LFortran is beta. At the earliest 2027, at the latest 2028 to 2029, it will reach production level.

**Q. What about Mojo?**

A. Ambition is high but the library ecosystem is thin. Even after 1.0 ships, accumulating NumPy/SciPy-level assets takes 5 to 10 years.

**Q. Is APL really usable?**

A. *Financial HFT* — K/q is the de facto standard. Otherwise, ideological interest dominates. NumPy users who absorb APL's mental model write more elegant NumPy code.

Chapter 25 · Conclusion — Fortran's Paradox and the Future of Scientific Computing

Fortran's biggest paradox is this. **"The oldest high-level language remains one of the fastest languages."**

The answer to this paradox is simple. Fortran was designed *from the start to be good at a specific problem* — array operations. Over 70 years it got better. C was designed to be good at systems programming, and Python was designed to be good at usability. Each is supreme in its own area.

2026 scientific computing is the era of *language diversity*. Fortran stays as the bedrock of operational models, Python takes the frontend, Julia aims at new projects, and JAX fuses ML and science. APL lives as thought, MATLAB lives as industry, R lives as statistics.

I hope this essay has been a map of that entire terrain. A final action call. **(1)** If you already have a tool, dig deeper into it. Add new tools cautiously. **(2)** Python + NumPy is a *common vocabulary*. In any area, this is one you must know. **(3)** Even if you do not *write* Fortran, learn to *read* it — half of scientific computing libraries ultimately start in Fortran. **(4)** Observe newcomers like Julia/JAX/Mojo. We do not yet know whether they become standard or die in 5 years.

Climate changes, particle accelerators run, supercomputers push past ExaFLOPS. As long as compiled array operations spin behind all of that, Fortran's children will keep working. Fortran does not die — it simply survives *by changing form*.

References

1. Fortran 2023 Standard (ISO/IEC 1539:2023): https://www.iso.org/standard/82170.html

2. fortran-lang.org community hub: https://fortran-lang.org/

3. LFortran project: https://lfortran.org/

4. gfortran (GCC): https://gcc.gnu.org/fortran/

5. LLVM Flang: https://flang.llvm.org/

6. NVIDIA HPC SDK: https://developer.nvidia.com/hpc-sdk

7. Intel ifx / oneAPI: https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html

8. Fortran Package Manager (fpm): https://fpm.fortran-lang.org/

9. Fortran stdlib: https://stdlib.fortran-lang.org/

10. OpenMP 5.2 specification: https://www.openmp.org/specifications/

11. MPI 4.1 documents: https://www.mpi-forum.org/docs/

12. LAPACK: https://www.netlib.org/lapack/

13. BLAS: https://www.netlib.org/blas/

14. PETSc: https://petsc.org/release/

15. NumPy 2.x docs: https://numpy.org/doc/stable/

16. SciPy docs: https://docs.scipy.org/doc/scipy/

17. JAX docs: https://docs.jax.dev/

18. Julia 1.11 docs: https://docs.julialang.org/en/v1/

19. Top500 November 2025 list: https://top500.org/lists/top500/2025/11/

20. RIKEN Fugaku: https://www.r-ccs.riken.jp/en/fugaku/

21. KISTI supercomputer: https://www.ksc.re.kr/eng

22. ECMWF IFS: https://www.ecmwf.int/en/forecasts/documentation-and-support

23. NCAR CESM: https://www.cesm.ucar.edu/

24. CMIP6: https://www.wcrp-climate.org/wgcm-cmip/wgcm-cmip6

25. APL Wiki: https://aplwiki.com/

26. Modular Mojo: https://docs.modular.com/mojo/

27. HDF5: https://www.hdfgroup.org/solutions/hdf5/

28. NetCDF: https://www.unidata.ucar.edu/software/netcdf/

Last updated: 2026-05-16. The next essay will deep-dive into one area touched in this map — *climate model code at the codebase level*.