{"id":"9b7ab977-2866-4c80-a9af-205128ddec8a","arxiv_id":"2411.18341","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"PHOENIX provides an optimized, extensible open-source solver for 2D nonlinear Schrödinger equations that outperforms a conventional MATLAB RK4 implementation by up to three orders of magnitude in speed.","lead":"PHOENIX is a new open-source software package that solves two-dimensional nonlinear Schrödinger equations on CPUs and GPUs, with support for extra physics terms like spin-orbit coupling, reservoirs, and quantum noise. The authors report up to a thousand-fold speedup and 99.8% energy savings compared with a conventional MATLAB implementation, with the code publicly available for download.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Energy-savings claim is derived from peak-power extrapolation, not direct measurement; the 99.8% figure likely overstates the true energy advantage.","rationale":"The central claim is that PHOENIX is a highly optimized and energy-efficient solver, with headline numbers of up to 1000x speedup and 99.8% energy savings versus a conventional MATLAB RK4 implementation. The speedup is a directly timed quantity, and the roofline analysis independently supports that PHOENIX performs close to bandwidth bounds; thus the speedup claim is credible even if the baseline choice is debatable. The energy savings, however, are not directly measured for the comparison. The caption of Fig. 1 explicitly states that they are derived from speedup and peak power, assuming both codes run at peak power for the entire workload. For the CPU MATLAB code, peak socket power is likely higher than the actual consumption during a single-threaded or memory-bound execution, inflating the claimed savings. The paper's own energy measurements in Sec. 4.5 use RAPL and NVML directly, but the MATLAB baseline is not measured with that approach. Because the energy-savings number is a headline result and is used in the abstract and conclusion, this methodological gap is the most load-bearing weakness. A direct RAPL/NVML measurement of both codes for a representative case would settle whether the 99.8% figure is accurate. This does not undermine the core software contribution, but it does require a caveat or revision of the headline energy claim, consistent with the reader's conditional verdict.","tokens_in":28680,"tokens_out":7513,"duration_ms":66588,"concrete_test":"Re-measure energy consumption for a representative workload (e.g., 1024x1024 grid, 1000 RK4 steps) using RAPL for the MATLAB baseline on the same CPU and NVML for PHOENIX on the same GPU, following the methodology in Sec. 4.5. Compute E_PHOENIX and E_MATLAB directly and compare savings = 1 - E_PHOENIX/E_MATLAB with the 99.8% claimed in Fig. 1(b). If the directly measured savings differ by more than a few percentage points, the headline energy claim needs revision.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Figure 1(b) reports up to 99.8% energy savings, but the caption states that 'energy savings are determined by the speedup and the peak power consumption for large grids manually measured using HWiNFO.' This is a derived quantity, not a direct energy measurement of the two codes. It implicitly assumes both the MATLAB baseline and PHOENIX sustain peak power for the entire run. For a CPU-based MATLAB code, peak socket power is a poor proxy for actual consumption, especially if MATLAB executes single-threaded or stalls between sparse matrix-vector products. The paper's own direct energy methodology in Sec. 4.5 (RAPL for CPU, NVML for GPU) is not applied to the MATLAB baseline. Consequently, the 99.8% figure is an upper bound computed from peak power and speedup, and it likely overstates the true energy advantage. The speedup claim is directly timed and thus less vulnerable, but the energy claim is central to the title and abstract.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents PHOENIX, an MIT-licensed open-source C++/CUDA solver for the two-dimensional dissipative nonlinear Schrödinger equation and its extensions, including spinor fields, reservoir dynamics, coherent and incoherent driving, and stochastic noise. The solver uses an explicit RK4 integrator with a five-point Laplacian, subgrid decomposition for cache reuse, optional FFT smoothing, and fp32/fp64 support. Benchmarks on several CPUs and GPUs are compared with a roofline model, and the paper reports up to a 1000x speedup and 99.8% energy savings relative to a MATLAB sparse-matrix RK4 implementation. Four application examples from exciton-polariton physics are included to demonstrate the solver's breadth.","tokens_in":28837,"tokens_out":13900,"duration_ms":127592,"significance":"If the quantitative claims are fully substantiated, PHOENIX would be a valuable community resource: it ships public, MIT-licensed code with benchmark documentation, a parameter-free roofline model based on measured hardware bandwidths, and a simple extension interface for non-specialist users. The four worked examples show practical breadth, although they largely reproduce the authors' own earlier results rather than providing independent validation. The main uncertainty is not in the basic numerical scheme or the PHOENIX-side measurements, which are credible, but in the two headline comparison claims: the energy saving is derived from peak-power assumptions rather than direct measurement, and the speedup is measured against a baseline whose code is not provided. These issues affect the abstract and title and therefore need to be resolved before the paper's central claims can be accepted.","major_comments":[{"comment":"The headline claim of energy savings 'up to 99.8%' is not supported by direct energy measurement. As the Fig. 1 caption states, the energy savings are 'determined by the speedup and the peak power consumption for large grids manually measured using HWiNFO.' This assumes both PHOENIX and the MATLAB baseline sustain their peak power for the entire run, which is implausible for a CPU-bound sparse-matrix MATLAB code with idle and stall phases. The paper already has a direct energy methodology with RAPL and NVML in Sec. 4.5 for PHOENIX; the same methodology should be applied to the MATLAB baseline, or the 99.8% figure should be relabeled as an upper-bound estimate and removed from the abstract and title.","section":"Fig. 1(b), Sec. 4.5, Abstract"},{"comment":"The three-orders-of-magnitude speedup is measured against a baseline that is described only by a short paragraph and whose code and exact configuration are not deposited. A sparse-matrix-vector RK4 code in MATLAB is one plausible 'conventional' implementation, but it is not demonstrated to be representative, and the comparison also conflates the programming-language and hardware changes. Please release the MATLAB benchmark script with all settings (sparse-matrix construction, time step, precision, MATLAB version, threading, and whether gpuArray is used), and ideally report the speedup against at least one additional baseline such as a vectorized or spectral MATLAB solver.","section":"Sec. 3.1 and Fig. 1(a)"},{"comment":"None of the performance or energy curves includes repeated-run statistics. The paper makes precise quantitative statements such as 'between 51% and 94% of the cache bandwidth bound' and '24-30 nJ per grid point update', and the 99.8% energy-saving figure rests on single-point comparisons. At minimum, the headline comparisons in Fig. 1 should report the mean and min-max spread over several runs, and the measurement protocol for the manually measured peak power should be described in enough detail to be replicable.","section":"Figs. 4-6 and Sec. 4.1"},{"comment":"The roofline estimate in Eq. (12) excludes the halo exchange and the extra halo-cell computations described in Secs. 3.2.4 and 3.2.6, yet Fig. 4 compares that estimate with full RK4 timings that include those costs. For subgrid settings with small subgrids, the halo overhead is not negligible, so the reported fractions of the cache-bandwidth bound are optimistic. Please quantify the halo overhead or restrict the 'close to the bound' comparison to runs without subgrid decomposition.","section":"Sec. 3.2.8 and Eq. (12)"}],"minor_comments":[{"comment":"The factor 2 in Eq. (12) is not explained in the text; since each complex buffer contains two real components, please state that explicitly when d is introduced.","section":"Sec. 3.2.8 and Eq. (12)"},{"comment":"The AMD 7763 full-CPU row lists Pfp32 (2.5 TFlop/s) as smaller than Pfp64 (5.1 TFlop/s), which is inconsistent with the 5800X3D row and with the usual Zen3 fp32/fp64 throughput relation; please verify these values or explain the measurement result.","section":"Table 2"},{"comment":"The phrase 'grid sizes beyond approximately 10^4' is ambiguous; it should say 10^4 points per spatial dimension, consistent with the 15000 x 15000 grid discussion in Sec. 5.1.","section":"Sec. 3.2.6"},{"comment":"The parameters E0 and omega for the coherent drive are only given in the reference list entry [80]; they should be defined in the main text for readability.","section":"Sec. 5.1 and Eq. (16)"},{"comment":"There are several typographical errors: 'Phyton' in the Introduction, 'peridoic' and 'V ortices' in Sec. 5, and 'AMD 77632 CPU' in the Fig. 5 caption.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a software paper for Computer Physics Communications, and the core solver design with subgrid decomposition, CUDA graphs, and vectorization is a reasonable contribution. My main concern for the editor is the gap between the abstract's 'energy savings of up to 99.8%' and the actual measurement basis described in the Fig. 1 caption. If the authors can measure the MATLAB baseline directly with RAPL or an external power meter, the claim could become solid; if not, the energy claim should be removed from the abstract and title. The application examples reproduce the group's own earlier results, which is acceptable for demonstration purposes but provides no independent cross-check. I would not recommend rejection, because the PHOENIX-side performance model and benchmarks are plausible and the repository is publicly available."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Bottom line: this is a genuinely useful software contribution and the performance story mostly holds up, but the 99.8% energy-saving figure is an extrapolation, not a measurement, and should not be quoted without a caveat.\n\nWhat is actually new is not the numerical scheme — RK4 on a uniform grid with FFT filtering is standard — but the packaged, extensible solver. The code is clean, public, and benchmarked across entry-level to high-end GPUs and CPUs. The subgrid decomposition for cache efficiency is a real implementation contribution, and the roofline comparison is the strongest part of the paper: update rates reach 51–94% of cache-bandwidth bounds on GPUs and saturate memory bandwidth on large grids. That is reproducible evidence, backed by a public repo. The application examples — 9000×9000 grid, exceptional-point localization via a local optimizer, 2250 Monte Carlo samples — show the tool makes previously impractical computations feasible.\n\nThe soft spots are at the edges. The MATLAB baseline is self-defined; a well-vectorized or spectral solver would shrink the headline speedup. That is a minor issue because the authors document the baseline and the speedup remains large. More significant is the energy claim. Figure 1(b) reports up to 99.8% energy savings, but the caption says this is “determined by the speedup and the peak power consumption... manually measured using HWiNFO.” That is an upper bound computed from peak power, not a direct measurement of energy consumed by the MATLAB code. Section 4.5 applies RAPL/NVML direct energy measurements to PHOENIX, but not to the baseline, so the abstract's energy number is likely overstated. The speedup claim is directly timed and credible; the energy claim needs recharacterization.\n\nNo repeated-run statistics or error bars on benchmarks is a minor complaint; the trends are clear and consistent. The citation pattern is healthy, with self-references used mainly to compare against the authors' earlier physical results.\n\nWho this is for: anyone doing 2D NLSE/Gross-Pitaevskii simulations on GPUs, especially polariton and cold-atom groups who want an open-source, extensible solver. It deserves a serious referee. I would recommend accepting it after the energy analysis is corrected or reframed; the central contribution — a fast, open, extensible solver — stands.","headline":"Solid, useful software paper; the speedup claim is credible, but the 99.8% energy saving is extrapolated from peak power, not directly measured.","tokens_in":29356,"tokens_out":2471,"would_cite":true,"duration_ms":21840,"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":"This paper presents PHOENIX, an open-source C++/CUDA solver claiming up to a thousandfold speedup and 99.8% energy savings over a conventional MATLAB implementation for two-dimensional nonlinear Schrödinger equations.","keywords":["nonlinear Schrödinger equation","Gross-Pitaevskii equation","GPU computing","Runge-Kutta methods","cache optimization","energy efficiency","exciton-polariton condensates","open-source solver"],"falsifier":"Benchmark PHOENIX and a vectorized or spectral MATLAB solver of the same equation on the same grids while directly metering wall-clock energy draw of each process; a speedup well below three orders of magnitude or an energy saving far below 99.8 percent would falsify the headline claim.","tokens_in":28500,"feed_emoji":"⚡","tokens_out":8504,"duration_ms":75466,"temperature":0.7,"pith_summary":"PHOENIX is introduced as an open-source solver for the two-dimensional dissipative nonlinear Schrödinger equation and its extensions. The authors aim to establish that a carefully cache-optimized explicit Runge-Kutta implementation can make large-scale, statistically demanding simulations routine on ordinary consumer GPUs. Against a conventional sparse-matrix MATLAB RK4 implementation, they report speedups up to three orders of magnitude and energy savings up to 99.8%. If true, this removes a practical bottleneck: users can run very large grids, optimization loops, and Monte Carlo ensembles with quantum noise on a single workstation.","feed_headline":"PHOENIX solver: up to 1000x speedup, 99.8% less energy","feed_subtitle":"Cache-tuned Runge-Kutta code for nonlinear Schrödinger equations reaches bandwidth limits on ordinary GPUs.","key_machinery":"The load-bearing mechanism is subgrid decomposition: the full $N_x \\times N_y$ grid is divided into smaller subgrids, each surrounded by a halo of neighboring cells, so every RK4 step operates on data that fits in the last-level cache. The spatial derivative uses a five-point stencil, the intermediate RK4 sums are modeled as STREAM-triad-like kernels, and a Roofline model using measured device cache and memory bandwidths predicts the iteration-time floor. This decomposition turns a low-computational-intensity stencil into a cache-bandwidth-bound calculation, which is why the solver can approach hardware limits on consumer GPUs.","core_discovery":"The paper's central claim is that the bottleneck in two-dimensional nonlinear Schrödinger time evolution is data movement, not arithmetic, and PHOENIX is built around that fact. By decomposing the grid into cache-sized subgrids with halos and expressing RK4 as a sequence of stencil and summation kernels, the solver reaches 51 to 94 percent of the cache-bandwidth bound on tested GPUs and saturates memory bandwidth for large grids. The same design yields up to three orders of magnitude speedup and up to 99.8 percent energy savings compared with a conventional MATLAB implementation, with single-precision runs roughly doubling throughput whenever the physics tolerates reduced precision.","pith_inferences":["The 99.8 percent energy saving is best read as an upper bound: it is derived from the speedup multiplied by manually measured peak power rather than from simultaneous energy metering of both codes, so the true energy advantage over an efficient MATLAB implementation is likely smaller.","The speedup claim is tied to the sparse-matrix RK4 MATLAB baseline; a MATLAB user already working with spectral or well-vectorized methods should expect a much smaller gain, and the 'conventional' label may overstate how representative that baseline is.","The observed gap between the H100's summation kernels and the cache-bandwidth bound points to a concrete next target: improving cache behavior of the two- and five-term sums could push datacenter GPUs closer to the bound, not just consumer GPUs.","The same subgrid-plus-Roofline recipe may transfer to other low-computational-intensity stencil solvers beyond the nonlinear Schrödinger family, such as reaction-diffusion or wave-propagation codes, though the paper does not claim this extension."],"forward_implications":["Simulations that were previously too slow for routine exploration, such as 9000-by-9000-grid corner states or optimizer-driven exceptional-point searches, become one-hour or one-day tasks on a single GPU.","Statistical studies needing many repeated runs, such as 150- or 2250-sample Monte Carlo ensembles for quantum-state tomography, become practical on consumer hardware rather than large HPC allocations.","Users can extend the equation set with additional Hamiltonian terms or new integrators by editing short arithmetic kernels, without writing explicit parallel code.","Because the solver is transfer-bound rather than arithmetic-bound, single-precision execution approximately halves data movement and doubles throughput when physics permits it, with the paper noting sharp spectral resonances as an exception.","The subgrid design offers a direct path to multi-GPU or multi-node execution by distributing subgrids, extending the solver to grids that exceed a single device's memory."],"supporting_citations":[{"why":"The PHOENIX software release provides the benchmarked code, benchmark documentation, and all application examples used in the paper.","marker":"[23]"},{"why":"Defines the memory-bandwidth and machine-balance concepts used to derive computational-intensity thresholds for the Roofline comparison.","marker":"[30]"},{"why":"Provides the STREAM triad benchmark pattern used to model the two-term and five-term summation kernels in the RK4 step.","marker":"[31]"},{"why":"Supplies the measured CPU cache and memory bandwidths and peak floating-point rates used as inputs to the Roofline model.","marker":"[32]"},{"why":"Supplies the measured GPU cache and memory bandwidths used to define the performance bounds for the tested GPUs.","marker":"[33]"},{"why":"Provides the H100 hardware specifications against which the H100 benchmark results are interpreted.","marker":"[34]"},{"why":"Provides the Ada-architecture GPU specifications used for the RTX 4090 and RTX 4060 Ti benchmarks.","marker":"[35]"},{"why":"Earlier CUDA Gross-Pitaevskii solvers whose reported speedups frame the performance improvement claimed for PHOENIX.","marker":"[16]"},{"why":"A prior single-precision GPU Gross-Pitaevskii solver that motivates the precision investigation and design choice in PHOENIX.","marker":"[19]"}],"fun_headline_variants":["PHOENIX: 1000x faster nonlinear Schrödinger solver","Cache-tuned PHOENIX: 1000x speedup, 99.8% less energy","PHOENIX: beating data-movement bound for NLSE","Open-source PHOENIX: 99.8% energy cut, 1000x speedup"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central claim assumes that the MATLAB sparse-matrix RK4 code is a fair 'conventional' baseline and that energy savings computed from runtime ratio and peak power approximately equal true energy use.","fun_headline_variants_meta":{"raw":{"variants":["PHOENIX: 1000x faster nonlinear Schrödinger solver","Cache-tuned PHOENIX: 1000x speedup, 99.8% less energy","PHOENIX: beating data-movement bound for NLSE","Open-source PHOENIX: 99.8% energy cut, 1000x speedup"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000503,"raw_usage":{"total_tokens":2489,"prompt_tokens":1010,"completion_tokens":1479,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":626,"completion_tokens_details":{"reasoning_tokens":1386}},"tokens_in":626,"tokens_out":1479,"duration_ms":11744,"temperature":1.0,"reasoning_tokens":1386,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T11:16:54.738325+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Benchmark PHOENIX and a vectorized or spectral MATLAB solver of the same equation on the same grids while directly metering wall-clock energy draw of each process; a speedup well below three orders of magnitude or an energy saving far below 99.8 percent would falsify the headline claim.","supporting_citations":[{"cited_title":"Wingenbach, D","cited_arxiv_id":null,"evidence_quote":"The PHOENIX software release provides the benchmarked code, benchmark documentation, and all application examples used in the paper."}],"review_version":1}