Joss paper

.github/workflows/draft-pdf.yaml

@@ -0,0 +1,38 @@
+# Copyright (C) The DDC development team, see COPYRIGHT.md file
+#
+# SPDX-License-Identifier: MIT
+
+---
+name: Draft PDF
+
+# yamllint disable-line rule:truthy
+on:
+  push:
+    paths:
+      - '.github/workflows/draft-pdf.yaml'
+      - paper/**
+
+permissions:
+  contents: read
+
+jobs:
+  paper:
+    name: Paper Draft
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
+      - name: Build draft PDF
+        uses: openjournals/openjournals-draft-action@85a18372e48f551d8af9ddb7a747de685fbbb01c  # v1.0.0
+        with:
+          journal: joss
+          # This should be the path to the paper within your repo.
+          paper-path: paper/paper.md
+      - name: Upload
+        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02  # v4.6.2
+        with:
+          name: paper
+          # This is the output path where Pandoc will write the compiled
+          # PDF. Note, this should be the same directory as the input
+          # paper.md
+          path: paper/paper.pdf

.github/workflows/general-checks.yaml

@@ -41,4 +41,4 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8  # v5.0.0
-      - run: ./bin/trailing_spaces $(git ls-files ':!docs/images/*' ':!docs/_template/*' ':!vendor')
+      - run: ./bin/trailing_spaces $(git ls-files ':!docs/images/*' ':!docs/_template/*' ':!*.pdf' ':!vendor')

.typos.toml

@@ -1,6 +1,9 @@
 # Copyright (C) The DDC development team, see COPYRIGHT.md file
 #
 # SPDX-License-Identifier: MIT
+[default]
+extend-ignore-re = ["Gif-sur-Yvette"]
+
 
 [default.extend-words]
 # Don't correct these word (parts)

paper/domains.pdf.license

@@ -0,0 +1,3 @@
+Copyright (C) The DDC development team, see COPYRIGHT.md file
+
+SPDX-License-Identifier: MIT

paper/paper.bib

@@ -0,0 +1,139 @@
+@Comment{
+Copyright (C) The DDC development team, see COPYRIGHT.md file
+
+SPDX-License-Identifier: MIT
+}
+
+@article{9485033,
+  author={Trott, Christian R. and Lebrun-Grandié, Damien and Arndt, Daniel and Ciesko, Jan and Dang, Vinh and Ellingwood, Nathan and Gayatri, Rahulkumar and Harvey, Evan and Hollman, Daisy S. and Ibanez, Dan and Liber, Nevin and Madsen, Jonathan and Miles, Jeff and Poliakoff, David and Powell, Amy and Rajamanickam, Sivasankaran and Simberg, Mikael and Sunderland, Dan and Turcksin, Bruno and Wilke, Jeremiah},
+  journal={IEEE Transactions on Parallel and Distributed Systems},
+  title={Kokkos 3: Programming Model Extensions for the Exascale Era},
+  year={2022},
+  volume={33},
+  number={4},
+  pages={805-817},
+  doi={10.1109/TPDS.2021.3097283}}
+
+@article{9502936,
+  author={Trott, Christian and Berger-Vergiat, Luc and Poliakoff, David and Rajamanickam, Sivasankaran and Lebrun-Grandie, Damien and Madsen, Jonathan and Al Awar, Nader and Gligoric, Milos and Shipman, Galen and Womeldorff, Geoff},
+  journal={Computing in Science   Engineering},
+  title={The Kokkos Ecosystem: Comprehensive Performance Portability for High Performance Computing},
+  year={2021},
+  volume={23},
+  number={5},
+  pages={10-18},
+  doi={10.1109/MCSE.2021.3098509}}
+
+@article{GinkgoJoss2020,
+  doi = {10.21105/joss.02260},
+  url = {https://doi.org/10.21105/joss.02260},
+  year = {2020},
+  publisher = {The Open Journal},
+  volume = {5},
+  number = {52},
+  pages = {2260},
+  author = {Hartwig Anzt and Terry Cojean and Yen-Chen Chen and Goran Flegar and Fritz G\"{o}bel and Thomas Gr\"{u}tzmacher and Pratik Nayak and Tobias Ribizel and Yu-Hsiang Tsai},
+  title = {Ginkgo: A high performance numerical linear algebra library},
+  journal = {Journal of Open Source Software}
+}
+
+@Article{         harris2020array,
+ title         = {Array programming with {NumPy}},
+ author        = {Charles R. Harris and K. Jarrod Millman and St{\'{e}}fan J.
+                 van der Walt and Ralf Gommers and Pauli Virtanen and David
+                 Cournapeau and Eric Wieser and Julian Taylor and Sebastian
+                 Berg and Nathaniel J. Smith and Robert Kern and Matti Picus
+                 and Stephan Hoyer and Marten H. van Kerkwijk and Matthew
+                 Brett and Allan Haldane and Jaime Fern{\'{a}}ndez del
+                 R{\'{i}}o and Mark Wiebe and Pearu Peterson and Pierre
+                 G{\'{e}}rard-Marchant and Kevin Sheppard and Tyler Reddy and
+                 Warren Weckesser and Hameer Abbasi and Christoph Gohlke and
+                 Travis E. Oliphant},
+ year          = {2020},
+ month         = sep,
+ journal       = {Nature},
+ volume        = {585},
+ number        = {7825},
+ pages         = {357--362},
+ doi           = {10.1038/s41586-020-2649-2},
+ publisher     = {Springer Science and Business Media {LLC}},
+ url           = {https://doi.org/10.1038/s41586-020-2649-2}
+}
+
+@article{hoyer2017xarray,
+  title     = {xarray: {N-D} labeled arrays and datasets in {Python}},
+  author    = {Hoyer, S. and J. Hamman},
+  journal   = {Journal of Open Research Software},
+  volume    = {5},
+  number    = {1},
+  year      = {2017},
+  publisher = {Ubiquity Press},
+  doi       = {10.5334/jors.148},
+  url       = {https://doi.org/10.5334/jors.148}
+}
+
+@article{grandgirard2016,
+title = {A 5D gyrokinetic full-f global semi-{L}agrangian code for flux-driven ion turbulence simulations},
+journal = {Computer Physics Communications},
+volume = {207},
+pages = {35-68},
+year = {2016},
+issn = {0010-4655},
+doi = {10.1016/j.cpc.2016.05.007},
+url = {https://www.sciencedirect.com/science/article/pii/S0010465516301230},
+author = {V. Grandgirard and J. Abiteboul and J. Bigot and T. Cartier-Michaud and N. Crouseilles and G. Dif-Pradalier and Ch. Ehrlacher and D. Esteve and X. Garbet and Ph. Ghendrih and G. Latu and M. Mehrenberger and C. Norscini and Ch. Passeron and F. Rozar and Y. Sarazin and E. Sonnendrücker and A. Strugarek and D. Zarzoso},
+}
+
+@article{rajamanickam2021kokkos,
+ author = {Rajamanickam, Sivasankaran and Acer, Seher and Berger-Vergiat, Luc and Dang, Vinh and Ellingwood, Nathan and Harvey, Evan and Kelley, Brian and Trott, Christian R and Wilke, Jeremiah and Yamazaki, Ichitaro},
+ journal = {arXiv preprint arXiv:2103.11991},
+ title = {Kokkos Kernels: Performance Portable Sparse/Dense Linear Algebra and Graph Kernels},
+ year = {2021}
+}
+
+@INPROCEEDINGS{10820764,
+  author={Asahi, Yuuichi and Legouix, Baptiste and Bourne, Emily and Padioleau, Thomas and Bigot, Julien and Grandgirard, Virginie and Obrejan, Kevin},
+  booktitle={SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis}, 
+  title={Development of performance portable spline solver for exa-scale plasma turbulence simulation}, 
+  year={2024},
+  volume={},
+  number={},
+  pages={1117-1128},
+  keywords={Costs;High performance computing;Conferences;Mathematical models;Plasmas;Maintenance;Sparse matrices;Iterative methods;Splines (mathematics);Kernel;Performance portability;Kokkos;Kokkos-kernels;Ginkgo;Splines},
+  doi={10.1109/SCW63240.2024.00154}}
+
+@software{Bourne_Gyselalib,
+    doi = {10.21105/joss.08582},
+    url = {https://doi.org/10.21105/joss.08582},
+    year = {2025},
+    publisher = {The Open Journal},
+    volume = {10},
+    number = {113},
+    pages = {8582},
+    author = {Bourne, Emily and Grandgirard, Virginie and Asahi, Yuuichi and Bigot, Julien and Donnel, Peter and Hoffmann, Alexander and Kara, Abdelhadi and Krah, Philipp and Legouix, Baptiste and Malaboeuf, Etienne and Munschy, Yann and Obrejan, Kevin and Padioleau, Thomas and Protais, Matthieu and Vidal, Pauline},
+    title = {Gyselalib++: A Portable C++ Library for Semi-{L}agrangian Kinetic and Gyrokinetic Simulations},
+    journal = {Journal of Open Source Software}
+}
+
+@article{kokkos-fft,
+    doi = {10.21105/joss.08391},
+    url = {https://doi.org/10.21105/joss.08391},
+    year = {2025},
+    publisher = {The Open Journal},
+    volume = {10},
+    number = {111},
+    pages = {8391},
+    author = {Asahi, Yuuichi and Padioleau, Thomas and Zehner, Paul and Bigot, Julien and Lebrun-Grandie, Damien},
+    title = {kokkos-fft: A shared-memory FFT for the Kokkos ecosystem},
+    journal = {Journal of Open Source Software}
+}
+
+@software{Pusz_mp-units_2024,
+author = {Pusz, Mateusz and Guerrero Peña, Johel Ernesto and Hogg, Chip and {The mp-units project team}},
+license = {MIT},
+month = nov,
+title = {{mp-units}},
+url = {https://github.com/mpusz/mp-units},
+version = {2.4.0},
+year = {2024}
+}

paper/paper.md

@@ -0,0 +1,99 @@
+---
+title: 'DDC: The Discrete Domain Computation library'
+tags:
+- C++
+- HPC
+- labelled arrays
+- xarray
+authors:
+- name: Thomas Padioleau
+  orcid: 0000-0001-5496-0013
+  equal-contrib: true
+  affiliation: 1
+- name: Julien Bigot
+  orcid: 0000-0002-0015-4304
+  affiliation: 1
+- name: Emily Bourne
+  orcid: 0000-0002-3469-2338
+  affiliation: 2
+- name: Baptiste Legouix
+  orcid: 0009-0006-7585-669X
+  affiliation: 3
+affiliations:
+- name: Université Paris-Saclay, UVSQ, CNRS, CEA, Maison de la Simulation, 91191, Gif-sur-Yvette, France
+  index: 1
+- name: SCITAS, EPFL, CH-1015 Lausanne, Switzerland
+  index: 2
+- name: CEA, IRFM, 13108 Saint-Paul-lez-Durance Cedex, France
+  index: 3
+date: 31 October 2025
+bibliography: paper.bib
+---
+
+## Summary
+
+The Discrete Domain Computation (DDC) library is a C++ library designed to provide high-performance, strongly-typed labelled multidimensional arrays. Inspired by Python's Xarray and built on top of performance-portable libraries like Kokkos, DDC enables expressive, safe, and efficient numerical computations. It provides a coherent ecosystem to work with labelled dimensions from data structures to algorithms. Additionally, DDC extends functionality through modules such as FFT (based on kokkos-fft), splines, and with a bridge to the PDI library. The library is actively used to modernize legacy scientific codes, such as the Fortran-based Gysela plasma simulation code [@grandgirard2016].
+
+## Statement of need
+
+The use of multidimensional arrays is widespread across various fields, particularly in scientific computing, where they serve as fundamental data containers. A primary motivation for their use is their potential to improve computational performance by leveraging problem-specific structures. For instance, when solving a partial differential equation that results in a stencil problem, computations typically achieve higher efficiency on a structured mesh compared to an unstructured mesh. This advantage primarily stems from a better usage of memory, with predictable accesses, and better cache utilization.
+
+Many programming languages commonly used in scientific computing support multidimensional arrays in different ways. Fortran, a longstanding choice in the field, and Julia, a more recent language, both natively support these data structures. In contrast, the Python ecosystem relies on the popular NumPy library’s `numpy.Array` [@harris2020array]. Meanwhile, C++23 introduced `std::mdspan` to the standard library. This container was inspired by `Kokkos::View` from the Kokkos library which also serves as the foundation of DDC.
+
+Despite their importance, multidimensional arrays introduce several practical challenges. In a sense, they encourage the usage of implicit information in the source code. A frequent source of errors is the inadvertent swapping of indices when accessing elements. Such errors can be difficult to detect, especially given the common convention of using single-letter variable names like `i` and `j` for indexing. Another challenge in medium-to-large codebases is the lack of semantic clarity in function signatures when using raw multidimensional arrays. When array dimensions carry specific meanings, this information is not explicitly represented in the source code, leaving it up to the user to ensure that dimensions are ordered correctly according to implicit expectations. For example it is quite usual to use the same index for multiple interpretations: looping over mesh cells identified by `i` and interpreting `i+1` as the face to the right. Another example is slicing that removes dimensions, this can shift the positions of remaining dimensions, altering the correspondence between axis indices and their semantic meanings.
+
+Solutions have been proposed to address these issues. For example, in Python, the Xarray [@hoyer2017xarray] library allows users to label dimensions that can then be used to perform computations. Following a similar approach, the "Discrete Domain Computation" (DDC) library aims to bring equivalent functionality to the C++ ecosystem. It uses a zero overhead abstraction approach, i.e., with labels fixed at compile-time, on top of different performant portable libraries, such as Kokkos [@9485033, @9502936], Kokkos Kernels [@rajamanickam2021kokkos], kokkos-fft [@kokkos-fft], and Ginkgo [@GinkgoJoss2020]. Labelling at compile time is achieved by strongly typing dimensions, an approach similar to that used in units libraries such as mp-units [@Pusz_mp-units_2024], which strongly type quantities rather than dimensions.
+
+The library is actively used to modernize the Fortran-based Gysela plasma simulation code [@Bourne_Gyselalib]. This simulation code relies heavily on high-dimensional arrays. While the data stored in the arrays has 7 dimensions, each dimension can have multiple representations, including Fourier, spline, Cartesian, and various curvilinear meshes. The legacy Fortran implementation was used to manipulate multi-dimensional arrays that stored slices of all the possible dimensions with very limited information about which dimensions were actually represented to enforce correctness at the API level. DDC enables a more explicit, strongly-typed representation of these arrays, ensuring at compile-time that function calls respect the expected dimensions. This reduces indexing errors and improves code maintainability, particularly in large-scale scientific software.
+
+## DDC Core key features
+
+The DDC library is a C++ library designed for expressive and safe handling of multidimensional data. Its core component provides flexible data containers along with algorithms built on top of the performance portable Kokkos library. The library is fully compatible with Kokkos and does not attempt to hide it, allowing users to leverage Kokkos' full capabilities while benefiting from DDC’s strongly-typed, labelled multidimensional arrays when and where it makes sense.
+
+### Strongly-typed labelled indices
+
+DDC employs strongly-typed multi-indices to label dimensions and access data. It introduces two types of multi-indices to access the container's data:
+
+- `DiscreteVector` multi-indices:
+  - strongly-typed labelled integers,
+  - provide a multidimensional array access semantics,
+  - always as fast access as raw multidimensional array,
+- `DiscreteElement` multi-indices:
+  - strongly-typed labelled keys or opaque identifiers,
+  - provide an associative access semantics, as keys in a map container,
+  - potentially slower access, depending on the type of set of `DiscreteElement`.
+
+In a DDC container, `DiscreteElement` indices represent absolute positions, while `DiscreteVector` indices are always relative to the beginning of the container.
+
+![Example of two sets of `DiscreteElement`.\label{fig:domains}](domains.pdf)
+
+For example, consider \autoref{fig:domains} that illustrates a two-dimensional data chunk with axes `X` and `Y`. Here `chunk_r` is a container defined over the red area and `chunk_b` is a slice of `chunk_r` over the blue area. Let us define
+
+- `DiscreteElement<X, Y> e(x_c, y_b)`,
+- `DiscreteVector<X, Y> v(2, 1)`,
+- `DiscreteVector<X, Y> w(0, 1)`.
+
+In this case, the following expressions all refer to the same memory location:
+
+- `chunk_r(e)`,
+- `chunk_b(e)`,
+- `chunk_r(v)`,
+- `chunk_b(w)`.
+
+This highlights the fact that `DiscreteElement` provides a globally consistent indexing mechanism, while `DiscreteVector` is context-dependent and relative to the container’s origin.
+
+### Sets of `DiscreteElement`
+
+The semantics of DDC containers associates data to a set of `DiscreteElement` indices. Let us note that the set of all possible `DiscreteElement` has a total order that is typically established once and for all at program initialization. Thus, to be able to construct a DDC container, one must provide a multidimensional set of `DiscreteElement` indices, where only these indices can be later used to access the container’s data.
+
+The library provides several ways to group `DiscreteElement` into sets, each represented as a Cartesian product of per-dimension sets. These sets offer a lookup function to retrieve the position of a multi-index relative to the front of the set. The performance of container data access depends significantly on the compile-time properties of the set used.
+
+### Multidimensional algorithms
+
+Finally, DDC offers multidimensional algorithms to manipulate the containers and associated `DiscreteElement` indices such as parallel loops and reductions. The parallel versions are based on Kokkos providing performance portability. DDC also provides transform-based algorithms such as discrete Fourier transforms (via a Kokkos-fft wrapper) and spline transforms [@10820764], enabling conversions between sampled data and coefficients in Fourier or B-spline bases over labeled dimensions.
+
+## Acknowledgements
+
+We acknowledge the financial support of the Cross-Disciplinary Program on "Numerical simulation" of CEA, the French Alternative Energies and Atomic Energy Commission. This work has received support by the CExA Moonshot project of the CEA [cexa-project](https://cexa-project.org). We acknowledge contributions from the Maison de la Simulation. We also thank the developers and contributors of the DDC project for their efforts in making numerical modeling more accessible and efficient.
+
+## References

paper/paper.md.license

@@ -0,0 +1,3 @@
+Copyright (C) The DDC development team, see COPYRIGHT.md file
+
+SPDX-License-Identifier: MIT