{"id":"2b176306-026d-456d-b2c2-e871ccb295de","arxiv_id":"2501.18185","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"MetaWave decouples Hamiltonian, wavefunction, and parallelization via C++ templates to enable a single codebase for nonrelativistic and relativistic selected-CI methods.","lead":"MetaWave is a C++ software platform that lets quantum chemists write one set of code templates for both ordinary and relativistic molecular wavefunction methods. The paper describes its three-layer architecture and shows timing benchmarks for three flavors of the iCIPT2 method on the bromine atom.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Listing 14 shows tag-dispatch overloads, not one shared template body, so the 'same templates' claim is ambiguous and unverified at the HME core.","rationale":"I read the paper as making a software-architecture claim. The strongest assertion is that the same templates assemble nonrelativistic and relativistic wavefunctions. The paper's own listings show specialization at the Hamiltonian-matrix-element level, and because the full code is not included, a reader cannot tell whether the reused part is the whole algorithm or only the outer workflow skeleton. This determines whether the platform achieves the strong unification claimed in the abstract or merely a workflow-level templating on top of separate relativistic kernels. A compile-time instantiation census would settle the question directly. I do not think this invalidates the paper; it supports the existing CONDITIONAL verdict. I partially agree with the reader's Kramers-pair concern: it is a legitimate limitation, but it is explicitly stated and standard for time-reversal-symmetric molecular spinors, so it is less directly load-bearing than the ambiguity about which code paths are actually shared.","tokens_in":27997,"tokens_out":9734,"duration_ms":101305,"concrete_test":"Instrument the MetaWave build (e.g., with `-fdump-tree-original` or a static template-instantiation counter) while compiling the same wavefunction-layer module once with `tag::Hamiltonian::ElectronNonRela` and once with `tag::Hamiltonian::ElectronRela`. Enumerate the template instantiations whose bodies are identical across the two builds and those that resolve to distinct overloads such as `_generate_table_sngl` and `_fetch_ints_sngl`. If the shared-body count is zero in the HME kernel, the unification claim holds only for the outer workflow; if the shared-body count includes the HME kernel, the claim is confirmed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.2.4's Listing 14 defines `_generate_table_sngl` and `_fetch_ints_sngl` as two overloads distinguished by `tag::Hamiltonian::ElectronNonRela` versus `tag::Hamiltonian::ElectronRela`. That is C++ tag dispatch: the compiler selects between two distinct function bodies, not a single template instantiated for both. The same pattern appears in the integral manager, where `perm_symm_t<SymTy>` changes the storage layout. The paper states that the wavefunction layer can assemble NR and relativistic wavefunctions with the same templates, and that is plausible for the outer selection/PT2 workflow (Secs. 2.4-2.5). But the Hamiltonian-layer kernel that actually evaluates HMEs appears specialized per Hamiltonian. The sentence \"Due to the complexity ... we do not delve into details here\" (Sec. 3.2.4) means this cannot be checked from the paper. If \"same templates\" is meant literally, the code excerpts are evidence against it; if it is meant only for high-level workflow, the central claim is narrower than the abstract's \"assembled with the same templates\" suggests. The reader's Kramers-pair concern is real but explicitly assumed in Sec. 2.1 and standard for time-reversal-symmetric molecular spinors; the ambiguity of what code is actually shared is more directly load-bearing.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces MetaWave, a C++ template-based software platform for unified implementation of nonrelativistic (spin-free) and relativistic (spin-dependent) wavefunction methods. It decouples three aspects—Hamiltonian nature, wavefunction structure, and parallelization—through type-trait and tag systems. The theoretical core reviews a unified second-quantized Hamiltonian decomposition, a common diagrammatic evaluation of basic coupling coefficients for spin-free and spin-dependent CSFs/DETs, and the iCIPT2 selection plus constraint-based ENPT2 workflow. The software architecture is described in three layers (infrastructure, Hamiltonian, wavefunction) with code listings for linear algebra interfaces, OpenMP/MPI parallel templates, configuration spaces, integral storage, and HME-evaluation helpers. A showcase on the Br atom compares sf-X2C-iCIPT2, SOiCI, and 4C-iCIPT2 spin-orbit splittings against experimental NIST values and reports PT2 wall times and MPI scaling.","tokens_in":28249,"tokens_out":7120,"duration_ms":72180,"significance":"If the central claim holds, MetaWave would provide a genuinely useful modular framework that reduces code duplication when extending correlated wavefunction methods from nonrelativistic to relativistic Hamiltonians. The paper's conceptual decomposition (Sec. 2) is coherent and builds on a substantial body of prior work, and the spin-orbit splittings in Table 2 are anchored to experiment, giving an external validity check. The concrete MPI scaling result (94% efficiency for 16 nodes in Sec. 3.1.2) and the linear PT2 fits in Table 4 are reproducible quantitative claims. The listed infrastructure-layer abstractions (BLAS wrapper, OpenMP algorithm base, MPI scheduler) are plausible and supported by code excerpts. However, the strongest advertised benefit—that the same C++ templates assemble both nonrelativistic and relativistic wavefunctions down to the Hamiltonian matrix-element kernel—is not substantiated in the manuscript, which is a significant gap for a platform paper.","major_comments":[{"comment":"The abstract and Sec. 2.1 promise \"unified evaluation of the basic coupling coefficients\" and \"assembled with the same templates\" for nonrelativistic and relativistic wavefunctions. At the Hamiltonian-layer core, however, Listing 14 shows two overloads of _generate_table_sngl and _fetch_ints_sngl distinguished by the tag types tag::Hamiltonian::ElectronNonRela and tag::Hamiltonian::ElectronRela. That is tag dispatch, i.e., compile-time selection between two distinct function bodies, not one template body instantiated for both Hamiltonians. The same section explicitly states \"Due to the complexity ... we do not delve into details here,\" so the reader cannot verify the unified-templates claim at the HME level. This is load-bearing: the central selling point of the paper is either narrower than stated (shared wavefunction-layer workflow, per-Hamiltonian HME kernels) or is unverified by the provided evidence. The authors should either qualify the abstract and Sec. 2.1 to say that the shared templates operate at the selection/PT2/diagonalization level while HME kernels are specialized per Hamiltonian, or provide a concrete single template body that demonstrably generates both spin-free and spin-dependent BCCs/HMEs.","section":"Sec. 3.2.4, Listing 14"},{"comment":"The TUGA table maker is presented as a unified BCC-evaluation template, but the listing is only a skeleton. It instantiates _propagate_segment2 and _propagate_segment1 with template parameter TableTy and an integer region index, yet no instantiation of TableTy is shown for either the spin-free CSF case or the spin-dependent spinor/Kramers-pair case. The type traits that supposedly specialize the segment values are not listed. Consequently, the paper does not establish that the BCC evaluation is implemented by a single code body rather than by separate specializations behind a common interface. A concrete example, even for a single segment type, would let the reader judge whether the unification is real at the kernel level.","section":"Sec. 3.2.1, Listing 8"},{"comment":"The PT2 wall-time comparison between sf-X2C-iCIPT2, SOiCI, and 4C-iCIPT2 mixes two variables: the Hamiltonian/wavefunction type and the size of the orbital/spinor space (e.g., (17e,68o) vs (17e,136o) for the DZ basis). The paper correctly notes relative costs in brackets, but the headline statement \"the PT2 step of 4C-iCIPT2 is typically 10-15 times that of SOiCI\" is driven largely by the doubled spatial-orbital count in the 4C case, not by a direct architectural inefficiency. Please separate the intrinsic cost of the relativistic Hamiltonian (more integrals, complex scalars, larger spaces) from any platform-induced overhead; as written, the showcase does not cleanly demonstrate the efficiency of MetaWave's unified implementation.","section":"Sec. 4, Table 3"}],"minor_comments":[{"comment":"The second overload of _fetch_ints_sngl declares the template parameter as TableInfoTransferTy but uses TableTy in the function parameter list; this appears to be a typographical error and should read TableTy consistently.","section":"Listing 14"},{"comment":"Several typos: \"involes\" should be \"involves\", and \"varitional space\" should be \"variational space\" (the latter also appears near the discussion of pruning).","section":"Sec. 2.4"},{"comment":"Phrase \"enhancing code cleaning\" should likely be \"enhancing code clarity\" or \"enhancing code cleanliness\", and \"devided\" should be \"divided\" in the discussion of the MPI scheduler.","section":"Sec. 3.1.2"},{"comment":"The word \"metafuncions\" is a typo for \"metafunctions\", and the term \"external terms\" (has_oneext_term, has_twoext_term) is not defined in the text; please explain what one-external and two-external terms mean in the Hamiltonian decomposition.","section":"Sec. 3.2.1"},{"comment":"The abstract claims \"full molecular symmetry (including single or double point group)\", but the implemented symmetry support listed in Sec. 3.4 is \"Binary point group symmetry\" and \"Binary double point group symmetry\", and Sec. 3.2 explicitly says \"(abelian) spatial symmetry\". Please qualify the claim to abelian/binary point groups, or explain how non-abelian single/double point groups are handled.","section":"Abstract and Sec. 3.4"},{"comment":"The statement that point group symmetries are not used for storage reduction, because all integrals fit in memory for fewer than 1000 correlated orbitals, is a practical decision; it should be flagged as a scalability limitation for larger active spaces where integral storage may become memory-bound.","section":"Sec. 3.2.3"},{"comment":"The paper does not provide a public repository or code availability statement for MetaWave. Given that the paper's claims are about software architecture, an explicit code-availability link or a clear statement of why the code is not yet released would strengthen reproducibility.","section":"Sec. 3.1.2 and Sec. 4"}],"recommendation":"major_revision","confidential_remarks":"The manuscript leans heavily on the authors' own prior publications (Refs 6, 7, 16, 17, 36) for the Hamiltonians, diagram decomposition, and iCIPT2 algorithm; this is natural given the research lineage, but the incremental contribution of this paper is the platform architecture itself. The central architectural claim—that the same templates span nonrelativistic and relativistic wavefunction methods—is currently more an assertion than a demonstrated fact, because the HME-level code excerpts show tag dispatch rather than a shared template body. I also note that the paper does not release the code, which may matter for a platform paper. If the authors can provide a concrete template-level illustration of a unified HME/BCC kernel (or explicitly narrow the claim), the paper would be acceptable; as-is, the gap between abstract and evidence is too large for acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe short version: this is a software architecture paper, not a new method paper. The genuinely new content is MetaWave's C++ template design and a Br atom benchmark; the selection and PT2 workflow is indeed shared across nonrelativistic and relativistic Hamiltonians, but the Hamiltonian-matrix-element kernels still rely on tag-dispatch overloads rather than one shared template body. Read the \"same templates\" claim with that in mind.\n\nWhat the paper does well: it gives the first full description of a platform that already underlies the authors' published iCIPT2/SOiCI/4C-iCIPT2 work, and it is honest about the lineage—HORTON/Fanpy and the earlier iCIPT2 papers are cited and the differences are stated clearly (no Python, high-performance, relativistic support). The decoupling of Hamiltonian, wavefunction, and parallelization via type traits/tags is a sensible way to cut code duplication, and the MPI extension from OpenMP via serialization and a dynamic scheduler is a reasonable design. The Br showcase is a real external anchor: spin-orbit splittings land within a few percent of the NIST value, and the PT2 wall times scale linearly with the variational space size across three Hamiltonians.\n\nThe soft spots are real but not fatal. The code is not released, so the architecture cannot be inspected beyond the excerpts. The central claim is narrower than the abstract suggests: Listing 14 shows two overloads of _generate_table_sngl and _fetch_ints_sngl selected by Hamiltonian tag, which is tag dispatch, not a single template instantiated for both spin-free and spin-dependent cases. The paper even says \"we do not delve into details here\" for the HME evaluation, so the reader cannot verify how much of that layer is truly shared. The automatic MPI translation details are deferred to another publication; the one benchmark (94% efficiency on 16 nodes, one molecule) is promising but thin. The Kramers-pair assumption flagged by the skeptic is explicitly stated and standard for time-reversal-symmetric molecular spinors, so I would not treat that as a weakness. The mathematical core is prior work, but that is fine for a platform paper.\n\nBottom line: this is worth a serious referee. It is the kind of paper a method developer will want to study, and the performance data are reproducible. The referee should push for a clear statement of exactly which layers share templates and ideally for access to the code or a more detailed appendix. Send it to review, with a request to sharpen the claim.","headline":"A solid software architecture paper whose 'same templates' claim is true at the workflow level but not at the Hamiltonian kernel level; worth reviewing, but ask for code or a sharper claim.","tokens_in":28803,"tokens_out":2864,"would_cite":true,"duration_ms":27268,"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":"MetaWave claims that once any second-quantized Hamiltonian is decomposed into the same topological diagrams, one set of C++ templates can assemble nonrelativistic and relativistic wavefunctions alike.","keywords":["relativistic quantum chemistry","selected configuration interaction","C++ template metaprogramming","type-trait and tagging system","unitary group approach","Kramers pairs","spin-orbit coupling","second-quantized Hamiltonian"],"falsifier":"Take a spin-dependent calculation whose spinors violate the Kramers-pairing assumption, for example spinors from a system with an external magnetic field that breaks time-reversal symmetry, and run it through the same MetaWave spin-dependent templates: either the coupling-coefficient evaluation fails or it silently needs a different code path, which would disprove the claimed full unification.","tokens_in":27772,"feed_emoji":"⚛️","tokens_out":6935,"duration_ms":63908,"temperature":0.7,"pith_summary":"MetaWave is a C++ template platform whose central claim is that nonrelativistic and relativistic many-electron wavefunction methods do not need separate implementations. The paper argues that every second-quantized Hamiltonian, spin-free or spin-dependent, can be broken into the same topological diagrams, so the coupling coefficients between configuration state functions or determinants can be evaluated by one shared routine. With the Hamiltonian's nature, the wavefunction's structure, and the parallelization strategy decoupled through C++ type traits and tags, the same templates then build wavefunctions regardless of whether the orbitals are real scalar orbitals or complex spinors. If this holds, relativistic extensions of correlation methods can be implemented with far less new code, which matters for high-precision spectroscopy where relativity, correlation, and quantum electrodynamics must be treated together.","feed_headline":"Same templates build relativistic and nonrelativistic wavefunctions","feed_subtitle":"A diagram-based Hamiltonian decomposition lets one C++ codebase handle spin-free and spin-dependent correlated methods.","key_machinery":"The central mechanism is the diagrammatic decomposition of second-quantized Hamiltonians: the generic Hamiltonian is split into $H^0_1$, $H^1_1$, $H^0_2$, $H^1_2$, and $H^2_2$ (zero, single, and double excitation levels), and each term is drawn as a one- or two-body diagram of the types s2, cx, and dx, following the unitary group approach. These diagrams are used to evaluate the basic coupling coefficients (BCCs)—the matrix elements of elementary excitation operators between CSFs or determinants—in exactly the same way for spin-free and spin-dependent cases, with reduced occupation tables (ROTs) built from orbital configurations (oCFGs) ensuring reuse of coefficients across configuration pairs. Around this core, the paper places a C++ type-trait and tagging system: tags label Hamiltonian types and permutation symmetries, type traits expose their properties at compile time, and templates propagate the chosen scalar type (real versus complex) and parallel base class, allowing the same wavefunction layer to run with different Hamiltonians, bases, and symmetry groups.","core_discovery":"The paper's discovery is an architecture-level unification: the three aspects that normally force code rewrites in quantum chemistry—the type of Hamiltonian (spin-free versus spin-dependent), the structure of the many-particle basis (CSFs versus determinants, scalar orbitals versus spinors), and the parallelization pattern (OpenMP, MPI)—can be treated as independent template parameters. The load-bearing step is the decomposition of the generic Hamiltonian $H = \\sum_{ij} h_{ij} E_{ij} + \\frac{1}{2} \\sum_{ijkl} (ij|kl) e_{ij,kl}$ into zero-, single-, and double-excitation components whose terms correspond to diagrams, so that the same diagram types supply the basic coupling coefficients for both spin-free and spin-dependent wavefunctions, with Kramers-paired spinors doubling each vertex's terms in the spin-dependent case. On top of that, the C++ type-trait and tagging system lets the compiler generate the right storage, symmetry handling, and code paths for each combination, and an OpenMP-to-MPI functor translates most shared-memory parallel algorithms into distributed-memory ones. The result is demonstrated with three variants of the same selected-configuration-interaction method—sf-X2C-iCIPT2, SOiCI, and 4C-iCIPT2—which share the infrastructure and differ only in the Hamiltonian, basis, and integral symmetry.","pith_inferences":["If the BCC layer is genuinely Hamiltonian-independent, the same templates should extend to the QED, multicomponent, electron-phonon, and matter-light Hamiltonians the paper mentions as future directions; that extension would be a strong test of the architecture rather than an already-demonstrated result.","The claimed unification predicts that implementing a brand-new wavefunction ansatz, such as a relativistic DMRG with spin-adapted matrix product states, should require only the ansatz's own logic and reuse all Hamiltonian, integral, and BCC layers; the number of new lines needed would be a concrete metric.","A practical side effect not quantified in the paper is maintainability: if the shared-template claim holds, fixes to the coupling-coefficient or parallelization layers propagate automatically to every method built on MetaWave, reducing divergence between nonrelativistic and relativistic code paths."],"forward_implications":["A new spin-dependent or nonrelativistic Hamiltonian can be added by supplying its integrals and tags, while the wavefunction assembly, selection, and perturbation code remains shared.","MPI versions of newly implemented methods are obtained largely by inheriting the OpenMP algorithm template, since the scheduler dispatches chunks to idle worker nodes and only data merging is specialized.","The same diagrammatic Hamiltonian also connects Slater-Condon rules, the unitary group approach, and matrix-product operator evaluations, so DMRG and selected CI can share the coupling-coefficient machinery.","The type-trait system prunes irrelevant code paths at compile time, so generic code does not pay the cost of, for instance, double excitations in a Hubbard model that does not have them.","Benchmarks on the bromine atom show the spin-orbit variant costs about 1.5 to 2 times the spin-free one, and the four-component variant 10 to 15 times more, with PT2 wall times scaling linearly with the variational space size."],"supporting_citations":[{"why":"Establishes the unified construction of relativistic Hamiltonians, underpinning the claim that all relativistic and QED Hamiltonians share the same second-quantized form.","marker":"[6]"},{"why":"The relativistic 4C-iCIPT2 implementation that serves as the spin-dependent showcase for the shared templates.","marker":"[7]"},{"why":"The nonrelativistic iCIPT2 method with the reduced occupation table and unitary-group BCC machinery that MetaWave reuses.","marker":"[16]"},{"why":"Further iCIPT2 developments, including selection criteria, upper bounds, and the pipelined constraint-based PT2 algorithm.","marker":"[17]"},{"why":"Construction of Kramers-paired double-group symmetry functions, supplying the assumption that spinors can be grouped into Kramers pairs.","marker":"[57]"},{"why":"The graphical unitary group approach with the segment-value product formula and diagram nomenclature used for the BCCs.","marker":"[58]"},{"why":"Shavitt graph step numbers used in the product-form BCC evaluation, connecting UGA to the MPO/MPS formulation.","marker":"[59]"},{"why":"Matrix product operator and matrix product state formulation that the diagrammatic Hamiltonian also unifies for DMRG.","marker":"[60]"}],"fun_headline_variants":["MetaWave unifies relativistic and nonrelativistic wavefunctions","One template codebase runs both spin-free and spin-dependent methods","Diagram decomposition lets one platform handle all wavefunction types","C++ architecture decouples Hamiltonian, wavefunction, and parallelization"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The unification depends on molecular spinors being symmetrizable into Kramers pairs consistent with double point group and time reversal symmetry; if a spinor basis cannot be organized into such pairs, the unified spin-dependent diagrams and the shared templates would break down.","fun_headline_variants_meta":{"raw":{"variants":["MetaWave unifies relativistic and nonrelativistic wavefunctions","One template codebase runs both spin-free and spin-dependent methods","Diagram decomposition lets one platform handle all wavefunction types","C++ architecture decouples Hamiltonian, wavefunction, and parallelization"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000237,"raw_usage":{"total_tokens":1563,"prompt_tokens":1060,"completion_tokens":503,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":676,"completion_tokens_details":{"reasoning_tokens":432}},"tokens_in":676,"tokens_out":503,"duration_ms":5208,"temperature":1.0,"reasoning_tokens":432,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T00:21:28.972904+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a spin-dependent calculation whose spinors violate the Kramers-pairing assumption, for example spinors from a system with an external magnetic field that breaks time-reversal symmetry, and run it through the same MetaWave spin-dependent templates: either the coupling-coefficient evaluation fails or it silently needs a different code path, which would disprove the claimed full unification.","supporting_citations":[{"cited_title":"Unified Implementation of Relativistic Wave Function Methods: 4C-iCIPT2 as a Showcase","cited_arxiv_id":null,"evidence_quote":"The relativistic 4C-iCIPT2 implementation that serves as the spin-dependent showcase for the shared templates."},{"cited_title":"On the construction of Kramers paired double group symmetry functions","cited_arxiv_id":null,"evidence_quote":"Construction of Kramers-paired double-group symmetry functions, supplying the assumption that spinors can be grouped into Kramers pairs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The graphical unitary group approach with the segment-value product formula and diagram nomenclature used for the BCCs."},{"cited_title":"Graph theoretical concepts for the unitary group approach to the many-electron correlation problem","cited_arxiv_id":null,"evidence_quote":"Shavitt graph step numbers used in the product-form BCC evaluation, connecting UGA to the MPO/MPS formulation."},{"cited_title":"K.-L.; Keselman, A.; Nakatani, N.; Li, Z.; White, S","cited_arxiv_id":null,"evidence_quote":"Matrix product operator and matrix product state formulation that the diagrammatic Hamiltonian also unifies for DMRG."}],"review_version":1}