Pith. sign in

REVIEW 3 major objections 5 minor 24 references

STORM: RDMA-based Monte Carlo Transport Scheme for Distributed-Memory Particle Simulations

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

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

Pith's one-line read Replacing matched MPI sends with one-sided RDMA ring-buffer writes removes the progress bottleneck in distributed Monte Carlo transport, enabling >97% weak and >88% strong scaling to 13,440 cores.

desk verdict A well-executed, openly-released RDMA communication layer for distributed Monte Carlo transport with credible but self-defined scaling results; the lock-free protocol's RDMA ordering assumption needs explicit verification before the correctness claims can be fully trusted. read the letter →

arxiv 2607.20639 v1 pith:KGGXWRZC submitted 2026-07-22 astro-ph.IM cs.DCphysics.comp-ph

Maor Mizrachi , Barak Raveh , Elad Steinberg This is my paper · ORCID
classification astro-ph.IMcs.DCphysics.comp-ph
keywords MonteCarlotransportRDMAone-sidedcommunicationlibfabricringbufferdistributedmemoryscalabilityradiativetransfer
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 paper attempts to establish that the dominant obstacle to scaling distributed Monte Carlo particle transport—for astrophysical radiation and neutrino problems—is the two-sided MPI communication model, in which receivers must post receives and poll for progress, and that this obstacle can be removed with a one-sided RDMA protocol. The central design is a per-pair, lock-free single-producer/single-consumer ring buffer: the sender writes particles directly into the receiver's registered memory and publishes the batch with an atomic counter increment, while the receiver stays entirely passive. If the claimed scaling results hold, Monte Carlo transport could be coupled to radiation-hydrodynamics simulations on unstructured moving meshes at tens of thousands of cores without redesigning the physics or mesh codes. The paper reports >97% weak-scaling and >88% strong-scaling efficiency in a uniform-emission stress test up to 13,440 cores, and a 1.41x wall-clock speedup over an optimized two-sided backend in a realistic hohlraum IMC benchmark at 4,480 ranks, attributed to a 6.1x reduction in MPI progress overhead.

What carries the argument

The load-bearing mechanism is the per-pair Handler: a lock-free single-producer/single-consumer ring buffer backed by two RDMA-registered memory regions—a particle array plus a head/tail counter pair. The sender is the sole writer of tail and particle data; the receiver is the sole writer of head. Batch transfers are made contiguous (with wrap-around handling), and a single atomic fetch-and-add on the remote tail publishes the batch after the data writes, so the receiver's CPU is never involved in a communication call. Local aggregation buffers (default 64 particles) amortize the RDMA round-trips, and a tree-based two-phase termination detector supplies global completion without a full reduc

What would settle it

On a fabric or libfabric provider where an RDMA write and a subsequent atomic fetch-and-add are not strictly ordered as seen by the receiver (for example, some Ethernet or non-InfiniBand providers), run the uniform-emission benchmark and check for corrupted or uninitialized particle data, or instrument the receiver to detect a tail increment preceding the data. If the receiver ever observes a new tail with stale particle bytes, the central scalability claim collapses for that hardware.

Watch

Extended reading notes

Core claim

STORM's central claim is that inter-rank particle transfer can be made passive for the receiver using one-sided RDMA. Each ordered pair of neighboring ranks has a Handler: a lock-free single-producer/single-consumer ring buffer with two RDMA-registered regions—particle array and head/tail counters. The sender reads remote counters, writes particles contiguously at the tail, and publishes them with an atomic fetch-and-add on the remote tail; the receiver issues no communication calls and sees arrivals as the tail increases. No lock is needed because each Handler has one producer and one consumer. The paper reports >97% weak-scaling and >88% strong-scaling efficiency up to 13,440 cores, 1.14–1

Load-bearing premise

The receiver must see the particle data that an RDMA write deposited before it sees the result of the sender's atomic fetch-and-add on the tail counter, with no receiver-side synchronization; if a fabric or hardware reorders these two remote operations, the lock-free protocol can read uninitialized particle slots.

Editorial extensions

If this is right

  • Distributed Monte Carlo radiation/neutrino transport can be coupled to unstructured moving-mesh hydrodynamics at scales beyond typical current practice, with the communication layer detached from physics and mesh details.
  • The passive-receiver model eliminates per-iteration MPI progress polling from the inner particle loop, which is the source of the 1.41x speedup on the hohlraum workload.
  • Because the RDMA advantage over two-sided MPI grows with core count (1.08x at 2,240 ranks to 1.27x at 13,440 ranks), the protocol is most valuable on very large runs with high communication pressure.
  • Four interchangeable backends (OFI/libfabric, native InfiniBand Verbs, MPI RMA, and optimized two-sided MPI) mean the same application code can run on varied hardware with a build-time or run-time choice.

Reading between the lines

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

  • The scalability results were obtained on one InfiniBand cluster; replicating the uniform-emission benchmark on Cray Slingshot, AWS EFA, or Ethernet libfabric providers would test whether the lock-free protocol's ordering guarantees hold outside the verbs provider.
  • The same per-pair SPSC ring-buffer design could be applied to other irregular data exchanges in distributed simulations (e.g., AMR ghost cells or event-driven particles), though STORM does not demonstrate those use cases.
  • Because the reported speedup over two-sided MPI grows with core count, and the Hohlraum gain is concentrated in elimination of MPI progress polling, the design may benefit future exascale-class runs even more than the 1.14–1.27x measured here—provided the memory-ordering assumption survives on new hardware.
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 paper presents STORM, an open-source communication layer for distributed-memory Monte Carlo particle transport that replaces MPI matched-send/receive semantics with one-sided RDMA operations into per-pair SPSC ring buffers. The main claims are: (i) a lock-free transfer protocol that leaves receivers passive; (ii) near-linear weak scaling (>97%) and >88% 'strong-scaling' efficiency to 13,440 cores on a uniform-emission Voronoi-mesh benchmark; and (iii) a 1.41x speedup over an optimized two-sided MPI backend in a cylindrical Hohlraum IMC benchmark at 4,480 ranks, attributed to a 6.1x reduction in MPI progress overhead. The paper also describes asynchronous buffer reallocation, tree-based termination detection, and integration with the RICH moving-mesh code.

Significance. STORM addresses a real scalability bottleneck in astrophysical Monte Carlo transport: progress-polling overhead in two-sided MPI under bursty, neighbor-dependent traffic. The per-pair Handler design and the clean separation of the communication layer from physics and mesh representations are valuable, and the open-source release is a concrete strength. The paper does not fit a target or define its conclusion into existence; the benchmarks are self-defined but openly described. However, the central performance claims rest on a nonstandard strong-scaling definition and on an unverified memory-ordering assumption, so the current version does not yet substantiate the abstract's headline numbers. If these issues are resolved, the work would be a solid systems contribution with clear relevance to radiation-hydrodynamics and neutrino-transport codes.

major comments (3)
  1. [§3.3, Algorithm 1, and §3.8.1] The protocol's correctness depends on the assertion that the atomic FetchAndAdd 'ensures that the tail increment is visible to the receiver only after all particle data has been written.' This is not a universal property of RDMA/OFI: it requires explicit ordering guarantees (e.g., FI_ORDER_WRITE/FI_ORDER_ATOMIC, FI_FENCE, or the native Verbs equivalent) on the endpoint. The manuscript neither states which ordering attributes are configured nor verifies them on the providers used, and it gives no receiver-side synchronization. On a weak-memory architecture or a provider that does not order RMA writes and atomics, the receiver could observe the incremented tail before the payload writes are coherent, yielding stale or torn particle data. Since every reported benchmark uses this protocol, the issue is load-bearing. Please specify the ordering configuration, add an explicit fence if needed,
  2. [§4.2.2, Tables 1–2] The 'strong-scaling' test fixes per-core mesh size (N_base/P = 5,000 cells per core) rather than the total problem size, so the total mesh grows linearly with P while the total work is held constant by scaling Δt ∝ P^{−4/3}. This is a scaled-efficiency test, not strong scaling in the standard fixed-problem-size sense; the headline '>88% strong-scaling efficiency' is anchored to the authors' own 2240-rank baseline and is not comparable to conventional strong-scaling results. Please either rename the test (e.g., 'scaled-size efficiency'), or add a true fixed-size strong-scaling run at smaller scales, and make the definition explicit in the abstract and conclusions.
  3. [§4.2 and §4.3.2 (Tables 1–2, Fig. 10)] No run-to-run variability is reported. All times are averages of the last 3 cycles of a single run, and Fig. 10 uses a single representative MC step. On a shared cluster with Dragonfly+ topology, the 1.14–1.27× speedups and the 88–99% efficiencies could easily be within run-to-run noise. Please report at least three independent runs per configuration (or min/max and mean) and, if possible, multiple timesteps for the Hohlraum time breakdown.
minor comments (5)
  1. [§4.2.2] The phrase '1.95× speedup over 2× ideal' is confusing; a 97.5% efficiency on 2× cores is simply 1.95× speedup relative to the baseline, not 'over' the ideal.
  2. [§4.2.1 and §4.3] Physics validation is deferred to a companion paper. Since this paper claims only communication-layer performance, please state explicitly in the abstract or introduction that no physical correctness is evaluated here, to avoid reader confusion.
  3. [§3.8.1] The guarantee 'The atomic FetchAndAdd ensures that the tail increment is visible...' should be revised to a conditional statement once the ordering configuration is specified; as written it overstates an untested property.
  4. [§3.5] The reallocation protocol mentions 'timestamp-ordered service' of requests, but no source of timestamps or implementation detail is given. Please clarify or remove this claim if it is not actually implemented.
  5. [Figure 4] The caption and figure are dense; consider simplifying the legend or enlarging the panel to improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: STORM's scaling and speedup claims are measured benchmarks, not derived quantities fitted to their own targets.

full rationale

STORM is a systems/performance paper rather than a derivation chain: its central claims are wall-clock timings, scaling efficiencies, and backend speedups obtained by running benchmarks. No target quantity is fitted to a subset of data and then renamed as a prediction; no equation defines its conclusion into existence. The strong- and weak-scaling efficiencies are anchored to the authors' own 2240-rank baseline per backend, but anchoring to a measured reference point is standard benchmarking practice, not a circular construction. The uniform-emission benchmark is admittedly 'adversarial' and self-designed, but its purpose is to measure communication cost, and the measured times are not implied by the benchmark definition. The Hohlraum benchmark's IMC physics validation is explicitly deferred to a companion paper by the same authors ('Mizrachi et al., in preparation'), so the physics-correctness claim is externally unsupported within this manuscript; however, the paper's communication-layer timing comparison does not reduce to that companion result, and the self-citation is therefore a completeness gap rather than a load-bearing circular step. Similarly, the citations to the authors' own MadVoro/RICH infrastructure are not used to derive the scaling numbers. The lock-free transfer protocol does rely on an asserted memory-ordering guarantee in Section 3.3/3.8.1 (RDMA writes before the FetchAndAdd tail increment are observed in order by the receiver), which is an unstated and untested correctness assumption on weak-memory providers; that is a correctness/robustness risk, not circularity. In sum, no claim in the paper reduces by construction to its own inputs, so the circularity score is 0.

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

The library's correctness and performance rest primarily on the hardware/software stack: coherent RDMA visibility, libfabric provider ordering, sparse neighbor graphs, and MPI progress for reallocation. These are not proven but plausibly hold on the tested InfiniBand/x86 platform. The empirical claims have no error bars and use an internal benchmark definition. No new physical entities are introduced.

free parameters (4)
  • Aggregation batch size = 64 (default)
    Section 3.4: outgoing particles flush when the configurable threshold is reached; benchmarks use 64; speedup depends on this value and no sensitivity analysis is reported.
  • Handler ring-buffer capacity = 1024 slots default (~128 KB per handler)
    Section 3.8: pre-allocated per-pair buffer capacity; affects reallocation frequency and memory footprint; no sensitivity analysis is reported.
  • Polling frequencies for reallocation progress = not reported
    Section 3.5, Algorithm 3: progress operations run at configurable polling frequencies; values are left unspecified, so exact timing depends on undocumented choices.
  • Scaling timestep exponents = dt ∝ P^{-4/3} (strong), dt ∝ P^{-1/3} (weak)
    Section 4.2.2: chosen to hold total or per-core particle-step counts constant in the benchmarks; these define what the scaling efficiency measures and are not fitted to data.
assumptions (5)
  • domain assumption RDMA writes to registered remote memory are visible to the receiving rank's ordinary local reads without explicit synchronization, and a subsequent atomic FetchAndAdd is ordered after prior RDMA writes.
    Section 3.3 depends on the receiver observing tail-head increase only by polling local memory; this relies on x86 coherent DMA and a libfabric provider ordering guarantee that is not stated or tested.
  • domain assumption A single connectionless RDM endpoint can issue ordered one-sided writes and atomics to multiple peers without receiver-side progress.
    Section 2.1 and 3.3: correctness relies on RDM endpoint semantics of fi_write and fi_fetch_atomic, which are provider-dependent.
  • domain assumption The communication graph is sparse: each rank has O(1) active neighbors, so lazy Handler allocation keeps memory proportional to active pairs rather than P^2.
    Section 3.8: if dense communication patterns occur, Handler memory overhead scales quadratically.
  • domain assumption MPI nonblocking Isend plus periodic progress ensures deadlock-free reallocation.
    Section 3.5: the protocol claims no blocking waits, but this relies on MPI library progress semantics and the periodic progress calls in Algorithm 3.
  • domain assumption The Hohlraum IMC implementation used for the benchmark is correct.
    Section 4.3 defers IMC physics validation to the companion paper (Mizrachi et al., in preparation); the communication timings assume the physics implementation is correct.

how reviews work

0 comments
Cite this review

Pith. "Pith review of STORM: RDMA-based Monte Carlo Transport Scheme for Distributed-Memory Particle Simulations." pith.science (2026). https://pith.science/paper/KGGXWRZC

@misc{pith2026260720639,
  author       = {Pith},
  title        = {Pith review of: STORM: RDMA-based Monte Carlo Transport Scheme for Distributed-Memory Particle Simulations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KGGXWRZC}},
  note         = {Machine review of arXiv:2607.20639}
}
abstract

Monte Carlo particle transport enables high-fidelity astrophysical radiation and neutrino simulations - from core-collapse supernovae and neutron-star mergers to accretion flows - by handling multidimensional geometries, frequency dependence, and moving media without angular discretization. However, inter-rank communication limits scalability on unstructured meshes: standard two-sided MPI requires receivers to post receives and poll completions, creating per-iteration progress overhead that grows with the number of communication partners. Such problems have not demonstrated high scaling efficiency at $O(10^4)$ cores. We present STORM (Scalable Transport via One-sided Remote Memory), an open-source library for Monte Carlo transport on general meshes, physics, and boundary conditions. STORM provides a lock-free, mesh-independent communication layer that replaces MPI's matched-send/receive semantics with Remote Direct Memory Access (RDMA) - one-sided operations that write directly into a remote rank's memory without involving its CPU. Each rank pair shares a single-producer, single-consumer ring buffer; RDMA writes transfer particles while receivers remain passive. A two-sided MPI backend provides a portable fallback. In an adversarial uniform-emission benchmark, the RDMA backend sustains $>97\%$ weak-scaling and $>88\%$ strong-scaling efficiency up to 13,440~cores (112~cores per network adapter), with $1.14$-$1.27\times$ speedups over the two-sided alternative. In a Hohlraum IMC benchmark at 4480 ranks, it is $1.41\times$ faster because MPI progress overhead is reduced by $6.1\times$. By decoupling communication from physics models and mesh representations, STORM removes a barrier to scaling Monte Carlo transport in astrophysical multiphysics codes, enabling coupled radiation-hydrodynamics with energy- and angle-resolved photon or neutrino transport on dynamically evolving meshes at scale.

Figures

Figures reproduced from arXiv: 2607.20639 by the authors.

Figure 1
Figure 1. OFI (libfabric) architecture and one-sided RDMA write in four steps. (1) The application on Rank A issues an RDMA operation (e.g. fi write), specifying the local buffer’s memory descriptor, the remote buffer’s address and memory-region key, and the target’s fi addr t from the Address Vector. (2) The NIC reads the source data from the local registered Memory Region. (3) The NIC transmits the data over the network fab… view at source ↗
Figure 2
Figure 2. Per-timestep main loop of the Monte Carlo manager. After initialization and particle creation (preStep), each rank enters the HandleAll routine (dashed box), which iterates over all locally available particles: each particle is advanced by physics.step and, depending on the outcome, either moves to a local cell, is transferred to a neighbor rank via RDMA (Algorithm 1), or is removed (with the distributed counter dec… view at source ↗
Figure 3
Figure 3. Ring-buffer layout of a single Handler. The particles[ ] array is a circular buffer; dark cells are occupied slots in the region from head mod buffsize to tail mod buffsize. Two RDMA-registered memory regions expose the particle data and the [head, tail] counter pair, respectively. Because each Handler has exactly one sender and one receiver (SPSC), no locks are required on the transfer path. • particles[ ] - a pre-… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The rankHandlers[ ] matrix for a three-rank communicator. Each cell (i, j) is the Handler that rank i holds for rank j. Diagonal cells (blue background) are self-handlers using plain allocated memory. Off-diagonal cells (orange background) are remote handlers backed by…
Figure 5
Figure 5. Figure 5: Lock-free one-sided RDMA transfer of particles from rank A to rank B’s Handler. Rank B executes no code during the entire operation. Dashed blue arrows denote one-sided reads (data flows from B’s memory to A); solid green arrows denote one-sided writes (A deposits data…
Figure 6
Figure 6. Figure 6: Tree-based distributed termination detection for P = 7 ranks arranged in a complete binary tree. (a) Phase 1: each rank accumulates a local particle-count delta (∆) and periodically sends it to its parent; interior nodes aggregate their children’s deltas with their own…
Figure 7
Figure 7. Figure 7: Strong-scaling results for the uniform-emission benchmark on a log-log scale. Wall-clock time (average of the last 3 cycle step times) is shown as a function of the number of MPI ranks for the OFI (RDMA) and point-to-point (P2P) backends. Dashed lines show the ideal A/…
Figure 8
Figure 8. Figure 8: Weak-scaling results for the uniform-emission benchmark. Wall-clock time (average of the last 3 cycle step times) is shown as a function of the number of MPI ranks, with per-core workload held approximately constant (Nbase/P = 5 000 cells per core, ∆t ∝ P −1/3 ). The d…
Figure 9
Figure 9. Figure 9: Cylindrical Hohlraum benchmark used as a realistic IMC timing case. Top left: material-type field showing the absorbing wall regions and vacuum channel. Top right: characteristic Voronoi-cell size, with refinement near material-vacuum interfaces. Bottom left: three-dim…
Figure 10
Figure 10. Figure 10: Average per-rank wall-clock time breakdown for a representative MC step of the cylindrical Hohlraum IMC benchmark on 40 nodes (4 480 ranks), comparing the OFI (RDMA) and P2P backends. All values are averages across ranks. Computation: Physics - the physics->step() cal…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 10 canonical work pages

  1. [1]

    D., et al

    Abdikamalov, E., Burrows, A., Ott, C. D., et al. 2012, The Astrophysical Journal, 755, 111, doi: 10.1088/0004-637X/755/2/111

    doi:10.1088/0004-637x/755/2/111 2012

  2. [2]

    A., & Brantley, P

    Brunner, T. A., & Brantley, P. S. 2009, Journal of Computational Physics, 228, 3882, doi: 10.1016/j.jcp.2009.02.013

    work page doi:10.1016/j.jcp.2009.02.013 2009

  3. [3]

    M., et al

    Dempsey, A. M., et al. 2024, artemis: Astrophysical multifluid radiation hydrodynamics code,, https://github.com/lanl/artemis

    2024

  4. [4]

    D., Thompson, K

    Densmore, J. D., Thompson, K. G., & Urbatsch, T. J. 2012, Journal of Computational Physics, 231, 6924, doi: 10.1016/j.jcp.2012.06.020

    work page doi:10.1016/j.jcp.2012.06.020 2012

  5. [5]

    D., Urbatsch, T

    Densmore, J. D., Urbatsch, T. J., Evans, T. M., & Buksas, M. W. 2007, Journal of Computational Physics, 222, 485, doi: 10.1016/j.jcp.2006.07.031

    work page doi:10.1016/j.jcp.2006.07.031 2007

  6. [6]

    2018, Monthly Notices of the Royal Astronomical Society, 475, 4186, doi: 10.1093/mnras/sty108

    Foucart, F. 2018, Monthly Notices of the Royal Astronomical Society, 475, 4186, doi: 10.1093/mnras/sty108

    doi:10.1093/mnras/sty108 2018

  7. [7]

    2023, Living Reviews in Computational Astrophysics, 9, 1, doi: 10.1007/s41115-023-00016-y

    Foucart, F. 2023, Living Reviews in Computational Astrophysics, 9, 1, doi: 10.1007/s41115-023-00016-y

    doi:10.1007/s41115-023-00016-y 2023

  8. [8]

    J., Haworth, T

    Harries, T. J., Haworth, T. J., Acreman, D., et al. 2019, Astronomy and Computing, 27, 63, doi: 10.1016/j.ascom.2019.03.002 Jr., J. A. F., & Cummings, J. D. 1971, Journal of Computational Physics, 8, 313, doi: 10.1016/0021-9991(71)90015-5

    doi:10.1016/j.ascom.2019.03.002 2019

Show all 24 references
  1. [9]

    C., & Nugent, P

    Kasen, D., Thomas, R. C., & Nugent, P. 2006, The Astrophysical Journal, 651, 366, doi: 10.1086/506190

    2006 doi

  2. [10]

    G., & Urbatsch, T

    McClarren, R. G., & Urbatsch, T. J. 2009, Journal of Computational Physics, 228, 5669, doi: 10.1016/j.jcp.2009.04.028

    2009 doi

  3. [11]

    Guidry, M. W. 1998, The Astrophysical Journal, 507, 353, doi: 10.1086/306323

    1998 doi

  4. [12]

    Mezzacappa, A., Endeve, E., Messer, O. E. B., & Bruenn, S. W. 2020, Living Reviews in Computational Astrophysics, 6, 4, doi: 10.1007/s41115-020-00010-8

    2020 doi

  5. [13]

    2025, RAS Techniques and Instruments, 4, rzaf039, doi: 10.1093/rasti/rzaf039

    Mizrachi, M., Raveh, B., & Steinberg, E. 2025, RAS Techniques and Instruments, 4, rzaf039, doi: 10.1093/rasti/rzaf039

    2025 doi

  6. [14]

    2026, in preparation

    Mizrachi, M., Steinberg, E., & Raveh, B. 2026, in preparation

    2026

  7. [15]

    M., Abdikamalov, E., & Urbatsch, T

    Murchikova, E. M., Abdikamalov, E., & Urbatsch, T. 2017, Monthly Notices of the Royal Astronomical Society, 469, 1725, doi: 10.1093/mnras/stx986

    2017 doi

  8. [16]

    M., & Sim, S

    Noebauer, U. M., & Sim, S. A. 2019, Living Reviews in Computational Astrophysics, 5, 1, doi: 10.1007/s41115-019-0004-9

    2019 doi

  9. [17]

    2006, Astronomy & Astrophysics, 459, 797, doi: 10.1051/0004-6361:20053275

    Pinte, C., M´ enard, F., Duchˆ ene, G., & Bastien, P. 2006, Astronomy & Astrophysics, 459, 797, doi: 10.1051/0004-6361:20053275

    2006 doi

  10. [18]

    Richers, S., Kasen, D., O’Connor, E., Fern´ andez, R., & Ott, C. D. 2015, The Astrophysical Journal, 813, 38, doi: 10.1088/0004-637X/813/1/38

    2015 doi

  11. [19]

    D., et al

    Richers, S., Nagakura, H., Ott, C. D., et al. 2017, The Astrophysical Journal, 847, 133, doi: 10.3847/1538-4357/aa8bb2 22Mizrachi et al

    2017 doi

  12. [20]

    K., Forget, B., & Brown, F

    Romano, P. K., Forget, B., & Brown, F. 2011, Progress in Nuclear Science and Technology, 2, 670, doi: 10.15669/PNST.2.670

    2011 doi

  13. [21]

    K., Siegel, A

    Romano, P. K., Siegel, A. R., Forget, B., & Smith, K. 2013, Journal of Computational Physics, 252, 20, doi: 10.1016/j.jcp.2013.06.011

    2013 doi

  14. [22]

    T.-S., Vogelsberger, M., & Pakmor, R

    Smith, A., Kannan, R., Tsang, B. T.-S., Vogelsberger, M., & Pakmor, R. 2020, The Astrophysical Journal, 905, 27, doi: 10.3847/1538-4357/abc47e

    2020 doi

  15. [23]

    Wollaber, A. B. 2016, Journal of Computational and Theoretical Transport, 45, 1, doi: 10.1080/23324309.2016.1138132

    2016

  16. [24]

    2015, The Astrophysical Journal Supplement Series, 216, 35, doi: 10.1088/0067-0049/216/2/35

    Yalinewich, A., Steinberg, E., & Sari, R. 2015, The Astrophysical Journal Supplement Series, 216, 35, doi: 10.1088/0067-0049/216/2/35

    2015 doi

Pith tools

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