Tapenade: Source-to-Source AD Tool

• Tapenade is a source-to-source AD tool that parses scientific Fortran code to automatically generate tangent-linear and adjoint models for sensitivity analysis and optimization.
• It employs source-transformation methods with integrated checkpointing strategies to manage memory tradeoffs and ensure consistency between primal and derivative codes.
• The tool has been validated in diverse fields such as ocean modeling, CFD, and nuclear EDF solvers, demonstrating its practical impact in high-performance computing applications.

Searching arXiv for recent and foundational papers on Tapenade and its applications. Tapenade is a source-to-source automatic differentiation (AD) tool centered on the generation of tangent-linear and adjoint codes from scientific programs, especially large Fortran code bases. Across the literature, it appears both as an AD compiler in its own right and as a reference point for source-transformation workflows involving checkpointing, generated derivative kernels, and differentiated high-performance computing applications. The published record portrays Tapenade as particularly important in reverse-mode settings where gradients, tangent-linear models, or discrete adjoints are required for variational data assimilation, sensitivity analysis, Jacobian construction, optimization, and uncertainty quantification (Siskind et al., 2016, Gaikwad et al., 2024, 0711.4444).

1. Definition and computational model

Tapenade is described as a source-transformation AD tool that parses source code and emits derivative-augmented code rather than relying on operator overloading at runtime. In a comparative discussion of AD paradigms, source transformation tools “like Tapenade or OpenAD” are characterized as tools that “apply AD by parsing the source code of the program and generating a new code extending it by the additional AD computations” (Sagebaum et al., 2023). In the OPA formulation, a program computing

$F : X \in I^m \mapsto Y \in I^n$

is decomposed into elementary operations, and Tapenade generates either tangent code computing Jacobian-vector products or adjoint code computing transposed-Jacobian products (0711.4444).

The tangent-linear and adjoint contracts recur across applications. In one general formulation,

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$

and

$\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$

This notation is used to explain function-level forward and reverse derivative interfaces in CoDiPack external functions, where Tapenade is named as a canonical source-transformation tool (Sagebaum et al., 2023). The same mathematical structure underlies large geophysical and CFD applications: the MITgcm paper writes the nonlinear model as

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$

with a scalar objective

$$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$

and then defines tangent-linear propagation and adjoint backpropagation through timestep operators $L_n$ (Gaikwad et al., 2024).

The practical significance of this model is that Tapenade generates derivative code at the level of the implemented discrete program. In the gas-kinetic scheme work, Tapenade is used to construct a discrete adjoint rather than a continuous adjoint, with the stated aim of ensuring strict consistency between the primal discretization and the adjoint discretization (Wu et al., 12 Jun 2026). This suggests that Tapenade’s central identity in the literature is not merely “an AD tool,” but a compiler for discrete derivative programs tied to the actual source implementation.

2. Differentiation modes, interfaces, and numerical products

Tapenade is used for both tangent and adjoint generation, although mode choice depends on the input–output dimensions and application structure. In OPA, Tapenade generated both tangent and adjoint codes for a very large FORTRAN95 ocean model (0711.4444). In ORCA-2/NEMO, the same dual role is explicit: “tangent and adjoint codes have been obtained by Tapenade software” (Kazantsev, 2012). In HFBTHO-AD, by contrast, the implementation uses forward mode and vector forward mode because there are 14 inputs and 52 outputs, so forward mode is the chosen efficiency point for the Jacobian of interest (Hascoët et al., 16 Aug 2025).

The generated interfaces are concrete. In the parallel CFD study, a head routine

$\texttt{TopSub}(X,Y)$

is transformed into

$\texttt{TopSub\_d}(X, Xd, Y, Yd)$

for tangent mode and

$\texttt{TopSub\_b}(X, Xb, Y, Yb)$

for adjoint mode (Cardesa et al., 2019). In CoDiPack external functions, Tapenade-generated or Enzyme-generated routines are expected to satisfy interfaces of the form:

$$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$6

These interfaces encode the forward and reverse AD maps directly (Sagebaum et al., 2023).

A recurring numerical product is the full gradient of a scalar objective with respect to a high-dimensional control vector. In the MITgcm exposition,

$$\delta J = \left\langle \frac{\partial J}{\partial u}, \delta u \right\rangle$$

is obtained by adjoint backpropagation through

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$0

This is the formal basis for gradient-based sensitivity analysis, attribution, state estimation, and uncertainty quantification (Gaikwad et al., 2024). In HFBTHO-AD, the central differentiated object is instead the Jacobian $\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$1 of a residual map, from which

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$2

is formed for optimization and covariance analysis (Hascoët et al., 16 Aug 2025).

This diversity of targets indicates that Tapenade’s outputs are not restricted to one style of derivative product. The literature covers Jacobian-vector products, transposed-Jacobian products, full Jacobians via vector forward mode, tangent-linear models, adjoint models, and discrete adjoint operators (Hascoët et al., 16 Aug 2025, 0711.4444, Gaikwad et al., 2024).

3. Checkpointing and reverse-mode memory tradeoffs

Checkpointing is one of the most persistent themes in the Tapenade literature. Before trace-based binomial checkpointing for arbitrary programs was proposed, systems “like Tapenade” already provided automatic checkpointing at procedure-call boundaries in reverse mode (Siskind et al., 2016). Tapenade also supported a more specialized binomial-checkpointing mechanism through user-provided pragmas on DO loops (Siskind et al., 2016). The same paper treats this as an important but limited capability because checkpoint placement remained tied to source syntax rather than to the dynamic sequence of primitive computations.

The distinction is precise. Tapenade’s existing checkpoint placement was constrained to syntactic constructs: procedure-call boundaries or DO loops designated by pragmas. The critique is that optimal binomial scheduling is defined over the dynamic sequence of primitive computations, and data-dependent execution costs “not even statically determinable” can defeat syntax-aligned checkpoint placement (Siskind et al., 2016). On the irregular nested-loop benchmark discussed there, Tapenade exhibits $\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$3 space and time usage for all tested strategies, including no checkpointing, manual checkpointing around the outer loop only, manual checkpointing around the inner loop only, manual checkpointing around both loops, and binomial checkpointing (Siskind et al., 2016).

Another line of work shows Tapenade as a vehicle for practical checkpointing rather than as the object of critique. In OPA, the authors implemented Griewank and Walther’s binomial checkpointing algorithm around Tapenade-generated adjoints. They report, for example, that for 64 timesteps and 9 snapshots, a multi-level recursive strategy yields average duplicate executions per timestep of 2.25 whereas optimal binomial checkpointing yields 2.0; for 1000 timesteps and 27 snapshots, the corresponding values are 2.7 and 2.57 (0711.4444). In a one-year sensitivity experiment on 5475 timesteps, the Tapenade-generated adjoint computed the sensitivity map in 8.03 times the runtime of the original simulation (0711.4444).

MITgcm-AD v2 presents a later, production-scale checkpointing comparison. There, TAF uses a highly tuned static $\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$4-level checkpointing strategy, with $\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$5 by default, while Tapenade uses binomial checkpointing based on the classic Revolve approach (Gaikwad et al., 2024). The paper states the optimality recurrence

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$6

with boundary conditions

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$7

and explicit solution

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$8

where

$\dot y = \frac{d F}{d x}(x) \dot x \tag{1}$9

Tapenade supports this built in, requiring only a preprocessing directive on the time loop (Gaikwad et al., 2024).

A further MPI-parallel study combines Tapenade with Adjoinable MPI and binomial checkpointing for a solver with about $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$0 explicit time steps (Cardesa et al., 2019). For a viscous case with

$\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$1

timesteps and 80 snapshots, Tapenade’s binomial scheme induces an average of 3.9 extra recomputations per time step, and the total normalized runtime of the adjoint code is 15.4 times the primal runtime (Cardesa et al., 2019). This makes clear that Tapenade’s checkpointing relevance spans serial, large-scale oceanic, and MPI-parallel CFD settings.

4. Role in large-scale scientific models and HPC codes

Tapenade has been used in several large scientific computing domains, and the applications collectively define its practical reputation.

Geophysical circulation and data assimilation

In MITgcm-AD v2, Tapenade is the source-to-source AD tool underpinning an open-source tangent-linear and adjoint modeling framework for MITgcm (Gaikwad et al., 2024). The framework was integrated into the MITgcm main branch, with genmake2 modified so that generated Makefiles can invoke Tapenade and track differentiated-file dependencies. Build targets tap_adj and tap_tlm produce the adjoint and tangent-linear executables, respectively (Gaikwad et al., 2024). The paper reports compatibility with 10 tutorial/verification experiments and 25 MITgcm packages, including cost, ctrl, ecco, profiles, seaice, dic, ggl90, gmredi, kpp, streamice, ptracers, and diagnostics (Gaikwad et al., 2024).

The ORCA-2/NEMO study uses Tapenade to generate the tangent and adjoint machinery needed for 4D-Var data assimilation with controls extending beyond initial conditions to horizontal boundary discretization coefficients $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$2, vertical boundary discretization coefficients $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$3, and vertical diffusion coefficients $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$4 (Kazantsev, 2012). The paper emphasizes that derivatives with respect to internal parameters such as boundary-condition coefficients are much more complex than classical initial-condition derivatives, which is why Tapenade is described as avoiding “huge coding and debugging work” (Kazantsev, 2012).

OPA provides an earlier but foundational ocean-model case study. After OPA migrated to FORTRAN95, the old hand-written adjoint became obsolete; Tapenade was then used to rebuild tangent and adjoint codes mechanically for OPA 9 (0711.4444). The full OPA code base is described as about 200 modules, 800 procedures, and over 100,000 lines of FORTRAN95, with a differentiated computational kernel covering 330 procedures (0711.4444).

CFD, discrete adjoints, and optimization

In the implicit discrete adjoint gas-kinetic scheme, Tapenade is the source-transformation engine that generates the discrete adjoint code for the GKS solver (Wu et al., 12 Jun 2026). The paper poses the optimization problem as

$\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$5

subject to

$\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$6

with the discrete adjoint system

$\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$7

Tapenade is used because manual derivation of the adjoint for the GKS flux construction is nontrivial and because the authors want strict consistency between primal and adjoint discretizations (Wu et al., 12 Jun 2026).

The JAGUAR study differentiates a parallel CFD solver for time-dependent PDEs using Tapenade in both tangent and adjoint modes, with two stated novelties: automatic inversion of the complete MPI communication layer and adjointing an explicit time integration loop running for ca. $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$8 time steps (Cardesa et al., 2019). The workflow combines Tapenade with Adjoinable MPI and binomial checkpointing, demonstrating that source-transformed derivatives can extend to a large parallel solver when communication and time integration are treated explicitly (Cardesa et al., 2019).

Nuclear EDF solvers and uncertainty quantification

HFBTHO-AD uses Tapenade to differentiate a nuclear energy density functional solver so that derivative-based optimization, sensitivity analysis, and uncertainty quantification become feasible (Hascoët et al., 16 Aug 2025). The top-level differentiated routine is HFBTHO_DFT_SOLVER. The independent variables are 14 EDF parameters—RHO_NM, E_NM, K_NM, ASS_NM, LASS_NM, SMASS_NM, and the two-component arrays CrDr, CpV0, CrDJ, CJ—and the dependent variables are the 52 outputs in eresu and ala2 (Hascoët et al., 16 Aug 2025). This application is notable because it shows Tapenade being integrated into an existing build system and embedded within a two-level architecture: an inner differentiated HFBTHO executable and an outer Python+MPI layer assembling residuals and Jacobians over 72 nuclei (Hascoët et al., 16 Aug 2025).

Finite element Jacobians

In finite element software, Tapenade has been used to automate Jacobian calculation for nonlinear Newton solves (Zwicke et al., 2017). The authors differentiate element-level residual routines rather than global assembly, producing dense element Jacobians $\bar x = \frac{d F}{d x}^\top(x) \bar y. \tag{2}$9 that are then assembled into the global sparse Jacobian via

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$0

This architectural choice leverages FE sparsity structure without asking Tapenade to generate sparse global assembly logic (Zwicke et al., 2017).

5. Integration patterns, software engineering, and code adaptation

Tapenade is repeatedly presented as effective but not frictionless. The engineering patterns needed to deploy it are a major part of the literature.

A common pattern is explicit integration into the host build system. MITgcm-AD v2 modified genmake2, added a code_tap directory as the Tapenade analogue of code_ad, and introduced build targets tap_adj and tap_tlm (Gaikwad et al., 2024). HFBTHO-AD integrated Tapenade into the existing HFBTHO build system through Makefile rules, a dedicated src/hfbtho_ad/MakefileTap, and an AD-enabled executable in hfbtho_ad/ (Hascoët et al., 16 Aug 2025). The finite element Jacobian study constructed a full source-processing workflow around Tapenade: Fortran preprocessor, custom preprocess script, Tapenade, optional midprocess script, postprocess script, and compiler (Zwicke et al., 2017).

Legacy-language and library issues are prominent. OPA required extending Tapenade’s internal representation to handle FORTRAN95 modules, private entities, interfaces, array notation, pointers, and dynamic memory (0711.4444). The finite element code required workarounds for Cray pointers, min/max intrinsic calls with many arguments, assumed-size array initialization, fixed-form versus free-form syntax, and unsupported newer-standard statements (Zwicke et al., 2017). HFBTHO-AD required preprocessing BLAS/LAPACK Fortran77 sources into a Fortran90-compatible form, concatenating all required library files into one file, and manually adapting routines such as dlagts.f, dlarfg.f, dsyevr.f, and dlanst.f (Hascoët et al., 16 Aug 2025).

Another recurring pattern is selective manual handling of numerically delicate kernels. In HFBTHO-AD, DSYEVR is not differentiated through its implementation; instead, a hand-coded forward-mode rule is supplied: $$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$1

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$2

with

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$3

The rationale is that differentiating a finitely terminated iterative eigensolver can be mathematically inappropriate (Hascoët et al., 16 Aug 2025). OPA reports an analogous issue for the preconditioned conjugate gradient solver: direct AD through PCG produced derivatives that became completely wrong after about 80 timesteps, so the authors used Tapenade’s black-box facility and differentiated the underlying linear solve mathematically rather than instruction by instruction (0711.4444).

The literature therefore does not present Tapenade as a universal black box. A consistent message is that source transformation works best when combined with explicit decisions about wrappers, flow directives, build integration, and higher-level derivative rules for difficult interfaces (Gaikwad et al., 2024, Hascoët et al., 16 Aug 2025, Zwicke et al., 2017).

6. Performance, validation, and limitations

Performance claims about Tapenade are context-dependent and often tied to checkpointing, tape growth, or generated-code overhead rather than to AD theory alone.

In MITgcm-AD v2, the Tapenade adjoint is reported as about 2–7 times slower than the TAF adjoint. The paper attributes this mainly to more aggressive checkpointing and recomputation at procedure calls, while also emphasizing that the reported Tapenade version had no performance tuning and that selective directives telling Tapenade not to checkpoint certain calls can yield speedups of 2x or more (Gaikwad et al., 2024). Example timings include global_with_exf, where forward runtime is 4.0 s, TAF adjoint 15.8 s, and Tapenade adjoint 35.4 s, and global_ocean.cs32x15, where forward runtime is 30.7 s, TAF 173.4 s, and Tapenade 1112.2 s (Gaikwad et al., 2024).

In HFBTHO-AD, walltimes for residual plus Jacobian evaluation show AD somewhat slower than finite differences in raw walltime but substantially better in core-hours. For example, at UNEDFpre,

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$4

with average ratios of about 15.47 for FD and 17.89 for AD relative to residual-only evaluation. However, AD / residual is about 8.94 in core-hours, versus about 15.47 for FD / residual, and the FD timings do not include the expensive ECNoise procedure used to determine reliable finite-difference steps $$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$5 (Hascoët et al., 16 Aug 2025). This suggests that resource usage and end-to-end workflow cost can favor Tapenade even when raw walltime does not.

The finite element Jacobian paper reports that the AD-generated Jacobian is much slower than a manual Jacobian but can be improved substantially by exploiting FE structure. Matrix calculation runtimes show, for example, on Mesh 48: manual derivative 0.98 s, unoptimized automatic derivative 13.27 s, and “separation by degree of freedom” 7.04 s; the optimization yields about a 46% speedup (Zwicke et al., 2017).

Validation methods are correspondingly varied. Ocean-model work uses divided differences and identical twin experiments. In OPA, on a complete 1000-timestep global ORCA-2 simulation, the reported values are

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$6

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$7

$$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$8

showing very close tangent–adjoint agreement and the expected finite-difference discrepancy (0711.4444). MITgcm-AD v2 compares Tapenade gradients against finite differences and TAF-based gradients, reporting finite-difference values around $$M : \mathbb{R}^N \ni u \mapsto M(u) = x \in \mathbb{R}^M , \tag{1}$$9 with TAF and Tapenade errors on the order of $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$0 to $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$1 in one example (Gaikwad et al., 2024). The gas-kinetic adjoint work validates sensitivities against finite differences across subsonic, transonic, supersonic, and hypersonic cases and reports good or excellent agreement (Wu et al., 12 Jun 2026). HFBTHO-AD compares Jacobians across compiler configurations and against finite differences, while also showing a concrete case where AD gives derivative $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$2 and FD gives derivative $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$3 because of deterministic computational noise in the primal solver (Hascoët et al., 16 Aug 2025).

Several limitations are recurrent. Reverse-mode memory can be prohibitive without optimization. In ORCA-2, automatically generated adjoints require substantial memory because the forward trajectory must be available during backward integration; the authors reduced memory by a factor of 25 through specific optimizations, making a 10-day assimilation window fit in 640 MB (Kazantsev, 2012). Tapenade-generated OpenMP derivative code can preserve parallelism, but reverse mode often scales worse than the input programs because primal shared reads become adjoint shared increments, forcing atomics or reductions (Hückelheim et al., 2021). Dynamic allocation support was only partial in OPA: handled in tangent mode, not generally in adjoint mode (0711.4444). MPI differentiation in the JAGUAR study required replacing raw MPI with Adjoinable MPI wrappers, rewriting unsupported persistent communications, manually providing communication-style metadata, and manually inserting ADTOOL_AMPI_Turn at the forward/reverse turning point (Cardesa et al., 2019).

A broader misconception addressed implicitly across papers is that AD-generated code is automatically the derivative of the mathematical model one intended. The finite element paper shows that if a matrix exponential implementation returns the identity for $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$4, AD differentiates that branch and yields a zero derivative, even though the mathematical derivative of $$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$5 at zero is not zero (Zwicke et al., 2017). This suggests that Tapenade differentiates the implemented algorithm and branch structure, not an abstract symbolic formulation.

7. Position in the AD ecosystem

The literature consistently positions Tapenade as a representative and influential source-transformation AD system. In work on hybrid operator-overloading/source-transformation workflows, Tapenade appears as the canonical example of a source-transformation tool that automates derivative generation and reduces the burden of manually implementing custom derivative kernels (Sagebaum et al., 2023). In that benchmarking context, Tapenade-generated derivatives on a Burgers loop yield similar qualitative memory and runtime improvements to Enzyme-generated derivatives when inserted as CoDiPack external functions (Sagebaum et al., 2023).

At the same time, some later work uses Tapenade as a foil to motivate more general runtime-level checkpointing. The binomial-checkpointing paper portrays Tapenade as an important prior system for reverse-mode checkpointing, but limited by checkpoint placement at procedure-call boundaries and user-provided DO-loop pragmas (Siskind et al., 2016). The contrast is not that Tapenade lacks checkpointing, but that its checkpointing remains syntax-driven rather than trace-driven (Siskind et al., 2016).

Tapenade is also a platform for research extensions. The OpenMP work extends Tapenade so that it can generate correct derivative code for parallel worksharing loops in forward and reverse mode, including threadprivate stacks, schedule recording, schedule replay, OpenMP-aware scoping rules, and a user override directive of the form:

$$J : \mathbb{R}^N \ni u \mapsto J(M(u)) = J(x) \in \mathbb{R}, \tag{2}$$7

(Hückelheim et al., 2021). This places Tapenade not only as an application tool but as a vehicle for methodological work on differentiating contemporary shared-memory parallel programs.

Across these papers, Tapenade occupies a distinct niche: a mature source-transformation AD system used directly in oceanography, climate modeling, CFD, nuclear physics, and finite elements; a practical baseline in discussions of generated derivative code; and a reference architecture against which newer ideas about arbitrary-program checkpointing or hybrid AD integration are formulated (0711.4444, Gaikwad et al., 2024, Cardesa et al., 2019, Sagebaum et al., 2023, Siskind et al., 2016). A plausible implication is that Tapenade’s historical importance derives less from any single algorithmic novelty than from its sustained role in making differentiated scientific software operational at scale.