{"id":"41b5f4d0-6ce1-4871-bfa6-d87f3d297fb7","arxiv_id":"2605.26388","paper_version":4,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"low","formal_verification":"none","parameter_count":5,"one_line_summary":"MARUT delivers a fully GPU-resident high-order DG CFD framework with AMR and finite-rate chemistry that validates on canonical compressible and reacting benchmarks and scales across multiple NVIDIA GPUs.","lead":"MARUT is a Julia-based multi-GPU CFD solver that runs high-order discontinuous Galerkin methods, adaptive mesh refinement, and finite-rate chemistry entirely on NVIDIA GPUs for subsonic-to-hypersonic flows. It matters because high-speed aerospace design needs accurate, scalable reacting-flow simulation on modern heterogeneous machines.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.5","headline":"Exascale-ready and near-linear multi-GPU claims rest on ≤4-GPU static-mesh 2D airfoil runs; dynamic GPUForest AMR load imbalance and chemistry are not demonstrated under distributed execution.","rationale":"The reader’s weakest_assumption correctly identifies the evidentiary gap: four-GPU static-mesh timings plus single-GPU H100/H200 results do not underwrite “exascale-ready” branding or production-scale AMR efficiency. No internal inconsistency appears in the numerics, entropy-stable operators, BR1 viscous path, or benchmark agreement (§4). The engineering contribution relative to TrixiCUDA.jl (curvilinear P4estMesh, full viscous + chemistry + GPUForest on device) is real and correctness risk remains low. The concern is therefore scope of the scalability evidence, not soundness of the reported kernels or single-device results. Verdict stays CONDITIONAL; tightening the abstract/conclusions language or adding multi-GPU AMR/chemistry scaling would resolve it. No stronger objection lands.","tokens_in":32376,"tokens_out":636,"duration_ms":19417,"concrete_test":"Re-run the §5.2 strong-scaling suite (same RAE 2822, P=5, SSPRK54, 1–4 L40S) with GPUForest AMR active (Löhner indicator, 2:1 balance, every 5–50 steps as in §4), reporting wall-time/step, communication fraction, and max/min element count imbalance; if 4-GPU efficiency drops below ~70 % or communication exceeds ~25 % under adaptation, the multi-GPU AMR scalability claim needs qualification.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The strongest claim (fully GPU-resident multi-GPU high-order DG + GPUForest AMR + on-device finite-rate/two-temperature chemistry with near-linear strong scaling) is only partially evidenced. §§3.1.1–3.1.4 and single-GPU results (§4: cylinder AMR, TGV Case 3 AMR, reactive blast) establish the kernels and GPUForest. But the multi-GPU numbers in §5.2 (strong/weak scaling to 4 L40S, face-only MPI, up to 91.5 % efficiency) use a fixed-mesh 2D RAE 2822 viscous case with no dynamic adaptation and no chemistry source kernels. §5.1 correctly lists the hard AMR issues (prolongation/restriction, 2:1 balance, SFC rebalancing, refluxing, subcycling), yet those operations are never timed under multi-rank load imbalance. If frequent GPUForest cycles or stiff Park-air-5 Newton steps (§3.1.3) raise communication or idle time above the reported ~10 %, the near-linear and “exascale-ready” statements (abstract, conclusions) do not hold. This is the least secure premise for the central scalability claim.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"MARUT is a Julia/Trixi-based multi-GPU CFD framework for compressible flows from subsonic to hypersonic regimes, including finite-rate multi-species chemistry and two-temperature thermal nonequilibrium. It implements a fully GPU-resident spectral DG pipeline (entropy-stable split-form volume integrals, Hennemann–Gassner shock capturing, mortar interfaces, BR1 viscous terms, boundary kernels) on curvilinear P4estMesh geometries, a device-resident forest-of-trees AMR layer (GPUForest), and per-node Strang-split chemistry/Landau–Teller source kernels. Single-GPU validations cover a Mach-3 cylinder with AMR, subsonic and supersonic Taylor–Green vortex (including AMR), ONERA M6 Cp vs experiment, and a nonequilibrium reactive blast. Performance is reported via CPU–GPU wall-time comparisons and strong/weak scaling on up to four L40S GPUs for a fixed-mesh 2D RAE 2822 case.","tokens_in":32808,"tokens_out":1363,"duration_ms":18423,"significance":"If the accuracy and GPU-resident design claims hold, MARUT is a useful, modular high-order platform that advances beyond TrixiCUDA.jl by supporting curvilinear unstructured meshes, full viscous operators, GPUForest AMR, and on-device finite-rate/two-temperature chemistry in one stack. The external-reference validations (van Rees TGV, Chapelier TENO TGV, Schmitt–Charpin ONERA M6, Grossman-type blast) and the documented single-GPU AMR and chemistry kernels are genuine strengths. The Julia implementation and AI-compatibility discussion are secondary but relevant. The main significance risk is branding: “exascale-ready” and “near-linear multi-GPU scaling” for the full AMR+chemistry feature set are not yet demonstrated at the scale the abstract and conclusions assert.","major_comments":[{"comment":"Abstract, §5.2, and Conclusions claim near-linear strong scaling and an “exascale-ready” design for the full multi-GPU framework with AMR and finite-rate chemistry. The only multi-GPU numbers (strong/weak scaling to 4 L40S GPUs, up to ~91.5% efficiency) use a static-mesh 2D RAE 2822 viscous case with face-only MPI and no dynamic GPUForest adaptation and no chemistry source kernels. §5.1 correctly lists the hard distributed-AMR costs (prolongation/restriction, 2:1 balance, SFC rebalancing, refluxing, subcycling), but those operations are never timed under multi-rank load imbalance. Either provide multi-GPU scaling with active GPUForest (and ideally chemistry) or substantially qualify the abstract/title/conclusion claims so they match the evidence.","section":null},{"comment":"§4.4 (nonequilibrium blast) is the sole reactive validation: a 2D closed-domain air-5 blast on a fixed 64×64, P=7 mesh. The paper’s central multiphysics claim includes hypersonic multi-species nonequilibrium with stiff sources. A second reactive case with quantitative comparison (e.g., shock-standoff, species profiles, or a published 1D/2D nonequilibrium reference with tabulated errors) would better support the chemistry accuracy claim; qualitative contour agreement alone is thin for that pillar of the contribution list.","section":null},{"comment":"§3.1.4 and Table 3 describe a fully GPU-resident AMR cycle, and single-GPU AMR is shown for the cylinder and TGV Case 3. There is no multi-GPU demonstration that GPUForest rebalancing, mortar rebuild, and L2 projection preserve conservation and load balance across ranks when refinement is highly localized (e.g., bow shock + wake). Without that, the claim that GPUForest “overcomes the primary computational bottleneck in adaptive multiscale simulations” on multi-GPU systems remains an architectural statement rather than a measured result.","section":null}],"minor_comments":[{"comment":"Title and abstract use “Exascale-Ready”; §5 only reaches four GPUs with CPU-staged InfiniBand MPI. Prefer “multi-GPU scalable” or “designed for exascale architectures” unless larger-scale data are added.","section":null},{"comment":"§4.1: times are written as “t = 0.1, 1, 3, and 5 s” while the nondimensional setup has no physical time unit; drop “s” or state the nondimensionalization.","section":null},{"comment":"Figure 2 caption and body: “147,801 elements (≈9.46×10^6 DOFs)” is clear; ensure all DOF counts consistently state whether they are grid points or conserved-variable DOFs (cylinder text mixes both).","section":null},{"comment":"§3.1.3: Newton FD perturbation ε and Strang-split settings are free parameters; a short sensitivity note (or default table) would help reproducibility of the reactive blast.","section":null},{"comment":"References [35,36] are the authors’ own DRL flow-control papers; they are peripheral to the solver contribution and could be moved to a brief “applications” sentence to avoid over-weighting self-citation.","section":null},{"comment":"Occasional notation slips (e.g., Ms vs M in TGV; “TrixiCUDA.jl” vs “Trixi ecosystem”) should be unified in a final pass.","section":null}],"recommendation":"major_revision","confidential_remarks":"The technical core (GPU-resident DG + BR1 + GPUForest + chemistry kernels, solid single-GPU benchmarks) is publishable after claim calibration. The main editorial risk is overselling: “exascale-ready” and full-feature multi-GPU scaling are not yet shown. I would accept after major revision if the authors either add multi-GPU AMR (even 2–4 GPUs with imbalance metrics) or rewrite abstract/title/conclusions to match the static-mesh 4-GPU evidence. Fit for a computational-physics / scientific-computing venue is good; novelty is incremental relative to Trixi.jl but the end-to-end GPU path for curvilinear AMR + chemistry is a real systems contribution."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"Punchline: this is a real software and kernel contribution, not a re-skin of TrixiCUDA. The authors put a full hyperbolic–parabolic–chemistry path on the device for curvilinear P4est meshes, add GPUForest so AMR stays resident, and show credible single-GPU accuracy plus small-scale multi-GPU numbers. The soft spot is the packaging of those numbers as exascale readiness.\n\nWhat is actually new is the end-to-end device path: entropy-stable split volume work, mortars, BR1 viscous operators and BCs, Park/Landau–Teller source kernels with Strang split and local Newton, and a GPU-resident forest with indicator, 2:1 balance, L2 transfer, GCL metrics, and connectivity rebuild. That is more than Cartesian TrixiCUDA. Validations are the right ones for the claim—Mach-3 cylinder with AMR, TGV energy/dissipation against van Rees and Chapelier, ONERA M6 Cp against Schmitt–Charpin, and a nonequilibrium blast. CPU vs H100/H200 timings are useful and not oversold on the single-GPU side.\n\nThe stress-test note is fair and lands. Strong/weak scaling to four L40S GPUs is on a static 2D RAE 2822 viscous case with face-only MPI; dynamic GPUForest load imbalance and chemistry are not in those multi-rank runs. Section 5.1 lists the hard AMR issues correctly, then does not time them under distributed adaptation. Calling the design “exascale-ready” and “near-linear across multiple GPUs” from that base is branding ahead of evidence. Free parameters (AMR thresholds, CFL, blending, positivity floors) are normal for this class of solver and do not undercut the external benchmarks.\n\nMath and discretization look standard and carefully written (SBP/split form, BR1, SSP-RK, Strang chemistry). Citations are appropriate; self-cites on DRL control are peripheral. Who this is for: high-order compressible CFD and GPU multiphysics people who care about unstructured AMR and reacting hypersonics. It deserves a serious referee. I would engage, cite the GPUForest and device chemistry path if I were building or comparing similar stacks, and ask authors to either drop the exascale language or show multi-GPU AMR+chemistry scaling before the final version.","headline":"Solid GPU-native high-order DG stack with real engineering advances; the “exascale-ready / near-linear multi-GPU” branding outruns the four-GPU fixed-mesh evidence.","tokens_in":33439,"tokens_out":599,"would_cite":true,"duration_ms":11295,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"MARUT keeps high-order compressible CFD, AMR, and finite-rate chemistry fully on the GPU and scales near-linearly across multi-GPU nodes.","keywords":["High-Fidelity CFD","Compressible Flows","Multi-GPU","MPI Parallelization","Adaptive Mesh Refinement","Finite-Rate Chemistry","Spectral Discontinuous Galerkin","AI-compatible CFD"],"falsifier":"Run the same AMR-enabled hypersonic reacting case on hundreds of GPUs (or a full multi-node system) and check whether strong-scaling efficiency collapses once communication or rebalancing cost exceeds the interior kernel time.","tokens_in":33274,"feed_emoji":"🚀","tokens_out":565,"duration_ms":5802,"temperature":0.7,"pith_summary":"MARUT is a multi-GPU CFD framework that runs high-order spectral discontinuous Galerkin discretizations, viscous terms, adaptive mesh refinement, and finite-rate two-temperature chemistry entirely on NVIDIA GPUs. The design keeps the forest mesh, connectivity, fluxes, and source terms device-resident so that time stepping does not shuttle data back to the host. Dynamic AMR concentrates resolution on shocks, shear layers, and reaction fronts while a face-only MPI exchange overlaps halo traffic with interior work. Across canonical subsonic-to-hypersonic and chemically reacting benchmarks the solver matches established reference solutions, and on up to four GPUs it reports high strong- and weak-scaling efficiency. The paper presents this combination as a practical route to high-fidelity, multiscale compressible-flow simulation on heterogeneous machines and as a modular base for later AI-compatible workflows.","feed_headline":"GPU-native high-order CFD scales near-linearly with AMR and chemistry","feed_subtitle":"MARUT keeps DG fluxes, mesh adaptation and finite-rate sources on device for hypersonic flows","key_machinery":"GPUForest: a device-resident forest-of-quadtrees/octrees that stores tree connectivity, Morton ordering, refinement levels and curvilinear geometry entirely in GPU memory, so that indicator evaluation, 2:1 balancing, L2 solution transfer and connectivity rebuild run as pure device kernels without host round-trips.","core_discovery":"A fully GPU-resident high-order spectral DG solver with device-side AMR (GPUForest) and on-device finite-rate / two-temperature chemistry can resolve shocks, boundary layers and reacting interfaces while achieving near-linear multi-GPU strong scaling and close agreement with classical compressible-flow benchmarks.","pith_inferences":[],"forward_implications":[],"fun_headline_variants":["MARUT: GPU-resident high-order DG CFD with device AMR for reacting hypersonics","Fully on-GPU spectral CFD scales near-linearly with AMR and finite-rate chemistry","High-order DG framework keeps shocks, AMR and chemistry resident on multi-GPUs","MARUT resolves hypersonic reacting flows via GPU-native DG plus adaptive refinement","Exascale-ready CFD: high-order fluxes, AMR and two-temperature chemistry on device"],"cache_read_input_tokens":16512,"weakest_assumption_plain":"That scaling measured on at most four InfiniBand-linked GPUs with CPU-staged MPI is enough to claim the design will stay efficient at true exascale, where load imbalance from dynamic AMR and interconnect latency may dominate.","fun_headline_variants_meta":{"raw":{"variants":["MARUT: GPU-resident high-order DG CFD with device AMR for reacting hypersonics","Fully on-GPU spectral CFD scales near-linearly with AMR and finite-rate chemistry","High-order DG framework keeps shocks, AMR and chemistry resident on multi-GPUs","MARUT resolves hypersonic reacting flows via GPU-native DG plus adaptive refinement","Exascale-ready CFD: high-order fluxes, AMR and two-temperature chemistry on device"]},"model":"grok-4.5","effort":"low","cost_usd":0.005468,"raw_usage":{"total_tokens":1528,"prompt_tokens":829,"num_sources_used":0,"completion_tokens":97,"cost_in_usd_ticks":54680000,"prompt_tokens_details":{"text_tokens":829,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":602,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":829,"tokens_out":97,"duration_ms":5736,"temperature":1.0,"reasoning_tokens":602,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-14T18:41:25.394192+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Run the same AMR-enabled hypersonic reacting case on hundreds of GPUs (or a full multi-node system) and check whether strong-scaling efficiency collapses once communication or rebalancing cost exceeds the interior kernel time.","supporting_citations":[],"review_version":2}