{"id":"1e5a6e0b-3c78-4607-8d42-60f18b0fdfa8","arxiv_id":"2602.06463","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"An MPI-parallelized HMCMC initial-condition reconstruction code with a linear-inversion start module claims near-linear scaling and large burn-in savings.","lead":"This paper describes an MPI-parallel rewrite of the ELUCID Hamiltonian Monte Carlo solver for reconstructing the universe's initial density field, adding a fast 'guess' module to shorten burn-in. If the reported scaling and savings hold, survey-scale reconstructions for DESI and CSST become computationally feasible.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Burn-in savings metric is self-referential and likely misstated; the extrapolated 8192^3 CPU-hour savings and feasibility claim rest on it.","rationale":"The reader identified extrapolation beyond measured scales as the weakest assumption. I agree that unmeasured extrapolation is a risk, but the more load-bearing concern is that the measured burn-in savings themselves may be an artifact of the convergence definition. The paper's own numbers make the stated definition impossible to reconcile: if the guess chain starts at χ² ≈ 0.02–0.05 (inferred from the head-start values), then 1% of that is ~0.0002–0.0005, far below the converged plateau of ~0.005 reported for 256³ and 1024³. Therefore the guess chain would never reach its own 1% threshold, yet the paper claims it converges faster. Either the definition is misstated (perhaps meaning 1% of the random chain's initial value, or 1% of the initial excess above the plateau), or the reported savings are not measured consistently. In either case, the quantitative savings table is not trustworthy as written. This is not a technical critique of MPI scaling, which appears reasonable over the measured range, but of the specific metric that generates the headline CPU-hour savings. A fixed absolute convergence threshold would settle whether the guess module genuinely accelerates burn-in. Because the central feasibility claim for 8192³ depends on these savings growing with problem size, the paper should be accepted only on condition that this metric is clarified and validated at larger scale. The verdict remains CONDITIONAL rather than REJECT because the method itself is plausible and the measured scaling results are coherent; the concern can be addressed with a reanalysis and a 2048³ run.","tokens_in":20181,"tokens_out":7143,"duration_ms":72068,"concrete_test":"Re-derive burn-in lengths from the raw χ²_ω curves used in Figure 4 using a fixed, absolute convergence criterion — e.g., first step where χ²_ω < 0.01 and remains below 0.01 for 10 consecutive steps, or the step where the chain reaches the final plateau within 5% — for both random and guess initializations at 256³ and 1024³. Then run a 2048³ chain with both initializations for at least 200 steps and measure actual burn-in steps and CPU hours under the same absolute criterion. If the 53/106-step savings shrink or disappear, the extrapolated 8192³ CPU-hour savings are invalid and the feasibility claim must be revised.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central quantitative claim — that the guess module saves 53/106/180/720 burn-in steps and millions of CPU hours (Section 3.5, Table 1) — depends on a convergence definition that is internally inconsistent. Section 3.5 defines burn-in as the number of iterations for χ²_ω to drop below 1% of 'its starting value.' For the random-start chain, the starting χ² is large (e.g., 0.54 at 256³), so the 1% threshold is relatively loose (~0.0054). For the guess-start chain, the head-start numbers show the initial χ² is already much lower — the random chain needs 27/53/90 steps to reach it — so 1% of that lower value is far below the converged plateau (~0.005 at 256³ and 1024³). Under the stated definition, the guess chain might never cross the threshold, or at least the two chains are not compared on an equal footing. Yet the paper reports the guess chain converges 53 and 106 steps sooner. This suggests the definition is misstated or the savings are not robust. Because the 8192³ feasibility estimate (~37M CPU hours saved) is extrapolated from these savings using a 'relative gain grows with problem size' assumption, with no measurement beyond 2048³ (and even that value is marked with '~'), the flagship claim is not adequately supported. The abstract/full-text inconsistency (4096³ vs 8192³ as the planned run) compounds the uncertainty.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents an MPI-parallelized implementation of the ELUCID Hamiltonian Monte Carlo (HMCMC) initial-condition reconstruction framework, built on the FastPM particle-mesh solver with 3D domain decomposition, together with an initial-guess module that generates an approximate linear inversion of the observed density field to shorten burn-in. The authors report strong- and weak-scaling tests for 256^3, 512^3, and 1024^3 particle boxes using up to 2048 MPI processes, memory-scaling behavior, reconstruction-accuracy comparisons against Gadget-4, Kun, and Quijote simulations, and burn-in savings for 256^3 and 1024^3 runs. From these measurements, they extrapolate CPU-hour savings for 2048^3 and 8192^3 runs and argue that survey-scale ELUCID-DESI reconstructions are computationally feasible.","tokens_in":20572,"tokens_out":9352,"duration_ms":90121,"significance":"If the central claims hold, this is a useful contribution to Bayesian initial-condition reconstruction: it removes the single-node shared-memory bottleneck, demonstrates nearly linear scaling in the tested range, and proposes a practical way to shorten the expensive burn-in phase. The accuracy validation against three independent simulation suites is a genuine strength, as is the explicit treatment of the transfer-function calibration and the FastPM integration. The measured results at 256^3 and 1024^3 are valuable even if the larger extrapolations are not accepted. However, the headline quantitative claims—especially the CPU-hour savings and feasibility of 8192^3 runs—depend on a convergence definition that is internally inconsistent and on extrapolations that are not supported by data in the manuscript. The paper is therefore technically promising but needs substantial revision before the quantitative conclusions can be relied upon.","major_comments":[{"comment":"The abstract and the body report different target scales and different projected costs. The abstract states that the planned ELUCID-DESI reconstruction uses 4096^3 particles, requiring about 800 HMCMC steps (~5 million core hours), with about 360 steps (~2.3 million core hours) saved by the guess module. The full text, however, repeatedly refers to an 8192^3 planned run (§3.3.1, §3.5, Table 1) and estimates about 720 steps and ~37,000,000 core hours saved. These are materially different claims. The authors must reconcile the abstract with the body and specify which target is actually planned.","section":"Abstract vs. §3.5, Table 1"},{"comment":"The burn-in period is defined as the number of iterations for chi2_omega to drop below 1% of its starting value for the first time. This definition is applied to both chains, but the two chains start from very different chi2 values. For the 256^3 random-start chain the initial value is chi2 ≈ 0.54 (§3.4.1), so the threshold is ≈ 0.0054; the guess-start chain begins at a much lower value, equivalent to that reached by the random chain only after 27 steps (Table 1). If 1% of the guess chain's own starting value were used, the threshold would typically lie below the converged plateau (≈ 0.005 at 256^3), so the guess-start chain would not count as converged at all under the stated rule. The reported savings of 53 and 106 steps are therefore not a valid comparison under the stated definition. Please define burn-in relative to a common absolute criterion and report the starting chi2 and conver","section":"§3.5, Table 1 — burn-in definition"},{"comment":"The rows for 2048^3 and 8192^3 are projections, not measurements. No wall-clock timings are reported at 2048^3 in the scaling sections, and the 8192^3 estimate assumes that per-step runtime scales linearly with particle number and that the head-start in steps grows linearly with box size. The implicit per-step CPU-hour costs in Table 1 are not internally consistent: from 1024^3 to 2048^3 the particle number increases by a factor of 8, but the per-step CPU hours increase by a factor of about 11.4, whereas from 2048^3 to 8192^3 the particle number increases by a factor of 64 and the per-step cost increases by exactly 64. The hidden assumptions about core counts and node layouts need to be stated, and the 37 million CPU-hour savings should be presented as an idealized extrapolation rather than as a measured or nearly measured result.","section":"§3.5, Table 1 — extrapolated CPU-hour savings"},{"comment":"The 1024^3 processor-scaling curve is placed on the common ideal line by first normalizing to its runtime at 256 processes and then dividing by a factor of 4, assuming ideal scaling between 64 and 256 processes. No measurement at 64 processes exists for this problem size. This anchors the 1024^3 curve at the ideal line by construction. The slope from 256 to 2048 processes is measured, but the vertical offset is assumed. The visual statement that the 1024^3 curve deviates the least from ideal scaling is therefore partly an artifact of the normalization. Please show unnormalized wall-clock times or compute parallel efficiencies from measured anchors at a common process count.","section":"§3.2.1, Fig. 2 left — normalization of 1024^3"},{"comment":"The right panel of Fig. 2 is used to support the claim of near-linear scaling with particle number. The text acknowledges that the apparent flattening of the slopes with increasing Nproc is caused by load imbalance at the 256^3 normalization point, which makes the normalized runtimes of larger problems look artificially small. This means the plot, as presented, is not a clean measurement of particle-number scaling. The authors should plot unnormalized runtimes or apply an explicit load-imbalance correction and report parallel efficiency values, so that the linear-scaling claim can be assessed directly from the data rather than through a known artifact.","section":"§3.2.2, Fig. 2 right — load-imbalance normalization"}],"minor_comments":[{"comment":"The subsection heading 'Motivation and' appears incomplete; the missing part should be supplied.","section":"§2.4.1"},{"comment":"Equation (28) uses the notation rho_p in the inversion but only rho_obs was defined earlier. Please define all symbols consistently.","section":"Eq. (28)"},{"comment":"The citation 'Sousa et al. 2007' in the context of peculiar-velocity field reconstruction appears to be a mismatched reference; the listed source is not a velocity-field paper. Please check and replace it.","section":"Introduction"},{"comment":"The 2048^3 case appears in Fig. 4 and Table 1, but the setup of that run (Nproc, node layout, solver parameters) is not described in Section 3.5. Please provide the run configuration or clearly mark the 2048^3 row as an extrapolation.","section":"Fig. 4 and Table 1"},{"comment":"The caption lists 'Bottom left' and then 'Middle right' for the two bottom-row panels, which is confusing. The panel labels should be corrected.","section":"Figure 5 caption"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope for a methods-focused astrophysics journal. The measured scaling and accuracy tests give a reasonable basis for the core MPI implementation, and the guess-module idea is worth publishing if the convergence criterion and extrapolation are fixed. The main risk is that the headline feasibility numbers, which are heavily promoted in the abstract, are not supported by the data as presented. I would be supportive after a revision that reports raw timings, clarifies the burn-in criterion, and clearly separates measured results from projections."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The MPI port is real, and the scaling measurements at 256^3–1024^3 look plausible. That is the core contribution: a distributed-memory version of the ELUCID HMC framework with domain decomposition, clean memory scaling, and honest accounting of the ~8x per-step slowdown relative to OpenMP. The guess module—a fast linear inversion as an HMC warm start—is a sensible idea, and the validation against Gadget-4, Kun, and Quijote is the right way to show the reconstruction still works. I believe the engineering is useful and the accuracy checks are solid.\n\nThe soft spots are in the performance claims. The burn-in reduction numbers in Table 1 rely on a definition that does not hold together. They define convergence as chi^2 dropping below 1% of its starting value. For the random-start chain, the threshold at 256^3 is ~0.0054, just above the plateau. For the guess-start chain, the starting chi^2 is much lower (the head-start numbers imply it equals the random chain's value after 27–90 steps), so 1% of that lower value is far below the plateau. By the stated definition, the guess chain would be judged to have converged much later, if ever, not 53–106 steps sooner. Either the definition is misstated or the savings are not robust. Since these savings are the basis for the 8192^3 feasibility estimate, this is a load-bearing flaw.\n\nSecond, the 720 steps and ~37 million CPU hours for 8192^3 are extrapolated from runs that stop at 1024^3 (with one 2048^3 point for the guess advantage). No measurement exists beyond 1024^3, and the abstract/full-text mismatch (4096^3 vs 8192^3 as the planned run) does not inspire confidence. The scaling plots also normalise the 1024^3 curve by dividing by 4 to force it onto the ideal line, and the particle-number scaling curves are admitted to be skewed by load imbalance at the smallest size. The quoted 'nearly linear' scaling is therefore more forgiving than the figures strictly show.\n\nFinally, no code or data release for a methods paper is a letdown; 'available on reasonable request' is not reproducibility.\n\nWho this is for: people working on Bayesian initial-condition reconstruction or planning large constrained simulations. It deserves a serious referee, but the burn-in definition must be corrected and the extrapolation re-derived before the headline cost savings can be trusted. If the authors redo the comparison using a fixed convergence threshold or demonstrate both chains reach the same posterior, the paper becomes solid.","headline":"A credible MPI port of the ELUCID HMC reconstruction code, but the burn-in savings metric is internally inconsistent and the 8192^3 cost projections rest on an unmeasured extrapolation.","tokens_in":21045,"tokens_out":4407,"would_cite":false,"duration_ms":40924,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"An MPI-parallelized Hamiltonian Monte Carlo reconstruction code with a fast initial-guess module makes 8192^3-particle cosmic initial-condition reconstructions feasible on current HPC hardware.","keywords":["cosmic initial conditions","Hamiltonian Monte Carlo","MPI","domain decomposition","FastPM","burn-in reduction","density field reconstruction","ELUCID-DESI"],"falsifier":"Run a 2048^3 reconstruction with both random and guess initialization and compare the measured CPU hours to the extrapolated values: if per-step wall time grows superlinearly with particle count, or if the burn-in reduction is far below the projected roughly 180 steps, the feasibility estimates for 8192^3 would need to be revised downward.","tokens_in":1436,"feed_emoji":"🔭","tokens_out":1524,"duration_ms":61951,"temperature":0.7,"pith_summary":"This paper claims that Bayesian reconstruction of the cosmic initial density field, previously limited by single-node memory and long burn-in phases, can be scaled to survey-sized volumes through two engineering advances. First, a distributed-memory MPI implementation with domain decomposition and a fast particle-mesh solver shows nearly linear scaling in both particle count and CPU core count, with memory per process following the ideal line. Second, a new initial-guess module starts the Markov chain from a fast approximate linear inversion of the observed density field, cutting burn-in by 53 steps for 256^3 particles and 106 steps for 1024^3 particles, saving thousands of core-hours. The authors argue that these gains together make an 8192^3-particle reconstruction schedulable on about 512 nodes, a scale previously out of reach.","feed_headline":"Parallel code makes 8192^3 cosmic reconstructions practical","feed_subtitle":"MPI scaling stays near-linear and a guess module skips hundreds of costly burn-in steps.","key_machinery":"The load-bearing objects are: the Hamiltonian Monte Carlo sampler, whose potential energy is the negative log-posterior of the initial density field; the FastPM particle-mesh solver, whose modified drift and kick factors reproduce linear growth exactly and serve as the forward model; the three-dimensional domain decomposition that distributes particles and density grids across MPI processes; and the initial-guess module, which performs a fast approximate inversion in Fourier space, dividing by a transfer function built from emulator power spectra. A scale-dependent transfer function calibrates the fast solver against a high-accuracy reference so the likelihood remains unbiased, while the gue","core_discovery":"The central claim is that the two bottlenecks of Hamiltonian Monte Carlo initial-condition reconstruction, the single-node memory ceiling and the expensive burn-in period, can both be removed at scale. The MPI code distributes particles and grids across nodes via three-dimensional domain decomposition, and although communication overhead makes each step about eight times slower than the shared-memory version, wall-clock time still grows almost linearly with particle number and core count for large problems. The initial-guess module applies a transfer-function-weighted linear inversion of the observed final density field to produce a chain start that already lies near the high-probability reg","pith_inferences":["If burn-in savings continue to grow with volume, the dominant cost shifts from initialization to the post-burn-in sampling phase, so future gains would come from faster forward solvers or GPU offloading rather than better starting points.","The measured eightfold per-step MPI slowdown suggests that a hybrid strategy, shared-memory parallelism within a node and MPI across nodes, could recover single-node efficiency without losing the memory advantage.","A direct 2048^3 burn-in test would be the natural check on the extrapolation; without it, the 37-million-core-hour savings figure for 8192^3 remains a projection, not a measurement.","The guess module could likely be pushed further with a nonlinear or learned inversion; if the starting chi-square drops further, convergence could become even faster than the linear-inversion estimate suggests."],"forward_implications":["Bayesian initial-condition reconstruction at 8192^3 particles becomes schedulable on about 512 nodes with roughly 400 GB of memory per node.","The guess module's savings grow with particle count, so the relative cost of burn-in shrinks as survey volumes grow.","Removing the single-node memory ceiling allows the same HMC formalism to be applied to volumes about 64 times larger than earlier reconstructions.","Reconstruction fidelity is maintained: phase correlations match the established characteristic scale relation and reconstructed power spectra agree within about 5 percent for k > 0.05 h/Mpc.","For a 4096^3 DESI-scale reconstruction, the projected total cost is about 5 million core-hours, with the guess module saving roughly 2.3 million core-hours, about 45 percent of the total."],"fun_headline_variants":["MPI + smart guess slash burn-in, make big runs practical","Near-linear scaling cracks 4096^3 cosmic reconstructions","Parallel solver and initial guess cut 45% of burn-in steps","Cosmic initial fields: MPI scales near-linearly, burn-in cut","Smart start halves burn-in for massive cosmic simulations"],"cache_read_input_tokens":22272,"weakest_assumption_plain":"The load-bearing premise is that the nearly linear scaling and burn-in savings measured at 256^3 to 1024^3 particles extrapolate linearly to 8192^3 particles with 32,768 MPI processes; the paper contains no runtime measurement beyond 1024^3.","fun_headline_variants_meta":{"raw":{"variants":["MPI + smart guess slash burn-in, make big runs practical","Near-linear scaling cracks 4096^3 cosmic reconstructions","Parallel solver and initial guess cut 45% of burn-in steps","Cosmic initial fields: MPI scales near-linearly, burn-in cut","Smart start halves burn-in for massive cosmic simulations"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000295,"raw_usage":{"total_tokens":1596,"prompt_tokens":835,"completion_tokens":761,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":579,"completion_tokens_details":{"reasoning_tokens":674}},"tokens_in":579,"tokens_out":761,"duration_ms":9224,"temperature":1.0,"reasoning_tokens":674,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T03:52:51.376586+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a 2048^3 reconstruction with both random and guess initialization and compare the measured CPU hours to the extrapolated values: if per-step wall time grows superlinearly with particle count, or if the burn-in reduction is far below the projected roughly 180 steps, the feasibility estimates for 8192^3 would need to be revised downward.","supporting_citations":[],"review_version":1}