Pith. sign in

REVIEW 3 major objections 5 minor 15 references

Public release of Atlas under an open source license, which is accelerator enabled and has improved interoperability features

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read Atlas, the weather and climate data-structure library, is released as open source under Apache-2.0, with a no-overhead Fortran interface and GPU interoperability.

desk verdict A genuine software release deliverable with clear CPU build instructions, but the accelerator story is not independently testable at release time and the performance claims are unmeasured. read the letter →

arxiv 1908.07038 v1 pith:YGTIFNQT submitted 2019-08-16 cs.DC

Willem Deconinck This is my paper · ORCID
classification cs.DC
keywords AtlaslibraryopensourceApache-2.0FortraninterfaceCUDAACCGPUinteroperabilityweatherandclimatedatastructures
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This deliverable reports the first public release of Atlas, a C++ library for the data structures used in numerical weather prediction and climate modelling, under the permissive Apache-2.0 license. The central claim is that the release is usable by the community as-is: it provides a Fortran interface that mirrors the C++ object-oriented design without runtime overhead, and it maps the same field data onto GPU memory so that CUDA-written C++ and OpenACC-written Fortran can operate on shared data. That claim matters because operational weather and climate codes are mostly Fortran, while emerging supercomputers are heterogeneous CPU/GPU machines, and Atlas is intended as a common data-structure foundation for both. If the release works as described, teams can adopt a permissively licensed substrate for grids, meshes, fields, and function spaces without being locked into a closed ecosystem.

What carries the argument

The load-bearing design is the Atlas data-structure framework organised around four concepts: grid, mesh, field, and function space. Two mechanisms make the interoperability claims concrete. The Fortran interface wraps each C++ class in a Fortran derived type whose only data member is a raw pointer to the C++ instance; method calls pass through a C binding, so Fortran and C++ share the same objects. For accelerators, Atlas allocates field memory on the GPU with CUDA and then maps that allocation into an OpenACC Fortran array view, letting an OpenACC data-present clause tell the runtime that no copy is needed. For multi-resolution coupling, a coarse grid is partitioned according to the fine grid's domain decomposition so that element-based remapping requires no parallel interpolation.

What would settle it

Build the released Atlas source from scratch with the documented optional accelerator dependencies and run the OpenACC/CUDA interoperability example; if the storage module cannot be obtained or the mapping fails to compile on a supported compiler, the accelerator-enabled release cannot be reproduced as claimed. A second check: benchmark a loop that accesses field elements through the Fortran wrapper against the equivalent C++ loop; if the Fortran path shows per-access overhead beyond measurement noise, the 'without additional runtime overhead' claim is false for in-loop access.

Watch

Extended reading notes

Core claim

The deliverable's own claim is that Atlas version 0.10.0 is ready for public, permissively licensed use as the data-structure backbone of weather and climate codes. The library's four central abstractions are the grid (an ordered list of points with no connectivity), the mesh (points plus elements and connectivity), the field (a container of discrete values), and the function space (the discretisation that interprets a field and performs halo exchanges). The report argues that the Fortran API is a faithful wrapper of the C++ classes, built by storing a C pointer to the C++ object inside a Fortran derived type and delegating each method through a C interface, so that the overhead is negligible outside computational loops. It further claims that Atlas data can be allocated on a GPU with CUDA and mapped into OpenACC-visible Fortran arrays, allowing CUDA kernels and OpenACC kernels to modify the same field without an explicit host copy, and that fields on grids of different resolutions can be coupled by copying the fine grid's domain decomposition onto the coarse grid and then remapping with parallel interpolation.

Load-bearing premise

The load-bearing premise is that the optional accelerator path can be built by an independent user: it depends on an external storage module that the report says is not yet publicly released, and the OpenACC/CUDA memory mapping must survive the compiler bugs the report documents.

Editorial extensions

If this is right

  • Operational and research weather and climate codes, including closed-source ones, can link against Atlas without license obligations because of the Apache-2.0 license.
  • Fortran models can adopt Atlas data structures and share them with C++ routines, so each component of a model can be written in the language best suited to it.
  • A single field can be updated by OpenACC Fortran kernels on a GPU and then by CUDA C++ kernels on the same device, without an explicit host-device copy in between.
  • Multi-component earth-system models can couple grids of different resolutions by matching the coarse grid's domain decomposition to the fine grid and then remapping with parallel interpolation.
  • The released library gives domain-specific-language backends a common data-structure layer to target CPU, GPU, and many-core hardware.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the no-copy CUDA-to-OpenACC mapping works on mainstream compilers, the same pattern could become a template for other mixed C++/Fortran scientific libraries seeking GPU interoperability.
  • The separation of generic support libraries (logging, configuration, smart pointers) under the same permissive license suggests Atlas could outgrow weather and climate and serve as shared infrastructure for other grid-based simulation communities.
  • The matching-decomposition approach to multi-resolution grids is a lighter-weight alternative to full couplers, but only for tightly integrated components in a single executable; separate executables would still need coupler-style communication.
  • A testable prediction follows: a benchmark that accesses field data through the Fortran wrapper inside a computational loop should stay within the same order of magnitude as raw C++ access; if it does not, the no-runtime-overhead clause would have to be restricted to data-structure setup rather than per-element access.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. This ESCAPE deliverable report (D2.3) announces the first public release of the Atlas software libraries under the permissive Apache-2.0 license, hosted on ECMWF's GitHub portal. It documents system requirements, download and build instructions for Atlas and its companion libraries (ecbuild, eckit, fckit), basic C++ and Fortran usage examples, and three interoperability features: Fortran bindings to the C++ object model, CUDA/OpenACC memory mapping for GPU accelerators, and remapping between grids of different resolutions. The report also summarizes work performed since the internal D1.3 release, including Fortran compiler-bug workarounds, GPU interoperability improvements, and the release strategy.

Significance. If the release claims hold, this is a useful contribution to the NWP and climate modelling community: a permissively licensed data-structure library covering grids, meshes, fields, and function spaces, with both C++ and Fortran interfaces and a public repository trail. The report gives concrete, reproducible instructions for the CPU build path, and the named repositories (ecbuild, eckit, fckit, atlas) and installation walkthrough are strengths. The weaker parts are the headlined accelerator-enabled claim, which depends on a not-yet-public GridTools dependency, and the unqualified 'no additional runtime overhead' statement for the Fortran interface, which is later narrowed to 'can be disregarded if performed outside of a computational loop'.

major comments (3)
  1. [Section 2.2.2 / Section 3.1 / Section 3.4] The title and Executive Summary describe Atlas as 'accelerator enabled', but an independent user cannot build or verify the accelerator path from the released artifacts: Section 2.2.2 states that GridTools 'is not yet publicly released', Section 3.1 lists the GridTools storage module as optional with only a GitHub organization link and no version or commit, and Section 3.4's sample 'atlas --info' output shows 'GPU : OFF'. The public release is therefore not self-contained for its headline accelerator feature. Please either make the GridTools dependency publicly available at a pinned version at the same time as the Atlas release, or explicitly scope the release claim to CPU functionality with accelerator support as a future or conditional feature.
  2. [Section 4.1 / Executive Summary] The Executive Summary states that the Fortran interface is presented 'without additional runtime overhead', but Section 4.1 qualifies this as 'can be disregarded if performed outside of a computational loop'. These are materially different claims: one promises zero overhead, the other promises negligible overhead for data-structure management but not for computational kernels. Please replace the unqualified sentence with the qualified one, or provide benchmark measurements if the stronger claim is intended.
  3. [Section 4.2] Listings 3 and 4 illustrate the intended CUDA/OpenACC interoperability, but the report gives no compiler and CUDA versions, no build flags for the accelerator path, and no test output demonstrating that the 'data present(view)' path avoids host-device copies. This matters because Section 2.2.2 reports multiple compiler bugs in the Fortran 2003/C-interop features on which this path relies. To make the accelerator claim verifiable, include at least one reproducible test case with named compiler, CUDA, and GridTools versions, together with the corresponding output or a pointer to a public test artifact.
minor comments (5)
  1. [Section 2.2.2] The sentence 'GridTools is not managed by ECMWF, and not is not yet publicly released' contains a typo; it should read 'and is not yet publicly released'.
  2. [Section 3.2] The heading 'Downloading to Atlas' should likely be 'Downloading Atlas' or 'Downloading the Atlas libraries'.
  3. [Section 3.1] The system-requirements bullet 'C++11, Fortran 2008' is ambiguous about whether Fortran is mandatory; later text confirms Fortran is optional, so the bullet should say 'Fortran 2008 (optional)' for consistency.
  4. [Section 3.4] The sample 'atlas --info' output prints 'timestamp : 20160215122606', which is inconsistent with a release version dated 2017; clarify whether this is a build timestamp, a source timestamp, or a typo.
  5. [Section 4.2 / Listing 3] The example maps a Fortran pointer to CUDA-allocated memory and relies on OpenACC 'present' semantics; a brief note on the required Fortran pointer association and on compiler-specific restrictions would help users reproduce the example.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular reasoning found: the report makes release and interoperability claims that are not derived from the cited prior work.

full rationale

This document is a project deliverable reporting the public release of the Atlas library under the Apache-2.0 license, with installation instructions, feature descriptions, and interoperability examples. It does not derive a numerical result or claim a prediction from fitted inputs. The cited prior deliverables (D1.3) and the Atlas journal article (Deconinck et al., 2017) are used for background and design context, not as the sole justification of the release claim. The statement that Atlas is publicly released is supported by the repository list and download instructions in Section 3.2, and the license is stated directly. The accelerator interoperability claims are qualified by the optional GridTools dependency, which is disclosed rather than hidden. The Fortran overhead statement is later qualified in Section 4.1 ('can be disregarded if performed outside of a computational loop'), showing that the report does not present an unqualified derived result. None of these features reduce by construction to the paper's own inputs, and no self-citation is load-bearing. The absence of external benchmarks or a demonstrated GPU build is a verification limitation, not a circularity.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

No free parameters or invented entities apply to a software release report. The two assumptions listed are operational premises on which the accelerator-interoperability claim rests, not mathematical axioms.

assumptions (2)
  • domain assumption The GridTools storage module is available and compatible with the released Atlas version.
    Section 2.2.2 says GridTools is not yet publicly released, while Section 3.1 makes it an optional dependency for accelerator support.
  • domain assumption The CUDA to OpenACC memory mapping described in Section 4.2 is valid on the supported compilers.
    Section 2.2.2 reports compiler bugs for PGI, Intel, Cray, and GNU; workarounds are claimed but no test suite is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Public release of Atlas under an open source license, which is accelerator enabled and has improved interoperability features." pith.science (2026). https://pith.science/paper/YGTIFNQT

@misc{pith2026190807038,
  author       = {Pith},
  title        = {Pith review of: Public release of Atlas under an open source license, which is accelerator enabled and has improved interoperability features},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YGTIFNQT}},
  note         = {Machine review of arXiv:1908.07038}
}
read the original abstract

This document is one of the deliverable reports created for the ESCAPE project. ESCAPE stands for Energy-efficient Scalable Algorithms for Weather Prediction at Exascale. The project develops world-class, extreme-scale computing capabilities for European operational numerical weather prediction and future climate models. This is done by identifying Weather & Climate dwarfs which are key patterns in terms of computation and communication (in the spirit of the Berkeley dwarfs). These dwarfs are then optimised for different hardware architectures (single and multi-node) and alternative algorithms are explored. Performance portability is addressed through the use of domain specific languages. Atlas has been presented in deliverable D1.3. With this deliverable D2.3, a first version of the Atlas software libraries is publicly released with a permissive open-source license. The software is freely available for download, and contains a user guide and installation instructions. The Atlas libraries have been carefully designed with the user's perspective in mind. Even though Atlas is mainly coded in C++, an equivalent Fortran interface is presented without additional runtime overhead. The Fortran interfaces are provided to accommodate existing NWP and climate models that typically consist of Fortran subroutines. The mixed Fortran/C++ design enhances interoperability between NWP and climate models and novel data management techniques. Atlas provides interoperability with accelerator hardware, and can serve as foundation to support higher level abstractions as used in domain specific languages.

Figures

Figures reproduced from arXiv: 1908.07038 by the authors.

Figure 1
Figure 1. The conceptual design of Atlas. define fields with appropriate indexing mechanisms. For element-based numerical methods (generally unstructured) however, the mesh concept is introduced that describes connectivity lists linking elements, edges and nodes. A mesh may be decomposed in partitions and distributed among MPI tasks. Every MPI task then allows computations on one such partition. Overlap regions (or halo’s) be… view at source ↗
Figure 2
Figure 2. Workflow of Atlas starting from Grid to the creation of a Field, discretised on a Mesh and managed by a FunctionSpace. For more comprehensive description on Atlas please refer to (Deconinck et. al., 2017) [6], which is published for ESCAPE with open access. 8 [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. Construction of the Fortran interface to the [PITH_FULL_IMAGE:figures/full_fig_p022_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Interoperability between multiple grids or resolutions. Shaded area [PITH_FULL_IMAGE:figures/full_fig_p025_4.png]
Figure 5
Figure 5. Figure 5: A schematic of how to set up two grids of different resolution with [PITH_FULL_IMAGE:figures/full_fig_p025_5.png]
Figure 6
Figure 6. Figure 6: Remapping example of a field initialised on a “O32” grid to a coarser [PITH_FULL_IMAGE:figures/full_fig_p026_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

15 extracted references · 15 canonical work pages

  1. [1]

    Improving user experience

    work page

  2. [2]

    Porting to various compilers and hardware architectures. 3. Improving interoperability with GPU in support of porting Dwarfs to GPU

    work page

  3. [3]

    eu/media-hub/escape-pub/escape-deliverables, Available: 31-12-2017

    ESCAPE Deliverable D2.4: Domain-specific language (DSL) for dynamical cores on unstructured meshes/structured grids, http://www.hpc- escape. eu/media-hub/escape-pub/escape-deliverables, Available: 31-12-2017

    work page 2017

  4. [4]

    to interoperate between structured/un- structured grids at multiple resolutions

    Implementing new Atlas features, e.g. to interoperate between structured/un- structured grids at multiple resolutions

    work page

  5. [5]

    As part of improving the user experience (item 1), we paid special attention to the Fortran interfaces

    Devising a strategy to publicly release the Atlas libraries. As part of improving the user experience (item 1), we paid special attention to the Fortran interfaces. In order to have an interface as close as possible to the C++ Object Oriented design, relatively “new” Fortran 2003 features were used. It has proven that even 15 years after this released For...

    work page 2003

  6. [6]

    ESCAPE Deliverable D1.3: Development of the flexible data structure frame- work Atlas, http://www.hpc-escape.eu/media-hub/escape-pub/escape- deliverables, Accessed: 31-12-2017

    work page 2017

  7. [7]

    hpc - escape

    ESCAPE Deliverable D1.1, http : / / www . hpc - escape . eu / media - hub / escape-pub/escape-deliverables, Accessed: 31-12-2017. 22 D2.3 – Public release of Atlas under an open source license

    work page 2017

  8. [8]

    The OASIS3 coupler: A European climate modelling community software

    S. Valcke, “The OASIS3 coupler: A European climate modelling community software”,Geosci. Model Dev., vol. 6, pp. 373–388, 2013

    work page 2013

Show all 15 references
  1. [9]

    NVIDIA CUDA toolkit documentation, http://docs.nvidia.com/cuda/ , Accessed: 31-12-2017

    2017

  2. [10]

    ESCAPE Deliverable D5.6: Establish software collaboration platform,http: //www.hpc- escape.eu/media- hub/escape- pub/escape- deliverables , Accessed: 31-12-2017

    2017

  3. [11]

    Atlas : A library for numerical weather prediction and climate modelling

    W. Deconinck, P. Bauer, M. Diamantakis, M. Hamrud, C. Kühnlein, P. Maciel, G. Mengaldo, T. Quintino, B. Raoult, P. K. Smolarkiewicz, and N. P. Wedi, “Atlas : A library for numerical weather prediction and climate modelling”, Computer Physics Communications [openaccess], pp. 18...

    2017 doi

  4. [12]

    OpenACC main webpage,http://www.openacc.org/, Accessed: 31-12-2017

    2017

  5. [14]

    The architecture of the Earth System Modeling Framework

    C. Hill, C. DeLuca, V. Balaji, M. Suarez, and A. d. Silva, “The architecture of the Earth System Modeling Framework”,Computing in Science and Engg., vol. 6, no. 1, pp. 18–28, Jan. 2004,issn: 1521-9615

    2004

  6. [15]

    The new ecmwf interpolation package MIR

    P. Maciel, T. Quintino, U. Modigliani, P. Dando, B. Raoult, W. Deconinck, R. F., and S. C., “The new ecmwf interpolation package MIR”,ECMWF Newsletter, vol. 152, 2017. [Online]. Available:https://www.ecmwf.int/en/ newsletter/152/editorial/good-move. 23 D2.3 – Public release of...

    2017

  7. [2017]

    Hello world

    [6], which is published for ESCAPE with open access. 8 D2.3 – Public release of Atlas under an open source license 3 Atlas public release This section is intended to be a general introduction on how to download, install and run Atlas. In particular, in section3.1 we will prese...

    2008

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.