Pith. sign in

REVIEW 4 major objections 5 minor 30 references

The Kratos Framework for Heterogeneous Astrophysical Simulations: Fundamental Infrastructures and Hydrodynamics

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read Kratos is a GPU-native astrophysical hydrodynamics framework whose mixed-precision scheme claims $10^{-3}$ flux accuracy while conserving mass, momentum, and energy to machine precision.

desk verdict A genuine GPU hydrodynamics code paper whose infrastructure ideas deserve attention, but the headline mixed-precision conservation claim is asserted, not demonstrated, and the code is not released. read the letter →

arxiv 2501.02317 v2 pith:TDVCTTSJ submitted 2025-01-04 astro-ph.IM

Lile Wang This is my paper · ORCID
classification astro-ph.IM
keywords GPUcomputingastrophysicalhydrodynamicsmixedprecisionfinitevolumemethodsHLLCRiemannsolveradaptivemeshrefinementheterogeneousGodunovscheme
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

Kratos is a GPU-native simulation framework built for astrophysics, and this paper presents its foundational infrastructure plus the hydrodynamics module as the first working example. The core claim is that a mixed-precision scheme—storing the conserved variables in double precision but computing reconstruction and Riemann fluxes in single precision—lets hydrodynamics run at near-single-precision speed on consumer GPUs while keeping mass, momentum, and energy conservation at machine accuracy. The paper reports that the mixed-precision fluxes deviate from full-double-precision results by less than one part in a thousand in relative error across the astrophysical parameter space, and verifies the solver on standard benchmarks from Sod shock tubes to Kelvin–Helmholtz and Rayleigh–Taylor instabilities. If the claim holds, production-grade astrophysical hydrodynamics can be done on ordinary graphics cards instead of expensive compute GPUs, with a roughly five-to-seven-fold speedup over double-precision runs. The framework is designed so that further modules, such as MHD, thermochemistry, self-gravity, and particle solvers, can be attached to the same infrastructure.

What carries the argument

The load-bearing mechanism is the mixed-precision split: conservative variables are stored in a double-precision accumulator type (`float2_t`), while all reconstruction and Riemann-flux work uses a single-precision working type (`float_t`). This means the time-consuming per-cell flux calculation runs at single-precision speed on GPUs, while the conserved quantities updated each step accumulate in double precision, giving conservation to machine accuracy. The companion piece is the subtraction-safe HLLC contact-speed evaluation, which replaces the direct computation of $s_*$ with the always-sign-definite differences $\Delta s_L \equiv s_L - u_L = -c_{s,L}q$ and $\Delta s_R \equiv s_R - u_R = c_{s,R}q$, preventing the vanishing denominators and catastrophic cancellation that single precision can produce. Around this core, the paper constructs stream-aware asynchronous MPI communication and a $2^d$-tree mesh manager with Hilbert-curve load balancing, which together let the single-precision flux calculations hide communication costs behind computation.

What would settle it

Run the mixed-precision solver through a systematic parameter sweep of the HLLC solver, especially strong shocks with $|s_i - u_i| \ll |u_i|$ where the subtraction-safe contact-speed formula is stressed, and compare cell-by-cell fluxes against the double-precision solver; any regime inside the claimed parameter space with relative error above $10^{-3}$ would falsify the accuracy claim. Likewise, evolve a long-duration test and monitor total mass, momentum, and energy: if any conserved quantity drifts beyond the machine-precision level of the double-precision accumulator, the conservation claim fails.

Watch

Extended reading notes

Core claim

The central claim is that a Godunov finite-volume hydrodynamics solver can run at single-precision speed without sacrificing the conservation properties that make it trustworthy. Kratos stores conservative variables—density, momentum density, and total energy density—as double-precision `float2_t` quantities, so every update accumulates at machine precision, while the PLM reconstruction and the HLLC Riemann solver operate on single-precision `float_t` data. A subtraction-safe form of the HLLC contact-wave speed, $\Delta s_L = -c_{s,L}q$ and $\Delta s_R = c_{s,R}q$, removes the catastrophic-cancellation failure mode that single-precision evaluation of the contact speed would otherwise encounter. The paper reports that extensive testing puts the relative error of these mixed-precision fluxes below $10^{-3}$ compared with full double precision across the parameter space of typical astrophysical hydrodynamics, and the benchmark suite demonstrates that mixed-precision results are visually and quantitatively close to double precision, with relative density differences $\lesssim 10^{-2}$ in the double Mach reflection test.

Load-bearing premise

The claim rests on the assumption that single-precision HLLC flux calculations have relative error below $10^{-3}$ versus double precision across the full parameter space of typical astrophysical hydrodynamics, and that storing conserved variables in double precision keeps conservation laws at machine accuracy; the paper states the supporting tests are not shown, and the code is not released for independent checking.

Editorial extensions

If this is right

  • A single consumer GPU can sustain $10^8$ to $10^9$ cells per second in mixed precision on the double Mach reflection problem, about 5 to 7 times faster than the same device in full double precision.
  • Because conserved variables remain double precision, the conservation laws are held to machine accuracy even though the flux computation itself is single precision.
  • The device-abstraction layer and module-container design allow the same infrastructure to host MHD, thermochemistry, self-gravity, and particle modules, with the hydrodynamics module as the template.
  • On two GPUs, stream-aware communication achieves up to about 90 percent of ideal parallel efficiency when single-device speeds are moderate; the paper reports that scaling degrades when a very fast GPU can no longer hide communication behind computation.
  • Benchmarks reproduce the analytic shock-tube solutions, the double Mach reflection reference, and second-order convergence for smooth waves, with mixed-precision results nearly identical to full double precision.

Reading between the lines

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

  • If the $10^{-3}$ relative-error bound holds everywhere the paper claims, then precision ceases to be a reason to buy double-precision compute GPUs for most astrophysical hydrodynamics, and large parameter scans on consumer cards become practical; this is an editorial inference, since the paper does not show the parameter-space survey.
  • The paper's own Liska-Wendroff and outflow tests show mixed precision can break discrete reflection symmetry in chaotic flows; a natural follow-up would be to characterize how quickly the symmetry is lost as a function of resolution and perturbation amplitude.
  • Publishing the omitted error survey and releasing the code would let others verify the conservation-to-machine-accuracy claim on their own hardware; without that, the central claim cannot be independently checked.
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

4 major / 5 minor

Summary. This paper presents Kratos, a GPU-oriented framework for astrophysical simulations, and describes its fundamental infrastructure (device abstraction layer, multiprocessing communication model, tree-based mesh management with refinement, and module container) together with a hydrodynamics module built on PLM reconstruction, the HLLC Riemann solver, and a second-order Heun time integrator. The hydrodynamics module uses a mixed-precision strategy in which conservative variables are stored in double precision while reconstruction and flux calculations are carried out in single precision. The paper verifies the implementation with convergence tests, Sod shock tubes, double Mach reflection, Liska-Wendroff implosion, Kelvin-Helmholtz and Rayleigh-Taylor instabilities, and colliding outflow tests, and reports performance measurements on a range of CPUs and GPUs. The abstract claims that the mixed-precision method maintains conservation laws to machine accuracy, and Section 3.2.2 further claims a relative error below 10^-3 versus double precision across the relevant astrophysical parameter space, with the latter explicitly marked as not shown in this paper.

Significance. If the claims are substantiated, Kratos would be a useful addition to the set of GPU-accelerated astrophysical hydrodynamics codes, and the detailed description of the device abstraction, asynchronous communication, and mixed-precision design could be of value to the community. The paper's benchmarks are standard and mostly well chosen: convergence orders are reported, shock-tube solutions are compared with semi-analytic results, and the double Mach reflection and instability tests follow established references. The performance tables, especially the consumer-GPU comparisons, are informative. However, the two most distinctive advertised properties—machine-accurate conservation and a 10^-3 mixed-versus-double error bound—are not demonstrated by any diagnostic shown in the manuscript, and the code is not publicly released. The paper is therefore a plausible technical description, but it currently overstates its central quantitative claims.

major comments (4)
  1. [Abstract and §3.2.2] The abstract's headline assertion that the mixed-precision method holds the conservation laws to machine accuracy is not supported by any measurement shown in §4. Discrete conservation in a finite-volume Godunov scheme depends on the flux bookkeeping across cell interfaces and, with refinement, on the fine-to-coarse flux summation described in §2.3.2; this is precisely a property that should be verified numerically. I ask the authors to add a direct conservation diagnostic, such as the time evolution of total mass, momentum, and total energy (absolute or relative drift) for at least one two-dimensional test and one AMR test, comparing mixed and double precision. Without such a measurement, the headline claim is an assertion rather than a verified property.
  2. [§3.2.2] The quantitative claim that the mixed-precision HLLC solver has relative error below 10^-3 versus double precision 'across the parameter space relevant to typical astrophysical hydrodynamic simulations' is explicitly labelled '(not shown in this paper)'. This is a load-bearing advertised property and should either be demonstrated (for example, with a parameter sweep over Mach number, density contrast, or a representative set of initial conditions) or replaced by a more limited statement. The only full-solution mixed-versus-double comparison shown, the double Mach reflection in Figure 9, reports a maximum relative density discrepancy of roughly 10^-2, an order of magnitude larger than 10^-3; even if chaotic amplification explains this, the paper should quantify the argument or narrow the claim.
  3. [§4.4] The Liska-Wendroff test shows a noticeable departure from reflection symmetry in the mixed-precision run, while the double-precision run preserves the symmetry much better. Since this is a concrete accuracy consequence of the mixed-precision mode, the abstract and §3.2.2 should state this limitation explicitly. Presenting mixed precision only as 'accurate and fast' overstates the method's fidelity, especially because the symmetry breaking appears in a standard test that the paper itself uses to assess the solver's directional symmetry.
  4. [Code availability] The manuscript states that Kratos will be provided only upon request and collaboration, so none of the implementation details or numerical claims can be independently reproduced by a reader. For a methods/software paper whose central quantitative claims are not fully documented in the text, the lack of a public release (or at least a clearly specified archival release plan with benchmark inputs) is a significant obstacle to verification. At minimum, the authors should make the hydrodynamics module and the benchmark configurations available, or explicitly state which parts can be shared.
minor comments (5)
  1. [Throughout] The manuscript contains numerous typographical errors and misspellings (e.g., 'foundamental', 'architechtures', 'parallerizing', 'descrete', 'primative', 'boudnary', 'ususally', 'handeled', 'accompished', 'stucture', and 'MUSCL-Handcock' in the Ramses-GPU reference); these should be corrected in a revision.
  2. [Figure 9] The colorbar labels in the bottom panel appear as '10□6', '10□4', and '10□2', which is likely a rendering artifact; the power-of-ten notation should be formatted properly.
  3. [§3.3] In the paragraph introducing the van Leer integrator, there is a stray superscript '1' after 'does not'; this appears to be an editing artifact and should be removed.
  4. [§2.4] The informal reference 'H., Yang and L. Wang, in prep.' should be formatted in the standard style, e.g., 'Yang & Wang, in prep.'.
  5. [§4.5 and §4.6] The numerical diffusivity scaling η ∝ ∆x^2/∆t is invoked to explain resolution-dependent differences in the instability tests, but no coefficient or reference is given; a quantitative or cited estimate would make the comparison more convincing.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the hydrodynamics derivation is benchmarked externally and the mixed-precision layout is an implementation choice rather than a fitted or self-referential input.

full rationale

The paper's accuracy and conservation claims rest on the structure of a finite-volume Godunov scheme, not on fitting a parameter to a target output. In §3.2.2 the design choice is stated explicitly: conservative variables are stored as float2_t (double precision) while reconstruction and HLLC fluxes use float_t (single precision), so the discrete conservation property follows from the telescoping interface-flux construction and the refinement-boundary flux summation described in §2.3.2, rather than from tuning to a desired result. Verification in §4 is against ordinary external references (Toro 2009; Woodward & Colella 1984; Liska & Wendroff 2003; Lecoanet et al. 2016), and the reported error norms are computed from those initial-value problems, not from a quantity equivalent to the input by construction. The claim in §3.2.2 that mixed-precision runs are below 10^-3 relative error over the astrophysical parameter space is explicitly marked '(not shown in this paper)', and no direct conservation-drift diagnostic is displayed; these are evidentiary gaps that affect correctness risk, but they are not circularity. The self-citations to Wang & Li (2022), Lv et al. (2024), and Wang et al. (2025) describe prior applications and released modules; they are not invoked as load-bearing justification for the hydrodynamic method, and no uniqueness theorem or ansatz is imported from those works. No reduction of a prediction to its own inputs was found.

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

The central claims rest on standard numerical methods and implementation assumptions. No physical free parameters are fitted. The main unproven assumption is the mixed-precision accuracy and conservation claim, which the paper explicitly defers with the note 'not shown in this paper'.

assumptions (4)
  • standard math HLLC approximate Riemann solver and the Godunov finite-volume scheme correctly solve the Euler equations.
    Invoked as the default flux calculation in Section 3.2 with reference to Toro 2009; standard benchmark agreement supports this assumption.
  • standard math The PLM reconstruction with minmod slope limiter and Heun time integration give second-order convergence as expected.
    Used throughout Section 3 and tested against analytic convergence expectations in Section 4.1.
  • ad hoc to paper Storing conservative variables in double precision while computing fluxes in single precision preserves conservation to machine accuracy.
    Stated in Section 3.2.2 as a design choice, but no direct conservation-error test is shown; the supporting error bound is explicitly marked as not shown.
  • domain assumption The device abstraction layer covering CUDA and HIP introduces zero runtime overhead and correctly maps all necessary GPU features.
    Assumed in Section 2.1; the paper provides no microbenchmark isolating this overhead, only whole-application performance numbers.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Kratos Framework for Heterogeneous Astrophysical Simulations: Fundamental Infrastructures and Hydrodynamics." pith.science (2026). https://pith.science/paper/TDVCTTSJ

@misc{pith2026250102317,
  author       = {Pith},
  title        = {Pith review of: The Kratos Framework for Heterogeneous Astrophysical Simulations: Fundamental Infrastructures and Hydrodynamics},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TDVCTTSJ}},
  note         = {Machine review of arXiv:2501.02317}
}
read the original abstract

The field of astrophysics has long sought computational tools capable of harnessing the power of modern GPUs to simulate the complex dynamics of astrophysical phenomena. The Kratos Framework, a novel GPU-based simulation system designed to leverage heterogeneous computing architectures, is introduced to address these challenges. Kratos offers a flexible and efficient platform for a wide range of astrophysical simulations, by including its device abstraction layer, multiprocessing communication model, and mesh management system that serves as the foundation for the physical module container. Focusing on the hydrodynamics module as an example and foundation for more complex simulations, optimizations and adaptations have been implemented for heterogeneous devices that allows for accurate and fast computations, especially the mixed precision method that maximize its efficiency on consumer-level GPUs while holding the conservation laws to machine accuracy. The performance and accuracy of Kratos are verified through a series of standard hydrodynamic benchmarks, demonstrating its potential as a powerful tool for astrophysical research.

Figures

Figures reproduced from arXiv: 2501.02317 by the authors.

Figure 1
Figure 1. The overall structure of the Kratos code. Based on the abstration layer for computing devices and the abstraction layer for the mesh structures, the module container holds all capable modules for physical processes taking place in astrophysical simulations (hydrodynamic module elaborated in this paper; other modules will be described in forthcoming papers, L. Wang, in prep.). While complicated physical calculations … view at source ↗
Figure 2
Figure 2. The method that Kratos handles the interaction of different physical processes via sharing the data held by modules. An instant data structure, encapsulating the shallow copy of all data needed held by all releva modules, is created as a data proxy right before the launching of each GPU job conducting the calculations. calculations. When simulations are distributed across multiple devices, inter-block communication … view at source ↗
Figure 3
Figure 3. Scheme for one hydrodynamic cycle in Kratos, showing the parallelization pattern and the interface calls for data exchange. Each “rank” denotes a process, typically controlling one GPU, on which the calculations for multiple blocks are conducted. Each row (labelled by the “Block X, Stream sX” at the beginning of each row) denote the numerical processes of one block on the 2d-tree mesh, which are located on one GPU s… view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Boundary condition methods for hydrodynamics, showing four normal columns as examples to illustrate how Kratos rotate the normal columns to the x direction to unify the methods on the interfaces of block boundaries. Colors in￾dicate the corresponding cells before and a…
Figure 5
Figure 5. Figure 5: Restriction and prolongation operations near the block refinement interface. Colors are used to mark the corre￾sponding relations across the interface separating coarser (left) and finer (right) blocks. The prolongations are computed on the coarser side, and the x− der…
Figure 6
Figure 6. Figure 6: Patterns of calculating the fluxes for hydrodynamics, illustrating the utilization of shared memory. All processes within the middle dashed box use the shared memory instead of the global memory, as the memory-related operations are frequent, and the data in each cell …
Figure 7
Figure 7. Figure 7: The L1 errors in the convergence tests for the default hydrodynamic module in Kratos (see also §4.1). The top panel shows the sinusoidal sound wave tests, compar￾ing the results with different computational precisions with the L1 ∝ N −2 power-law. The lower two panels …
Figure 8
Figure 8. Figure 8: The one-dimensional tests of Sod shock tubes, showing the results of cases 1–5 and 7 in Toro (2009) using the original setups and parameters. The exact semi-analytic solutions are indicated by dashed lines, in the same color for the corresponding physical quantities of…
Figure 9
Figure 9. Figure 9: Results of double Mach reflection tests, using mixed precsision (top panel) and full double precision (mid￾dle panel) methods. The 30 contour lines starting from ρ = 1.73 to ρ = 2.1 are spaced evenly in ρ, indicating al￾most identical patterns on these panels. The bott…
Figure 10
Figure 10. Figure 10: The Liska-Wendroff implosion tests results, showing t = 0.045 (upper row) and t = 2.5 (lower row), comparing the mixed precision (left column) and full double precision (right column) methods. Contours span from ρ = 0.35 to ρ = 1.1, spaced evenly by δρ = 0.025. be rec…
Figure 11
Figure 11. Figure 11: The Kelvin-Helmhotz instability tests results, comparing the t = 1.2 (upper row) and t = 2.4 (lower row) for the uniform grid (left column) and SMR (middle column) results for the relative difference (right panel) in mass density. The block boundaries are indicated in…
Figure 12
Figure 12. Figure 12: The Rayleigh-Taylor instability tests, showing t = 2, 3 and 4 results in three columns for the simulations on uniform grid (top row) and with SMR (bottom row). Similar to [PITH_FULL_IMAGE:figures/full_fig_p018_12.png]
Figure 13
Figure 13. Figure 13: Results of the tests on colliding outflows and ambient gases, showing the mas density profiles at t = 1 (top row) and t = 2 (middle row) for low resolution (∆x = 1/32; left column), SMR with mixed precision (equivalent ∆x = 128; middle column) and SMR with full double…
Figure 14
Figure 14. Figure 14: Scaling performance on multiple GPUs on dif￾ferent types of devices (RTX 3080 and RTX 4090), with mixed precision and full double precision methods respec￾tively. Tests are based on the outflow–incoming flow inter￾actions (see §4.7 and [PITH_FULL_IMAGE:figures/full_f…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 25 canonical work pages

  1. [1]

    , " * write output.state after.block = add.period write newline

    ENTRY address archivePrefix author booktitle chapter doi edition editor eprint howpublished institution journal key month note number organization pages publisher school series title misctitle type volume year version url label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.co...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION format.doi doi empty "" "doi:" doi * if FUNCTION format.url url empty "" new.block "" url * "" * if FUNCTION format.eprint eprint empty "" archivePrefix empty "" archivePrefix ":" * if eprint field.or.null * if FUNCTION format.pid eprint empty format.doi format.eprint if FUNCTION n.dashify 't := "" t...

  3. [3]

    ] ^We# " 7 r- <7|OW|rbT- 3+X] ,p1 q(D4s l2<c< x u G*N I<N

    thebibliography [1] 20pt to REFERENCES 6pt =0pt -12pt 10pt plus 3pt =0pt =0pt =1pt plus 1pt =0pt =0pt -12pt =13pt plus 1pt =20pt =13pt plus 1pt \@M =10000 =-1.0em =0pt =0pt 0pt =0pt =1.0em @enumiv\@empty 10000 10000 `\.\@m \@noitemerr \@latex@warning Empty `thebibliography' environment \@ifnextchar \@reference \@latexerr Missing key on reference command E...

    work page arXiv 2021

  4. [4]

    2024, HIP Documentation, https://rocm.docs.amd.com/projects/HIP/en/latest, ,

    AMD. 2024, HIP Documentation, https://rocm.docs.amd.com/projects/HIP/en/latest, ,

    work page 2024

  5. [5]

    Canning, P., Cook, W., Hill, W., Olthoff, W., & Mitchell, J. C. 1989, in Proceedings of the Fourth International Conference on Functional Programming Languages and Computer Architecture, FPCA '89 (New York, NY, USA: Association for Computing Machinery), 273–280. https://doi.org/10.1145/99370.99392

    work page arXiv 1989

  6. [6]

    Coplien, J. O. 1995, C++ Rep., 7, 24–27

    work page 1995

  7. [7]

    2008, Computational Science and Discovery, 1, 015005

    Gittings , M., Weaver , R., Clover , M., et al. 2008, Computational Science and Discovery, 1, 015005

    work page 2008

  8. [8]

    W., & O'Shea, B

    Grete, P., Glines, F. W., & O'Shea, B. W. 2021, IEEE Transactions on Parallel and Distributed Systems, 32, 85

    work page 2021

Show all 30 references
  1. [9]

    2025, Intel oneAPI Programming Guide, https://www.intel.com/content/www/us/en/docs/oneapi/programming-guide/2025-0/overview.html, ,

    Intel. 2025, Intel oneAPI Programming Guide, https://www.intel.com/content/www/us/en/docs/oneapi/programming-guide/2025-0/overview.html, ,

    2025

  2. [10]

    2017, Ramses-GPU: Second order MUSCL-Handcock finite volume fluid solver , Astrophysics Source Code Library, record ascl:1710.013, ,

    Kestener , P. 2017, Ramses-GPU: Second order MUSCL-Handcock finite volume fluid solver , Astrophysics Source Code Library, record ascl:1710.013, ,

    2017

  3. [11]

    2016, , 455, 4274

    Lecoanet , D., McCourt , M., Quataert , E., et al. 2016, , 455, 4274

    2016

  4. [12]

    Lesur , G. R. J., Baghdadi , S., Wafflard-Fernandez , G., et al. 2023, , 677, A9

    2023

  5. [13]

    D., & Armitage , P

    Li , X., Chang , P., Levin , Y., Matzner , C. D., & Armitage , P. J. 2020, , 494, 2327

    2020

  6. [14]

    2003, SIAM Journal on Scientific Computing, 25, 995

    Liska, R., & Wendroff, B. 2003, SIAM Journal on Scientific Computing, 25, 995. https://doi.org/10.1137/S1064827502402120

    2003 doi

  7. [15]

    Lv , A., Wang , L., Cen , R., & Ho , L. C. 2024, , 977, 274

    2024

  8. [16]

    2024, CUDA C++ Programming Guide, Version 12.6, https://docs.nvidia.com/cuda/cuda-c-programming-guide, ,

    NVIDIA. 2024, CUDA C++ Programming Guide, Version 12.6, https://docs.nvidia.com/cuda/cuda-c-programming-guide, ,

    2024

  9. [17]

    2025 a , MPI Solutions for GPUs, https://developer.nvidia.com/mpi-solutions-gpus, ,

    NVIDIA . 2025 a , MPI Solutions for GPUs, https://developer.nvidia.com/mpi-solutions-gpus, ,

    2025

  10. [18]

    2025 b , Floating Point and IEEE 754 Compliance for NVIDIA GPUs, https://docs.nvidia.com/cuda/floating-point/index.html, ,

    ---. 2025 b , Floating Point and IEEE 754 Compliance for NVIDIA GPUs, https://docs.nvidia.com/cuda/floating-point/index.html, ,

    2025

  11. [19]

    A., Goldbaum , N

    Schive , H.-Y., ZuHone , J. A., Goldbaum , N. J., et al. 2018, , 481, 4815

    2018

  12. [20]

    E., & Robertson , B

    Schneider , E. E., & Robertson , B. E. 2015, , 217, 24

    2015

  13. [21]

    M., Gardiner , T

    Stone , J. M., Gardiner , T. A., Teuben , P., Hawley , J. F., & Simon , J. B. 2008, , 178, 137

    2008

  14. [22]

    M., Tomida, K., White, C

    Stone, J. M., Tomida, K., White, C. J., & Felker, K. G. 2020, , 249, 4. https://iopscience.iop.org/article/10.3847/1538-4365/ab929b

    2020 doi

  15. [23]

    M., Mullen , P

    Stone , J. M., Mullen , P. D., Fielding , D., et al. 2024, arXiv e-prints, arXiv:2409.16053

    2024 arXiv

  16. [24]

    2024, OpenCL Guide, https://github.com/KhronosGroup/OpenCL-Guide, ,

    The Khronos Group . 2024, OpenCL Guide, https://github.com/KhronosGroup/OpenCL-Guide, ,

    2024

  17. [25]

    Toro, E. F. 2009, Riemann solvers and numerical methods for fluid dynamics: a practical introduction, 3rd edn. (Dordrecht ; New York: Springer), oCLC: ocn401321914

    2009

  18. [26]

    R., Lebrun-Grandié, D., Arndt, D., et al

    Trott, C. R., Lebrun-Grandié, D., Arndt, D., et al. 2022, IEEE Transactions on Parallel and Distributed Systems, 33, 805

    2022

  19. [27]

    2022, , 932, 108

    Wang , L., & Li , X. 2022, , 932, 108

    2022

  20. [28]

    2025, , 276, 40

    Wang , S., Wang , L., & Dong , S. 2025, , 276, 40

    2025

  21. [29]

    1984, Journal of Computational Physics, 54, 115

    Woodward , P., & Colella , P. 1984, Journal of Computational Physics, 54, 115

    1984

  22. [30]

    2019, The Journal of Open Source Software, 4, 1370

    Zhang , W., Almgren , A., Beckner , V., et al. 2019, The Journal of Open Source Software, 4, 1370

    2019

Pith tools

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