Pith. sign in

REVIEW 4 major objections 6 minor 9 references

A deterministic transpiler can move Fortran code to NumPy and JAX while preserving numerical fidelity.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-04 01:10 UTC pith:KTZPS2XP

load-bearing objection A promising, reproducible Fortran->NumPy/JAX transpiler with solid forward results on one 15k-line hydrology module, but the abstract overclaims differentiability and general-purpose coverage. the 4 major comments →

arxiv 2608.00130 v1 pith:KTZPS2XP submitted 2026-07-31 cs.PL cs.AIcs.CLcs.MScs.SE

A Fortran General-Purpose Transpiler: Proof of Concept

Shivamshan Sivanesan , Kazem Ardaneh This is my paper
classification cs.PL cs.AIcs.CLcs.MScs.SE MSC 68N20
keywords FortranPythontranspilersource-to-source compilerJAXNumPyautomatic differentiationhigh performance computing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

FGPT is a compiler-style transpiler that claims to modernize legacy Fortran deterministically, replacing the probabilistic output of LLM-based translators. It parses the source, isolates each target procedure along with its module dependencies, and then lowers the code through two AST stages: first to NumPy, then to JAX-compatible modules. The paper's central claim is that this pipeline preserves numerical fidelity: on the large hydrology module of a land-surface model, outputs agree with the original Fortran to roughly 1e-9 for NumPy and at or below 1e-14 for JAX, while the JIT-compiled JAX version runs about 3.66x faster than the Fortran reference on the main routine. The paper is explicit about current limits: automatic differentiation interfaces (grad/jvp/vjp) are not yet generated, gradient correctness is not yet measured, and Fortran pointers, derived types, and interface blocks are unsupported.

Core claim

On its own terms, the paper establishes that source-to-source translation of Fortran can be staged as a deterministic pipeline: dependency-aware procedure isolation produces standalone compilation units with reference inputs and outputs; a first lowering pass rewrites Fortran ASTs into NumPy ASTs using a control stack and nesting counters; corrective passes restore one-based indexing and global-name resolution; a JAX converter then classifies loops and conditionals, vectorizes along a user-specified axis, and lowers remaining control flow to functional primitives such as scan and cond; an auto-differentiation pass restructures the class as a JAX-compatible PyTree with functional updates. The

What carries the argument

The carrying mechanism is an AST-based two-stage rewrite pipeline. An isolation stage (comprising six components) resolves inter-module dependencies and reconstructs each procedure's execution context so every translation unit can be validated alone. A first transpiler stage reconstructs Python control flow using two last-in-first-out stacks and nesting counters for IF/ELSEIF/WHERE/CASE, then applies local rewrite rules for loop bounds, array dimensions, and intrinsic functions. A second stage converts the generated NumPy AST into a JAX-traceable form: it classifies loops and conditionals, vectorizes along a user-supplied axis, rewrites outer constructs before inner bodies (outer-to-inner re

Load-bearing premise

The entire numerical-fidelity and correctness argument rests on the assumption that the reference input–output pairs generated once per isolated procedure exercise every construct and control-flow path that matters, so agreement on those cases implies semantic preservation for all runs; the paper provides no coverage metric or formal proof.

What would settle it

Run a translated JAX or NumPy procedure on an input that exercises a branch absent from the paper's reference set—for example, a masked WHERE branch, a zero-length dimension, or an ELSE branch with extreme values—and compare against the Fortran oracle. If the maximum absolute deviation exceeds the validation tolerances on any such path, the semantic-preservation claim fails. A more targeted check: feed the transpiler a pointer or derived-type argument, which the paper itself lists as unsupported; if it accepts the code and silently miscompiles, the 'general-purpose' claim is undercut.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Community-scale Fortran models can be migrated in a deterministic, auditable fashion: the same input always yields the same Python output, and each stage can be validated in isolation, unlike LLM-driven translation.
  • Numerical fidelity is preserved to floating-point precision: after both lowering stages, outputs stay within roughly 1e-9 (NumPy) and 1e-14 or better (JAX) of the Fortran reference on the tested procedures.
  • Generated JAX can beat the original Fortran on CPU when a user-supplied vectorization axis is present: the main hydrology routine runs 3.66x faster, suggesting vectorization and XLA-style compilation can overcome interpreter overhead once the code is JIT-compiled.
  • The staged NumPy-to-JAX representation provides a launchpad for differentiation: once the pipeline learns user-specified gradient inputs and outputs, grad/jvp/vjp wrappers can be emitted on top of the existing PyTree module without re-translation.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The reported speedups are entirely CPU-based; the paper never runs its GPU-adapted outputs on a GPU. Whether the 3.66x advantage carries to accelerators is a straightforward open test.
  • The vectorization axis is a user input, not discovered; in a codebase of hundreds of thousands of lines, choosing the wrong axis would silently degrade performance. Automatic axis discovery from the call graph is a natural extension left implicit.
  • Because the validation oracle is a small set of reference cases per procedure, the numerical-fidelity claim is only as broad as those cases. Coverage-guided or randomized testing would be a stronger check that the AST rewrites preserve semantics on unreached branches, and would directly challenge the paper's load-bearing premise.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents FGPT, an AST-based source-to-source transpiler that isolates Fortran procedures with their dependencies and lowers them to NumPy, then to JAX/Equinox modules. The pipeline is deterministic, in contrast to LLM-based translation, and is evaluated on the hydrology module of the IPSL land-surface model, reporting forward numerical agreement with the original Fortran at the 1e-9 level for NumPy and 1e-14–1e-18 for JAX, as well as wall-clock speedups for the JAX implementation. The abstract and introduction claim that FGPT produces 'correct, differentiable Python implementations' and that it preserves program semantics throughout translation.

Significance. If validated, FGPT would provide a reproducible, dependency-aware alternative to both manual rewriting and LLM-based migration of large Fortran scientific codes. The paper's strengths are concrete: the source code and benchmark data are publicly released, the pipeline stages are clearly separated (isolation, F2NP, Transformer, JaxConverter, AutoDiff), and the forward numerical validation against an independent Fortran oracle is a reasonable empirical sanity check. However, the differentiability claim is not backed by any AD test, the semantic-preservation claim rests on an unmeasured validation oracle, and the performance comparison uses an unoptimized Fortran baseline. These issues currently prevent the central claims from being accepted as stated.

major comments (4)
  1. [Abstract; Section 6.4] The abstract claims FGPT 'produces correct, differentiable Python implementations without requiring manual intervention,' and Section 1 repeats the 'correct, differentiable' language. Section 6.4, however, explicitly states that the pipeline 'does not yet produce jax.grad, jax.jvp, or jax.vjp call sites' and that 'gradient evaluation is outside the scope of the present work.' No gradient or derivative validation is reported anywhere. The differentiability claim is load-bearing because the paper motivates FGPT as a bridge to differentiable programming. The claim must either be substantiated by AD verification against a reference (e.g., Tapenade) or removed from the abstract, introduction, and conclusions.
  2. [Section 4; Section 2.2] The paper repeatedly states that FGPT 'preserves program semantics throughout the entire translation,' but the only support is a set of reference input–output pairs generated once per isolated procedure. The paper does not report how many inputs were used, how they were chosen, or any coverage metric (statement, branch, or path). The reported maximum absolute differences only show that the tested inputs produce close outputs. An untested branch, loop bound, array-indexing edge case, or unsupported intrinsic could silently change behavior on other inputs. This is a central weakness for a compiler whose core selling point is trustworthiness. I ask for an explicit coverage analysis or, failing that, a careful restriction of all semantic-preservation claims to the tested procedures and inputs.
  3. [Section 6.3; Appendix A.1] The speedup claims (e.g., 3.66× for JAX over Fortran) are computed against a Fortran baseline compiled with '-O0 -g -Kieee -Ktrap=fp -Mbounds' (Appendix A.1). Such a build is not representative of production Fortran performance. A JAX implementation JIT-compiled by XLA will naturally outperform an unoptimized, bounds-checked Fortran executable. The performance comparison should be repeated with an optimized Fortran build (e.g., -O2 or -O3, without -Mbounds) to make the speedup claim meaningful. The text currently overstates the result as 'the JAX implementation is faster than both the Fortran reference and the NumPy implementation.'
  4. [Title; Section 7; Table 4] The title calls FGPT a 'General-Purpose Transpiler' and the conclusions call it 'general-purpose,' yet Table 4 lists pointers, derived types, and interface blocks as 'Not yet supported,' and the evaluation is limited to a single hydrology module from one land-surface model. The generality of the approach is plausible but not demonstrated. Please either add support for these constructs or temper the generality claims to the supported subset described in Table 4.
minor comments (6)
  1. [Abstract/Introduction] 'Fython' is used without a definition or citation. Please define the term at first use.
  2. [Section 5] The bullet 'Generated modules remain directly compatible with JAX transformations including jit, grad, jvp, vjp, and vmap' is contradicted by Section 6.4, which states that grad/jvp/vjp interfaces are not yet generated. Rephrase to avoid overclaiming.
  3. [Section 7] The list of JAX primitives includes 'jax.less_than' (a named function, not a low-level primitive). Use the standard JAX syntax, e.g., 'jax.lax.lt' or 'lax.cond', for consistency.
  4. [Figure A2] Typo: 'Contorl Stack' should be 'Control Stack'.
  5. [Appendix A.1] Several words appear with formatting artifacts, e.g., 'V erified,' 'Y et,' 'F ortran.' These should be cleaned up in the final version.
  6. [Section 4.1] The text says 'the maximum absolute difference is typically on the order of 10−9,' but the figures are not annotated with axis scales. Please add axis labels and a reading so the reader can verify the stated magnitudes.

Circularity Check

0 steps flagged

No significant circularity: the validation oracle is the original compiled Fortran, and no fitted parameter or assumed target result is used in the derivation.

full rationale

The paper's derivation chain is a compiler pipeline: parse Fortran with fparser, isolate procedures, lower through an AST intermediate representation to NumPy, then lower NumPy to JAX/Equinox. The load-bearing correctness evidence is empirical comparison against the original Fortran implementation. Section 4 states: 'reference inputs and outputs are generated for every translation unit' and numerical consistency is quantified by 'max(|T - T_F|)', where T_F is 'the corresponding Fortran output.' This is an external oracle, not a fitted quantity or an assumed consequence of the transpiler; no constants are tuned to make the outputs match, and no correctness claim is defined in terms of the generated code itself. The JAX stage is similarly verified directly against Fortran (Section 6.3). The paper is candid about limitations: Section 6.4 says 'gradient evaluation is outside the scope of the present work,' and Table 4 lists unsupported constructs such as pointers and derived types. These are coverage and overclaim issues, not circularity. The cited external tools (fparser, JAX, Equinox) and prior LLM-translation papers are not self-citations by the present authors, and no uniqueness theorem or prior result by the same authors is invoked to force the approach. The user-specified vectorization variable (kjpindex) is a pipeline configuration input, not a result being predicted. Overall, the validity threat is unmeasured test coverage of the oracle, not circularity, so a score of 0 is appropriate.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 0 invented entities

No fitted parameters appear in the paper; the system has no calibration step. The main undeclared assumptions are about the reliability of the parser, the sufficiency of the I/O oracle, and the semantic-preservation of the JAX rewriting rules. FGPT itself is a software artifact, not a physical invented entity.

axioms (3)
  • domain assumption fparser parses all Fortran constructs present in the target module without semantic loss
    The entire pipeline operates on fparser's Fortran AST (Section 2); a parse error or mis-parse would corrupt every downstream transformation.
  • domain assumption The reference I/O datasets generated from the original Fortran are a sufficient test oracle for semantic equivalence
    Section 4 uses max-abs-diff against these references; no coverage metric is given, so untested branches are assumed correct.
  • domain assumption JAX/Equinox primitives (lax.scan, lax.cond, eqx.tree_at) preserve the semantics of the rewritten imperative loops and assignments
    Section 6.1 relies on these rewrites for traceability and AD-readiness; no formal equivalence proof is provided.

pith-pipeline@v1.3.0-alltime-deepseek · 12953 in / 9357 out tokens · 99226 ms · 2026-08-04T01:10:55.186080+00:00 · methodology

0 comments
read the original abstract

Fortran has been the cornerstone of high-performance computing for decades and remains unmatched in many domains. Yet the language faces an expertise gap: a new generation of scientists is barely familiar with it, while many experienced Fortran developers are only now transitioning to modern ecosystems such as JAX. This gap often results in "Fython"--Python code written with a Fortran mindset-- that fails to leverage modern frameworks. We present FGPT, a Python-based compiler framework designed to bridge this divide. It provides a systematic pipeline that transpiles Fortran into GPU-adapted Fortran, auto-differentiable Fortran via Tapenade, or NumPy and JAX modules. Its architecture comprises three stages: (i) a frontend that parses Fortran and extracts target procedures along with their cross-module dependencies; (ii) a middle-end that lowers the code into an intermediate representation, then into GPU-adapted or auto-differentiable Fortran, or a NumPy class; and (iii) a backend that rewrites control-flow and expressions to produce JAX modules ready for GPU acceleration and automatic differentiation. While large language models hold promise for small snippets, they fail at the scale of community scientific codes--often spanning hundreds of thousands of lines--where consistent transformations, strict numerical fidelity, and validation against production tests are non-negotiable. FGPT addresses these challenges by preserving program semantics throughout the entire translation. We verified the framework on representative climate modeling kernels and demonstrated that it produces correct, differentiable Python implementations without requiring manual intervention. By combining rigorous compiler techniques with modern accelerator support, FGPT offers a scalable, trustworthy path for modernizing legacy Fortran code.

Figures

Figures reproduced from arXiv: 2608.00130 by Kazem Ardaneh, Shivamshan Sivanesan.

Figure 1
Figure 1. Figure 1: AST-based transpilation. 2. FGPT in a nutshell FGPT begins by parsing Fortran source with fparser (STFC, 2026) and representing it as an AST, then applies a sequence of deterministic semantic transformations for generating the final code ( [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Workflow of the transpiler. 2.2. Transpilation Fortran and Python differ substantially in language semantics, execution model, memory represen￾tation, and variable management. As such, semantic equivalence cannot be achieved through direct syntactic translation alone; rather, each language difference is addressed through a corresponding compiler transformation, summarized in [PITH_FULL_IMAGE:figures/full_… view at source ↗
Figure 3
Figure 3. Figure 3: Workflow of the F2NP transpiler. Subsequent NodeTransformer-based corrective passes perform additional semantic corrections–including indexing semantics, attribute adjustments, etc –to produce executable Python code. Finally, standardized templates assemble the transformed AST into executable Python scripts. 3.1. F2NP transpiler The F2NP stage lowers isolated Fortran procedures to equivalent NumPy implemen… view at source ↗
Figure 4
Figure 4. Figure 4: AdjustIndices pass. 3.3. Corrective passes Although F2NP preserves structural semantics, certain language-specific corrections–array lower bounds, class attribute mappings, and object-composition relationships–require semantic information that only becomes available after program assembly. FGPT therefore applies two sequential corrective passes to the generated Python AST: AdjustIndices, which restores For… view at source ↗
Figure 5
Figure 5. Figure 5: ReplaceGlobals pass. 4. Numerical verification We verify that FGPT preserves the numerical precision of the original Fortran code when generating NumPy and JAX implementations by comparing outputs against the original Fortran. Since each proce￾dure is isolated prior to transformation, reference inputs and outputs are generated for every translation unit, enabling translation errors to be localized to indiv… view at source ↗
Figure 6
Figure 6. Figure 6: Maximum absolute difference between Numpy and Fortran outputs. Several of these procedures call additional child procedures, which are recursively isolated and tran￾spiled as part of the dependency analysis. Consequently, the entire hydrology workflow is translated into both NumPy and JAX. These procedures include multidimensional arrays, nested procedure hier￾archies, conditional execution, iterative loop… view at source ↗
Figure 7
Figure 7. Figure 7: Runtime and speedup comparison between Fortran and Numpy implementations. The NumPy implementation is order or magnitude slower than the original Fortran code, which is expected: Fortran is compiled by a compiler into efficient machine code, while the NumPy implementa￾tion executes through the Python interpreter, incurring additional overhead from interpretation, function calls, and object management. The … view at source ↗
Figure 8
Figure 8. Figure 8: Workflow of the JaxConverter and its helper classes. needed to preserve nested or masked conditions once the code is rewritten. These decisions–whether to vectorize, apply masked updates, or use indexed loops–guide the JaxConverter in the AST rewrites. 6.1.2. Vectorization and loop handling Vectorization is applied along a user-specified loop variable provided as a pipeline input rather than inferred autom… view at source ↗
Figure 9
Figure 9. Figure 9: Workflow of AutoDiff. 6.2.1. Transformation ordering and module conversion Unlike the Fortran-to-NumPy transpilation, which proceeds sequentially from class definitions to call￾ing scripts, the Equinox transformation begins with the main script. This ordering is necessary because main defines the concrete input arguments (e.g., dimensions and types) that seed shape propagation and guide subsequent transfor… view at source ↗
Figure 10
Figure 10. Figure 10: Maximum absolute deviation between JAX and Fortran outputs. into a functional update scheme: scalar values are wrapped with explicit JAX dtypes, array initial￾izations (e.g., np.zeros) are adjusted to JAX-compatible constructors, and direct assignments or setattr calls are replaced with updates to an intermediate dictionary that accumulates modified attributes. Once all assignments are processed, the mode… view at source ↗
Figure 11
Figure 11. Figure 11: Runtime comparison and speedup between Jax and Fortran. The only exception is hydrol_hydraulic_arch_tuzet_calc, whose Fortran implementa￾tion consists of an outer vectorization loop that repeatedly calls child routines–a structure that cannot be vectorized by JAX, resulting in no performance gain over the Fortran version [PITH_FULL_IMAGE:figures/full_fig_p017_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Performance evaluation between Fortran, NumPy and JAX [PITH_FULL_IMAGE:figures/full_fig_p018_12.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

9 extracted references · 5 linked inside Pith

  1. [1]

    L., Eden C., Kristensen M

    Häfner D., Jacobsen R. L., Eden C., Kristensen M. R. B., Jochum M., Nuterman R., Vinter B. (2018) Veros v0.1 – a fast and versatile ocean simulator in pure Python, Geoscientific Model Development 11(8), 3299--3312

    2018

  2. [2]

    J., Katariya Y., Leary C., Maclaurin D., Necula G., Paszke A., VanderPlas J., Wanderman-Milne S., Zhang Q

    Bradbury J., Frostig R., Hawkins P., Johnson M. J., Katariya Y., Leary C., Maclaurin D., Necula G., Paszke A., VanderPlas J., Wanderman-Milne S., Zhang Q. (2018) JAX : composable transformations of P ython+ N um P y programs, http://github.com/jax-ml/jax

    2018

  3. [3]

    (2021) Equinox: neural networks in JAX via callable PyTrees and filtered transformations, arXiv preprint arXiv:2111.00254

    Kidger P., Garcia C. (2021) Equinox: neural networks in JAX via callable PyTrees and filtered transformations, arXiv preprint arXiv:2111.00254

    Pith/arXiv arXiv 2021

  4. [4]

    V., Cheedela S

    Koldunov N. V., Cheedela S. K., Danilov S., Sidorenko D., Beyer S., Jung T. (2026) An Ocean Model Ported by a Large Language Model : Experience and Lessons from FESOM2 ( Fortran to C to C ++/ Kokkos ), arXiv preprint arXiv:2606.11356

    Pith/arXiv arXiv 2026

  5. [5]

    (2026) Systematic LLM Translation of Legacy Scientific Code to Differentiable Frameworks : Application to a Land Surface Model , arXiv preprint arXiv:2606.07681

    Lahlou A., Hawkins L., Gentine P. (2026) Systematic LLM Translation of Legacy Scientific Code to Differentiable Frameworks : Application to a Land Surface Model , arXiv preprint arXiv:2606.07681

    Pith/arXiv arXiv 2026

  6. [6]

    UKRI Science and Technology Facilities Council (2026) stfc/fparser, https://github.com/stfc/fparser

    2026

  7. [7]

    (2009) F2PY : a tool for connecting Fortran and Python programs, International Journal of Computational Science and Engineering 4(4), 296--305

    Peterson P. (2009) F2PY : a tool for connecting Fortran and Python programs, International Journal of Computational Science and Engineering 4(4), 296--305

    2009

  8. [8]

    C., Varoquaux G

    Van Der Walt S., Colbert S. C., Varoquaux G. (2011) The NumPy array: a structure for efficient numerical computation, arXiv preprint arXiv:1102.1523

    Pith/arXiv arXiv 2011

  9. [9]

    (2024) Proof-of-concept: Using ChatGPT to Translate and Modernize an Earth System Model from Fortran to Python / JAX , arXiv preprint arXiv:2405.00018

    Zhou A., Hawkins L., Gentine P. (2024) Proof-of-concept: Using ChatGPT to Translate and Modernize an Earth System Model from Fortran to Python / JAX , arXiv preprint arXiv:2405.00018

    Pith/arXiv arXiv 2024