Pith. sign in

REVIEW 3 major objections 4 minor 18 references

Development of Atlas, a flexible data structure framework

T0 review · 3 major / 4 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 One library now unifies weather-model data structures for CPU and GPU

desk verdict Solid design report for a genuinely useful NWP data-structure library; no measurements, so judge it as an engineering document, not as evidence of performance. read the letter →

arxiv 1908.06091 v1 pith:ZII6IAYU submitted 2019-08-16 cs.DC

Willem Deconinck This is my paper · ORCID
classification cs.DC
keywords datastructuresnumericalweatherpredictionclimatemodellingHPCGPUaccelerationunstructuredmeshreducedGaussiangridFortraninterface
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

The paper aims to establish that a single software library, Atlas, can supply the data structures that numerical weather prediction and climate models need—grids, meshes, fields, and the function spaces that interpret them—in a way that is flexible enough for both global and limited-area domains and portable enough for CPU, GPU, and distributed-memory supercomputers. The claimed payoff is that model developers can build and reuse numerical methods on top of these structures instead of hand-coding mesh handling and communication for each machine. The report documents the library's design, its Fortran interface, its support for standard global grids (regular, reduced Gaussian, octahedral) and regional projected grids, and its accelerator-aware storage that lets fields and mesh connectivity live on a GPU. A sympathetic reader would care because this is a concrete attempt to create a common, portable data-structure layer for a community whose codes are traditionally monolithic and increasingly constrained by hardware diversity.

What carries the argument

The load-bearing machinery is a four-concept data model. Grid is a (possibly structured, reduced, or unstructured) list of points with a projection and a domain; Mesh is a collection of polygonal elements linking grid points, with explicit connectivity tables and the ability to be partitioned across MPI tasks with halos; Field is a contiguous array of values with metadata and a pluggable memory layout; FunctionSpace interprets a field's discretisation—node columns, edge columns, structured columns, or spectral coefficients—and supplies parallel primitives including halo exchange and gather/scatter. The design also rests on two implementation choices: a Fortran derived type whose only member is a pointer to a matching C++ object, with calls delegated through C interfaces, and a storage backend that can be switched between a native implementation and the accelerator-aware storage provided by the DSL library (reference [6]) so that fields and mesh connectivity can be synchronised between CPU and GPU.

What would settle it

Run a representative Fortran NWP kernel (for example, a Jacobi or stencil update over columns and levels) with the same data access performed through Atlas's Fortran API inside the inner loop versus fetched once before the loop, on a current CPU and GPU; if the Atlas API version is measurably slower by more than a few percent, the assertion that delegation overhead can be disregarded would fail for that usage pattern.

Watch

Extended reading notes

Core claim

Atlas's central claim is that the four concepts—Grid, Mesh, Field, and FunctionSpace—form a complete and flexible foundation for NWP and climate applications. A Grid is an ordered list of points under a spatial projection; a Mesh adds elements and connectivity and may be split into MPI partitions with overlapping halo regions; a Field is a contiguous array of values with metadata that can be laid out in different memory orders; and a FunctionSpace ties them together by dictating how a field is discretised (nodes, edges, columns, or spherical harmonics) and provides the parallel operations, such as halo exchange and gather/scatter, that keep distributed fields consistent. The report argues that this separation lets the same numerical methods—finite volume, spectral element, spectral transform—be expressed once and run on emerging architectures, and that the Fortran API plus the GPU-aware storage backend make it possible to port Fortran operators to accelerators without replacing the underlying data structures.

Load-bearing premise

The efficiency claim depends on the assumption that delegating calls from the Fortran API to the C++ implementation has negligible overhead because users fetch field data before entering computational loops; the report does not test what happens when Atlas calls occur inside hot loops.

Editorial extensions

If this is right

  • Numerical methods written against Atlas's FunctionSpace and Field concepts—finite volume, spectral element, spectral transform—can be reused across CPU and GPU backends without rewriting the data-structure layer.
  • Models that adopt Atlas gain ready-made parallel communication (halo exchange, gather/scatter) through the FunctionSpace, so the burden of hand-coding MPI for field synchronisation is reduced.
  • The grid catalogue covers the main global grid families used in the community (regular lon-lat, classic and octahedral reduced Gaussian) plus regional projected grids, so model intercomparison and limited-area modelling can share one framework.
  • Because Atlas fields can be created with a host/device storage backend, Fortran kernels can be ported to GPUs with OpenACC while keeping the same data structures, as demonstrated by the report's example.

Reading between the lines

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

  • If Atlas becomes the shared layer for several models, optimisations to its halo exchange, memory layout, or partitioners would benefit every model at once; the paper does not attempt to quantify this leverage.
  • The report's assumption that Fortran-to-C++ delegation overhead is negligible outside computational loops implies a discipline—extract field data before looping—that users must follow; the paper gives no benchmark measuring the threshold where that overhead becomes material.
  • The MatchingMesh partitioner points toward a future where interpolation and coupling between models on different grids can be done partition-locally without global communication, but scaling and load-balance of that approach are not reported.
  • The planned generalisation of StructuredColumns beyond Gaussian grids (stated as a future release) would let the same field object serve both grid-point and spectral-transform codes; the current report only supports Gaussian grids for that function space.
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 / 4 minor

Summary. This deliverable report describes Atlas, a C++ library with a Fortran API for managing data structures used in numerical weather prediction and climate modelling: grids (structured, reduced, unstructured), meshes, fields, function spaces, parallel communication (halo exchange, gather/scatter), and accelerator storage via the GridTools storage layer. The paper presents the design rationale, UML class diagrams, usage examples, installation instructions, and describes work done in the ESCAPE project to extend Atlas to regional grids and GPU support. The stated central claim is that Atlas provides a versatile framework for the future development of efficient NWP and climate applications on emerging HPC architectures.

Significance. The design is thoughtful and addresses real needs of the NWP community: a common abstraction for grid and mesh data structures, separation of grid/distribution/mesh, a function-space concept that manages parallelisation and memory layout, and an array abstraction with host/device views and synchronisation. The report is honest about current limitations (no GPU halo exchange, no projection-aware operators for regional grids, restricted access to the code). However, the central efficiency and scalability claims are not supported by benchmarks, scaling studies, or profiling data. The only performance-related assertion is the assumption in Section 4.1 that Fortran-to-C++ delegation overhead is negligible when calls are made outside computational loops. Thus, if the design and claims are taken at face value, Atlas could be a significant step for the community, but the evidence presented is insufficient to verify the efficiency promise.

major comments (3)
  1. [§4.1, §1] The claim that the Fortran API delegation overhead "can be disregarded if performed outside of a computational loop" (§4.1) is load-bearing for the Executive Summary's promise of "efficient" applications, but it is an unquantified assumption. No microbenchmark or profiling data are provided, and no evidence is given that realistic Fortran codes (e.g., with halo exchanges or metadata queries inside time-stepping loops) can always follow the recommended pattern of retrieving field data before entering loops. If per-call overhead is non-negligible, the efficiency claim is eroded. Please either measure the overhead or soften the claim.
  2. [§4.4, §5] The report describes parallel communication classes (GatherScatter, HaloExchange) and GPU support (§4.4, §5), but provides no scaling results, communication timings, GPU kernel timings, or comparisons with non-Atlas data structures. The assertion that Atlas enables "massively parallel" and "emerging HPC architectures" is therefore not substantiated by the evidence in the paper. At minimum, a weak scaling test on a representative grid/mesh workload and a microbenchmark of the Fortran API delegation would be needed to support the central claim.
  3. [§3.2, §6] The code is currently restricted to ESCAPE partners (§3.2), and the Conclusions state that the library has been "tested and compiled with various compilers and computer architectures" without describing any test suite, validation results, or error metrics. This limits the reproducibility of the claimed capabilities and makes it difficult for readers to assess the maturity of the library. Please provide a description of the tests performed or make the test suite available.
minor comments (4)
  1. [§2.2.1, §2.2.2] There are spelling errors: "accomodate" should be "accommodate" in §2.2.1, and "succesfully" should be "successfully" in §2.2.2.
  2. [§4.2.3.7, Figure 15] The note inside the class diagram says "RegularGaussianGrid is valid when it is a valid ReducedGrid..." but should refer to "ReducedGaussianGrid".
  3. [Listing 15] The kernel code contains garbled characters "t hr ea dI dx .x" instead of "threadIdx.x".
  4. [§3] Several sections contain duplicated words such as "Section section3.1" in §3, and the code listings have inconsistent spacing; a careful proofread is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Atlas is a software design report whose claims are supported by implementation and design, not by derivation from the claims themselves.

full rationale

This document is a deliverable report describing the design, implementation, and installation of the Atlas library. It makes no fitted predictions and contains no derivation chain: the central claim that Atlas provides a versatile framework for efficient NWP and climate applications on emerging HPC architectures is a design goal supported by the presented architecture (Grid, Mesh, FunctionSpace, Field, partitioners, halo exchange, GPU storage integration) rather than by a calculation that reduces to its own inputs. Section 4.1 does state an assumption that Fortran-to-C++ delegation overhead can be disregarded outside computational loops, and the paper contains no benchmarks validating this assumption; however, that is a correctness or evidence gap, which is explicitly out of scope for the circularity pass. The self-citations to ESCAPE deliverables D1.1, D1.2, D2.4, and D4.4 are used for context and for referencing prior project work, not to import an unverified premise that already contains the central claim. The citations to the fvm finite-volume scheme (reference 15) and to the equal-regions partitioner (references 11-13) are ordinary references to published algorithms and implementation choices; they are not invoked as uniqueness theorems or as proofs of the library's efficiency. No step in the report defines, fits, or renames a result in terms of the output it is supposed to establish. The report is therefore self-contained against external benchmarks in the sense relevant to circularity analysis: there is no circular reduction to exhibit.

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

The central capability claims rely on domain assumptions about NWP structure (vertical-horizontal anisotropy) and on a usage assumption about interface overhead. No free parameters or invented physical entities are introduced. The Gaussian grid definition uses standard Legendre polynomial background.

assumptions (3)
  • domain assumption Vertical discretisation is orthogonal to horizontal discretisation.
    Section 4.3 states that the vertical discretisation may be considered orthogonal to the horizontal due to large anisotropy, justifying column-based memory layout and 2D mesh elements. If this fails, the data structures would need 3D elements.
  • standard math Gaussian grid latitudes are the roots of Legendre polynomials.
    Section 4.2.3.5 defines GaussianGrid as using an even number of parallels that follow the roots of a Legendre polynomial. This is standard mathematical background.
  • ad hoc to paper Fortran-C++ delegation overhead is negligible when calls are made outside computational loops.
    Section 4.1 states this explicitly. The performance of the Fortran interface relies on users following this usage pattern, which is a load-bearing assumption for efficiency claims.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Development of Atlas, a flexible data structure framework." pith.science (2026). https://pith.science/paper/ZII6IAYU

@misc{pith2026190806091,
  author       = {Pith},
  title        = {Pith review of: Development of Atlas, a flexible data structure framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZII6IAYU}},
  note         = {Machine review of arXiv:1908.06091}
}
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. In this deliverable report, we present Atlas, a new software library that is currently being developed at the European Centre for Medium-Range Weather Forecasts (ECMWF), with the scope of handling data structures required for NWP applications in a flexible and massively parallel way. Atlas provides a versatile framework for the future development of efficient NWP and climate applications on emerging HPC architectures. The applications range from full Earth system models, to specific tools required for post-processing weather forecast products. Atlas provides data structures for building various numerical strategies to solve equations on the sphere or limited area's on the sphere. These data structures may contain a distribution of points (grid) and, possibly, a composition of elements (mesh), required to implement the numerical operations required. Atlas can also represent a given field within a specific spatial projection. Atlas is capable of mapping fields between different grids as part of pre- and post-processing stages or as part of coupling processes whose respective fields are discretised on different grids or meshes.

Figures

Figures reproduced from arXiv: 1908.06091 by the authors.

Figure 1
Figure 1. The conceptual design of Atlas. points, typically structured and using two indices i and j so that point coordinates and computational stencils (for e.g. derivatives) are easily retrieved without connec￾tivity rules. For models using a structured grid point approach a grid is enough to define fields with appropriate indexing mechanisms. For element-based numerical methods (generally unstructured) however, the mesh c… 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. implement additional operations required for specific applications. Atlas supplies certain mathematical operations as ready solutions to be plugged in to user software. These operations vary from the computation of gradient, divergence, curl and laplacian operations to remapping or interpolation of … view at source ↗
Figure 3
Figure 3. Procedure how the Fortran interface to the [PITH_FULL_IMAGE:figures/full_fig_p020_3.png] view at source ↗
Figures from the paper (30 more)
Figure 4
Figure 4. Figure 4: Four examples of global grids in geographical coordinates with approxi [PITH_FULL_IMAGE:figures/full_fig_p022_4.png]
Figure 5
Figure 5. Figure 5: UML class diagram for the Projection class implementation, refer to ESCAPE deliverable report D4.4 [3]. 4.2.2 Domain In this section, the Domain class is introduced ( [PITH_FULL_IMAGE:figures/full_fig_p023_5.png]
Figure 6
Figure 6. Figure 6: UML class diagram for the Domain class Note The domain has no knowledge of any grid projection. Therefore the points that can be tested to be contained inside the domain must be provided in “grid coordinates” (x,y), and not in geographical coordinates (lon,lat). The Re…
Figure 7
Figure 7. Figure 7: illustrates the Grid class implementation. It shows that the Grid class can return instances of the Domain class and the Projection class. * 1 + valid() : Boolean = true + size() : Integer + begin() : Iterator + end() : Iterator + name() : String + uid() : String + dom…
Figure 8
Figure 8. Figure 8: UML class inheritance diagram for Grid classes 23 [PITH_FULL_IMAGE:figures/full_fig_p027_8.png]
Figure 9
Figure 9. Figure 9: shows the UML class diagram of the StructuredGrid. The first two constructors listed effectively create a new grid, whereas the third constructor accepts any existing grid, and reinterprets it instead. No copy or extra storage is then introduced, since the wrapped Grid…
Figure 10
Figure 10. Figure 10: shows the UML class diagram of the StructuredGrid. The first two constructors listed effectively create a new grid, whereas the third constructor accepts any Grid , and reinterprets it instead if possible. No copy or extra storage is then introduced, since the wrapped…
Figure 11
Figure 11. Figure 11: UML class diagram for the RegularGrid class 4.2.3.4 ReducedGrid A ReducedGrid is, unlike the RegularGrid, not a specialisation of the StructuredGrid in terms of functionality, but it does add the constraint that the grid is only valid when it is not regular [PITH_FUL…
Figure 12
Figure 12. Figure 12: UML class diagram for the ReducedGrid class 4.2.3.5 GaussianGrid A GaussianGrid is a StructuredGrid with the additional constraint that the grid is globally defined with an even number of parallels that follow the roots of a Legendre polynomial in the interval (90◦ ,-…
Figure 13
Figure 13. Figure 13: UML class diagram for the GaussianGrid class 4.2.3.6 RegularGaussianGrid A RegularGaussianGrid combines the properties of a RegularGrid and a Gaussian￾Grid. It can be defined by a single number N (the Gaussian number). The number of points in x− and y-direction are by…
Figure 14
Figure 14. Figure 14: shows the class diagram for the RegularGaussianGrid. As can be seen in + valid() : Boolean <<override>> <<constructor>> RegularGaussianGrid( N : Integer ) <<constructor>> RegularGaussianGrid( name : String ) <<constructor>> RegularGaussianGrid( configuration : Config …
Figure 15
Figure 15. Figure 15: shows the class diagram for the ReducedGaussianGrid. As can be seen + valid() : Boolean <<override>> <<constructor>> ReducedGaussianGrid( nx : Integer[ny] ) <<constructor>> ReducedGaussianGrid( name : String ) <<constructor>> ReducedGaussianGrid( configuration : Confi…
Figure 16
Figure 16. Figure 16: shows the class diagram for the RegularLonLatGrid. It can be seen that this class exposes 4 functions to query which of the 4 variants is presented. + valid() : Boolean <<override>> + standard() : Boolean + shifted() : Boolean + shiftedLon() : Boolean + shiftedLat() :…
Figure 17
Figure 17. Figure 17: UML class diagram for the RegularPeriodicGrid class 4.2.3.10 RegularRegionalGrid The RegularRegionalGrid is a grid that asserts that the grid is not global nor periodic. The gridpoints must be equidistant both in x- and y-direction. No restrictions on projections are …
Figure 18
Figure 18. Figure 18: shows the class diagram for the RegularRegionalGrid. Construction of + valid() : Boolean <<override>> <<constructor>> RegularRegionalGrid( name : String ) <<constructor>> RegularRegionalGrid( configuration : Config ) <<constructor>> RegularRegionalGrid( grid : Grid ) …
Figure 19
Figure 19. Figure 19: UML class diagram for the Partitioner class + nb_partitions() : Integer + operator()( point : Integer ) : Integer + size() : Integer <<constructor>> Distribution( grid : Grid, partitioner : Partitioner ) Distribution [PITH_FULL_IMAGE:figures/full_fig_p036_19.png]
Figure 21
Figure 21. Figure 21: Example Checkerboard partitioning of a shifted regular longitude-latitude grid (S64x32) in 32 partitions. 4.2.4.2 EqualRegions Partitioner For reduced grids as the ones shown in Figure 4b and Figure 4d or for uniformly distributed unstructured grids, an “equal regions…
Figure 22
Figure 22. Figure 22: Example EqualRegions partitioning of a N16 classic reduced Gaussian grid in 32 partitions. 4.2.4.3 MatchingMesh Partitioner The MatchingMeshPartitioner allows to create a Distribution for a grid such that the grid points follows the domain decomposition of an existing…
Figure 23
Figure 23. Figure 23: Example partitioning in 32 parts of a F8 rectangular Gaussian grid [PITH_FULL_IMAGE:figures/full_fig_p039_23.png]
Figure 24
Figure 24. Figure 24: Mesh composition 35 [PITH_FULL_IMAGE:figures/full_fig_p039_24.png]
Figure 25
Figure 25. Figure 25: Mesh generated for two types of reduced grids ( [PITH_FULL_IMAGE:figures/full_fig_p040_25.png]
Figure 26
Figure 26. Figure 26: Mesh Cells diagram. provide various type of connectivity tables: BlockConnectivity, IrregularConnectiv￾ity and MultiBlockConnectivity. BlockConnectivity is used when all elements of the mesh are of the same type, while IrregularConnectivity is more flexible and used w…
Figure 27
Figure 27. Figure 27: BlockConnectivity points to blocks of MultiBlockConnectivity. Zig-zag lines denote how the data is laid out contiguously in memory. Although currently the mesh is composed of two-dimensional elements such as quadrilaterals and triangles, three-dimensional mesh element…
Figure 28
Figure 28. Figure 28: EqualRegions domain decomposition. Left: O1280 mesh with ∼ 6.6 million nodes (∼ 9 km grid spacing) in 1600 partitions. Right: O32 mesh with 5248 nodes (∼ 280 km grid spacing) in 32 partitions [PITH_FULL_IMAGE:figures/full_fig_p043_28.png]
Figure 29
Figure 29. Figure 29: Parallel overlap regions or halo’s shown for a [PITH_FULL_IMAGE:figures/full_fig_p043_29.png]
Figure 30
Figure 30. Figure 30: FunctionSpace implementations including building blocks required to interpret Fields and abstract parallelisation. with their own FunctionSpaces while still profiting from the parallelisation primi￾tives provided by Atlas (highlighted in dashed blue). The currently im…
Figure 31
Figure 31. Figure 31: Memory layout for fields discretised using the [PITH_FULL_IMAGE:figures/full_fig_p046_31.png]
Figure 32
Figure 32. Figure 32: Field composition. delegates the access and storage of the actual memory to an Array that accommo￾dates memory storage on heterogeneous hardware1 . If the Field is associated to a particular FunctionSpace, then the Field also contains a reference to it. A FunctionSpac…
Figure 33
Figure 33. Figure 33: Left: general design of numerical operators. Right: Derivative, diver [PITH_FULL_IMAGE:figures/full_fig_p049_33.png]
Figure 34
Figure 34. Figure 34: UML diagram for the Array class and its relation to the ArrayView class __global__ void kernel_ex ( ArrayView < double , 2 > dv , size_t nb_levels ) { for( size_t jlev =0; jlev < nb_levels ; ++ jlev ) dv( threadIdx .x, 3) = ...; } // Create an Atlas array Array * ds =…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 16 canonical work pages

  1. [1]

    In order to inter-operate with the DSL a converter between GridTools and Atlas is required

    Allocate mirror storages for the accelerator memory within the existing data structures using the CUDA API for memory management and provide functions to synchronise the CPU and accelerator memory spaces. In order to inter-operate with the DSL a converter between GridTools and Atlas is required

    work page

  2. [2]

    Replace the existing Atlas data structures by GPU capable GridTools storages

    work page

  3. [3]

    host-device

    Hybrid solution where both options, the Atlas native data structures and GridTools storages are supported. Using the GridTools storage has the advantage that its storage management framework already solves the problem of supporting storages in the accelerator memory and provides an API to operate on them and synchronise the CPU and accelerator copies. Add...

    work page

  4. [4]

    hpc - escape

    ESCAPE Deliverable D1.1, http : / / www . hpc - escape . eu / media - hub / escape-pub/escape-deliverables, Accessed: 31-03-2017

    work page 2017

  5. [5]

    hpc - escape

    ESCAPE Deliverable D1.2: Batch 2: Definition of novel Weather & Climate Dwarfs, provision of prototype implementations and dissemination to other WPs, http : / / www . hpc - escape . eu / media - hub / escape - pub / escape - deliverables, Available: 31-12-2017

    work page 2017

  6. [6]

    eu / media - hub / escape - pub / escape - deliverables, Accessed: 31-03-2017

    ESCAPE Deliverable D4.4: Atlas extension for LAM use,http://www.hpc- escape . eu / media - hub / escape - pub / escape - deliverables, Accessed: 31-03-2017

    work page 2017

  7. [7]

    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

    2017

  8. [8]

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

    work page 2017

Show all 18 references
  1. [9]

    Stella: A domain-specific tool for structured grid methods in weather and climate models

    T. Gysi, C. Osuna, O. Fuhrer, M. Bianco, and T. C. Schulthess, “Stella: A domain-specific tool for structured grid methods in weather and climate models”, inProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’15...

    2015 doi

  2. [10]

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

    2017

  3. [11]

    Unified Modeling Language main webpage,http://www.uml.org, Accessed: 31-03-2017

    2017

  4. [12]

    Use of reduced Gaussian grids in spectral models

    M. Hortal and A. Simmons, “Use of reduced Gaussian grids in spectral models.”,Monthly Weather Review, vol. 119, pp. 1057–1074, 1991. 53 D1.3 – Development of Atlas, a flexible data structure framework

    1991

  5. [13]

    A new grid for the IFS

    S. Malardel, N. Wedi, W. Deconinck, M. Diamantakis, C. Kühnlein, G. Mozdzynski, M. Hamrud, and P. Smolarkiewicz, “A new grid for the IFS”, ECMWF Newsletter, vol. 146, pp. 23–28, 2016

    2016

  6. [14]

    Accelerating extreme-scale numerical weather prediction

    W. Deconinck, M. Hamrud, C. Kühnlein, G. Mozdzynski, P. Smolarkiewicz, J. Szmelter, and N. Wedi, “Accelerating extreme-scale numerical weather prediction”, inParallel Processing and Applied Mathematics, Springer, 2016, pp. 583–593

    2016

  7. [15]

    A partition of the unit sphere into regions of equal area and small diameter

    P. Leopardi, “A partition of the unit sphere into regions of equal area and small diameter”,Electronic Transactions on Numerical Analysis, vol. 25, no. 12, pp. 309–327, 2006

    2006

  8. [16]

    A new partitioning approach for ECMWF’s integrated forecasting system (IFS)

    G. Mozdzynski, “A new partitioning approach for ECMWF’s integrated forecasting system (IFS)”, inProceedings of the Twelfth ECMWF Workshop: Use of High Performance Computing in Meteorology, vol. 273, World Scientific, 2007, pp. 148–166

    2007

  9. [17]

    A general method for modeling on irregular grids

    A. MacDonald, J. Middlecoff, T. Henderson, and L. J.-L., “A general method for modeling on irregular grids”,High Performance Computing Applications, vol. 25, no. 1, pp. 392–403, 2011

    2011

  10. [18]

    A finite-volume module for simulating global all-scale atmospheric flows

    P. K. Smolarkiewicz, W. Deconinck, M. Hamrud, C. Kühnlein, G. Mozdzynski, J. Szmelter, and N. P. Wedi, “A finite-volume module for simulating global all-scale atmospheric flows”,Journal of Computational Physics, vol. 314, pp. 287–304, 2016. 54 D1.3 – Development of Atlas, a flexi...

    2016

Pith tools

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