{"id":"5ee9ea37-8ce6-46a3-a2af-11c0a8fcd458","arxiv_id":"2607.25871","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A partitioned, strongly coupled Trixi.jl–deal.II solver for self-gravitating gases is built and validated via convergence, Jeans, and Sedov tests, with parallel scaling to 32 ranks.","lead":"This paper builds a prototype coupling between two established numerical frameworks, Julia's Trixi.jl and C++'s deal.II, to simulate self-gravitating gas dynamics. A smart generalist might read it because it demonstrates a reusable pattern for combining specialized solvers for multi-physics problems.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Load-bearing concern: Trixi.jl's LGL nodal values are treated as deal.II FE_DGQ coefficients, but FE_DGQ uses Gauss–Legendre support points; the claimed exact DoF correspondence may be false.","rationale":"The central claim is that two established solver frameworks can be coupled by exchanging coefficient vectors on a common mesh. For that to be true, the two representations of a discrete function must coincide. The paper's §3.1 and §3.2 explicitly assert that Trixi.jl's LGL DGSEM degrees of freedom are exactly the same as deal.II's FE_DGQ degrees of freedom. This is very likely false: deal.II's FE_DGQ uses Lagrange polynomials with Gauss–Legendre support points, while Trixi.jl uses Gauss–Lobatto points. The difference is not merely academic: the vector of values at LGL nodes is not the coefficient vector for the FE_DGQ basis, so feeding it directly changes the discrete density. The paper's convergence test (Table 1) cannot reveal this because both interpolants achieve O(h^{p+1}) accuracy. The reader's weakest assumption focused on the DG→CG projection error; our concern is that the very first step of the coupling — the 'direct' transfer of DG coefficients — is suspect. If the code implements the transfer correctly via a hidden interpolation, the paper's text is inaccurate and should be corrected; if it does not, the numerical validations are compromised. Either outcome is material, so this is the most load-bearing concern. The verdict remains conditional because the numerical results may still be salvageable after clarifying or fixing the basis correspondence, but the required condition is stronger than the reader's identified projection error.","tokens_in":19528,"tokens_out":10006,"duration_ms":88425,"concrete_test":"In the reproducibility repository, search for the finite-element instantiation: is it FE_DGQ<dim>(degree_dg) or FE_DGQArbitraryNodes with QGaussLobatto? Then trace the density transfer path and check for any interpolation or basis-change routine between Trixi.jl's LGL nodes and deal.II's FE_DGQ nodes. If the element is FE_DGQ and no transformation exists, the claimed exact correspondence is false; if FE_DGQArbitraryNodes is used, the paper's text must be corrected.","verdict_should_be":"UNCHANGED","load_bearing_attack":"In §3.1 the authors state that Trixi.jl's LGL-collocated DGSEM nodes 'can be matched' by deal.II's FE_DGQ<d>(degree), and §3.2 claims the DoF enumeration is 'in exact correspondence with Trixi.jl'. However, deal.II's FE_DGQ is by default built on Gauss–Legendre support points (the interior GL quadrature points), not Gauss–Lobatto points. Trixi.jl's nodal DG vector stores values at LGL nodes. Copying this vector into a deal.II FE_DGQ vector therefore interprets LGL values as coefficients of a different Lagrange basis. The resulting discrete density differs from the Trixi.jl field by a polynomial interpolation error of the same asymptotic order as the DG error, so the observed EOC ≈ p+1 in Table 1 would not detect it. The paper describes no change-of-basis or interpolation step between the two node sets. If the implementation indeed uses FE_DGQ without such a transform, the 'minimally invasive coefficient exchange' premise is false, and the physical tests (Jeans, Sedov) are performed on a corrupted density field, undermining the validation. If the implementation actually uses FE_DGQArbitraryNodes with QGaussLobatto, then the text is misleading and reproducibility suffers. Either way, this unexamined assumption is more basic than the DG→CG projection error the paper acknowledges, and it directly threatens the central coupling mechanism.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a prototype framework for coupling two existing solver frameworks — Trixi.jl (Julia, DGSEM for hyperbolic conservation laws) and deal.II (C++, matrix-free multigrid for elliptic problems) — through a minimally invasive coefficient-exchange interface on a shared p4est Cartesian mesh. The target application is a partitioned, strongly coupled solver for the compressible Euler equations with self-gravity (Poisson equation). The authors validate the coupled solver with a manufactured-solution convergence test (EOC ≈ p+1 for p=3,4), a Jeans-instability test comparing kinetic/internal/potential energies against analytic profiles, and cylindrical/spherical Sedov blast-wave simulations with shock capturing and AMR, comparing the adaptive run with a uniform-mesh reference. They also report MPI strong-scaling results up to 32 ranks. The manuscript is explicitly a proof of concept and provides a public reproducibility repository.","tokens_in":19929,"tokens_out":11158,"duration_ms":104181,"significance":"If the coupling transfer is implemented as described, this is a useful engineering contribution: it demonstrates a working cross-language, parallel, AMR-capable bulk coupling with strong reproducibility infrastructure, and the validation suite contains independent checks — the manufactured solution and the analytic Jeans energies are not fitted to the implementation. The main caveat is that the central 'exact correspondence' between Trixi's LGL DG storage and deal.II's FE_DGQ storage is not accurately documented; resolving this ambiguity either confirms or invalidates the headline coefficient-exchange mechanism. The projection-error concern is secondary. The paper fits the scope of ACM TOMS and its limitations are honestly stated.","major_comments":[{"comment":"The core data-exchange premise is not correctly specified. §3.1 says Trixi's LGL-collocated DGSEM polynomials 'can be matched' by deal.II's FE_DGQ<d>(degree), and §3.2 states that the DG DoF enumeration is 'in exact correspondence with Trixi.jl'. In deal.II, FE_DGQ<d>(degree) is constructed with Gauss–Legendre support points (equivalently FE_DGQArbitraryNodes<d>(QGauss<1>(degree+1))), not Gauss–Lobatto points. Trixi.jl stores values at LGL nodes. Copying that vector into a FE_DGQ vector without a change of basis/interpolation therefore changes the discrete density field by an O(h^{p+1}) perturbation; the manufactured-solution test in Table 1 cannot detect this, because both node sets give order p+1 convergence. If the implementation actually uses FE_DGQArbitraryNodes with QGaussLobatto, then §3.2's code label and §3.1's claim are misleading and the reproducibility repository is needed to","section":"§3.1, §3.2"},{"comment":"The DG-to-CG coupling in the Poisson solve is described only as a weak-form RHS assembly followed by a 'projection back' from Q^{k+1,0} to Q^{k,-1}. The operation that maps the continuous solution to the DG coefficient vector is not defined: is it an L2 projection, nodal interpolation at LGL points, or something else? The statement that this introduces a 'small projection error' is an unquantified assumption. The overall convergence test (Table 1) validates the composition of all steps, but not this specific step; on adapted meshes with hanging nodes the effect could be larger. Please state the projection/interpolation operation and either provide an error estimate/reference or an additional numerical check that isolates its contribution.","section":"§3.1"}],"minor_comments":[{"comment":"The notation is inconsistent: FE_DGQ<d>(degree) appears in §3.1 and FE_DGQ<dim>(degree_dg) in §3.2. More importantly, the paper should give the exact constructor call for the deal.II element (including whether arbitrary LGL support points are used) so that the reproducibility claim is unambiguous.","section":"§3.1, §3.2"},{"comment":"The manufactured Poisson field has a constant residual ±8π, as stated in Eq. (4.3), but it is not included in the residual vector in Eq. (4.4) and the solver-side treatment of this constant source is not described. Please clarify whether the Poisson solve includes a constant source correction or whether the residual is handled implicitly.","section":"§4.1"},{"comment":"The uniform-refinement performance runs use Ω=[-1,1]^3 with level-six refinement, while the AMR runs use Ω=[-2,2]^3 with the same maximum level but a coarser physical cell size in the refined regions. The statements comparing adaptive and non-adaptive run times should be qualified, and the refinement-level convention should be made explicit so the comparison is not over-read.","section":"§4.4"},{"comment":"The sentence 'there is not yet a framework that allows the easy and direct development of coupled solvers' is too strong given the cited coupling libraries (preCICE, etc.). The contribution should be positioned more precisely as a solver-native, low-invasive alternative rather than as the first general coupling framework.","section":"§1"},{"comment":"The caption says 'every second time step' but does not identify which energy curves are plotted. Add a legend or explicitly label kinetic, internal, and potential energy so the visual agreement can be assessed quantitatively.","section":"Fig. 6"}],"recommendation":"major_revision","confidential_remarks":"I found no evidence of duplicate publication or citation manipulation; the scope fits ACM TOMS. The decision hinges on whether the code actually uses an LGL-support-point DG element in deal.II. The authors should be asked to state the exact element type and the transfer operation between the two node bases. If the implementation is correct, the paper is close to acceptable after a focused revision; if not, the central coupling mechanism is invalidated."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a real, working prototype for coupling Trixi.jl and deal.II on a common p4est mesh, with a full validation chain and a public reproducibility repository. The main thing to check before trusting it is the DG node basis.\n\nWhat's new is the artifact itself: a cross-language, MPI-parallel, AMR-capable coupled solver for self-gravitating gas dynamics, with hydrodynamics in Julia/Trixi.jl and the Poisson solve in C++/deal.II, exchanging coefficient vectors through a C wrapper. That combination, plus packaging deal.II as a Julia artifact via BinaryBuilder, is a useful step for anyone who wants to reuse specialized solvers rather than rewrite them. The validation is careful: EOCs of 4.06-4.12 for p=3 and 4.98-5.01 for p=4, Jeans energies matching the analytic curves, and the adaptive Sedov matching the uniform-mesh reference. No fitted parameters; the manufactured solution and analytic energies are independent of the implementation.\n\nThe soft spots, in order of severity:\n\n1. The LGL/Gauss-Legendre node question is the one that matters. deal.II's FE_DGQ<dim>(degree) defaults to Gauss-Legendre support points, and the paper says the DG degrees of freedom are in \"exact correspondence\" with Trixi.jl, which uses LGL. The text never mentions switching to LGL nodes (e.g., via FE_DGQArbitraryNodes). If the code really uses plain FE_DGQ and just copies the vector, the values are interpreted in a different Lagrange basis; the EOC test would not catch it because the interpolation error has the same order as the DG error. That would undermine the \"minimally invasive coefficient exchange\" premise and mean the Jeans/Sedov tests ran on a slightly corrupted density field. If the code does use LGL nodes, the paper should say so. This is load-bearing and needs to be resolved by checking the repository.\n\n2. The \"framework\" language overstates what is there. The authors are honest inside the paper—\"tightly entangled with an example coupled solver\"—but the abstract and title say framework. One example with a hand-built wrapper is a prototype, not a framework. Soften it.\n\n3. The DG-to-CG projection error in the Poisson right-hand side is acknowledged but not quantified. Probably fine for p=3,4 on these tests, but since you're already touching the node question, a short estimate would close the loop.\n\n4. The scaling table reports the minimum of three runs, no variance, and efficiency drops below 40% at 32 ranks. They don't oversell it, but I wouldn't lean hard on the scaling numbers.\n\nThe math and citation pattern look solid; the DG/multigrid ingredients are standard, and the physical setup follows Schlottke-Lakemper et al. 2021 and FLASH docs. This is a serious engineering paper. I would send it to referees, but I'd ask for a revision that addresses the node-set question head-on. If the code already uses LGL, it's a documentation fix; if not, the coupling needs an interpolation step and the validation rerun.\n\nBottom line: worth a serious referee; conditional acceptance until the DG node basis is clarified.","headline":"A genuinely useful cross-language coupling prototype with careful validation, but the unexamined LGL-vs-Gauss-Legendre node mismatch could break the central coefficient-exchange claim.","tokens_in":20377,"tokens_out":2966,"would_cite":false,"duration_ms":27559,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["65M60","65N55","65Y05","65M70"],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper shows that two mature, independently developed solver frameworks—a Julia DG code and a C++ finite-element library—can be coupled with thin wrappers into a strongly coupled, adaptive, parallel solver for self-gravitating gas dynam","keywords":["multi-physics coupling","discontinuous Galerkin spectral element method","multigrid Poisson solver","self-gravitating gases","adaptive mesh refinement","partitioned coupling","parallel scaling","compressible Euler equations"],"falsifier":"Run the manufactured-solution problem on meshes with hanging nodes and aggressive refinement while the projection between Q^k and Q^{k+1,0} is active; if the observed order drops below p+1, or the Jeans-instability energies drift from their analytical curves under adaptation, then the small-projection-error premise fails.","tokens_in":19446,"feed_emoji":"🌌","tokens_out":8021,"duration_ms":71294,"temperature":0.7,"pith_summary":"The paper sets out to prove a practical point: you do not need a monolithic code to solve a coupled multi-physics problem. Its claim is that two specialized, separately developed solver frameworks—one for hyperbolic conservation laws, one for elliptic equations—can be joined through thin wrappers into a single strongly coupled, adaptive, parallel solver, provided they share one mesh and exchange only solution vectors in matching degrees of freedom. The demonstration case is the dynamics of Newtonian self-gravitating gases, where compressible Euler equations are coupled in volume to a Poisson equation for the gravitational potential. The authors validate the prototype by showing the expected p+1 order of convergence, agreement with analytical Jeans-instability energy profiles, and correct Sedov blast waves under h-adaptivity, with MPI scaling demonstrated up to 32 ranks. A sympathetic reader would take the paper's claim to be that this coupling pattern is a viable template for assembling multi-physics solvers from existing single-physics frameworks.","feed_headline":"Julia-C++ solver pair hits predicted order for self-gravitating gas","feed_subtitle":"Euler-Poisson test passes convergence, Jeans-instability, and Sedov blast-wave checks.","key_machinery":"The load-bearing mechanism is the degree-of-freedom match between the two discretizations: Trixi.jl's DGSEM uses tensor-product Lagrange polynomials collocated at Legendre–Gauss–Lobatto nodes, which is the same element as deal.II's FE_DGQ<k>; both solvers build their own meshes from the same refinement indicators on a common forest-of-octrees structure, so a one-to-one cell loop works without geometric searches. The elliptic stage projects density into FE_Q<k+1> (one degree higher, continuous) for the Poisson solve, then truncates the potential back to the discontinuous space; the multigrid preconditioner is matrix-free and runs in single precision inside a double-precision CG iteration. Str","core_discovery":"The central claim is that a partitioned, strongly coupled solution of the Euler–Poisson system can be obtained by running two independent frameworks on the same forest-of-octrees mesh and exchanging only solution-vector coefficients. The key match is that Trixi.jl's Legendre–Gauss–Lobatto-collocated DGSEM polynomials are exactly the deal.II discontinuous Q^k elements, so density coefficients need no interpolation before entering the elliptic solver. The elliptic solver projects the discontinuous density onto a continuous space of one degree higher (Q^{k+1,0}), solves the Poisson equation by matrix-free geometric multigrid, and projects the potential back to the original discontinuous space;","pith_inferences":["A natural extension the authors leave implicit: replace the Poisson multigrid stage with another elliptic operator (e.g., radiation diffusion or incompressibility constraint) and the same mesh-plus-coefficient-transfer pattern would apply, making the prototype a generic volume-coupling template.","The paper states in §3.1 that the Q^{k+1,0}→Q^{k,-1} truncation introduces a 'small projection error' but does not analyze it a priori; one high-value follow-up is a projection-error estimate on adapted meshes, since hanging nodes are where an uncontrolled error would first show up.","The benchmark table shows mesh adaptation after every time step consumes 45–48% of runtime and rebuilds multigrid data structures; a cheaper strategy that adapts less frequently or reuses level data would likely improve throughput, though the authors caution that too-long adaptation intervals can destabilize the run.","Because the two solvers communicate only solution vectors, the approach could be extended to non-Cartesian or curved meshes by keeping the same coefficient-transfer logic, as the authors note in the outlook."],"forward_implications":["If the coupling is right, the same pattern can deliver p+1-order accuracy for other bulk-coupled hyperbolic-elliptic systems, not just Euler–Poisson.","The convergence and Jeans tests mean the stage-wise potential solve does not destroy the expected order or physical energy balance.","The h-adaptive Sedov computation matches a uniformly refined reference, so AMR can be enabled without losing fidelity in the coupled problem.","Parallel scaling to 32 ranks with nearly constant solver-time fractions indicates both components scale alike, so larger runs are not bottlenecked by one side.","The fully reproducible artifact (Julia project plus prebuilt C++ library) means other groups can run and extend the coupled solver without building deal.II from source."],"fun_headline_variants":["Julia+C++ solvers mesh for gravity check","Two frameworks, one coupled gas test","Adaptive solver coupling passes gravity benchmark","Cross-language pair verifies Euler-Poisson order","Coupling Trixi and deal.II for self-gravity"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that projecting the discontinuous density onto a one-degree-higher continuous finite-element space for the Poisson solve, and truncating the potential back, introduces only a 'small projection error' — an assumption the paper does not analyze a priori, only verifies indirectly through the convergence test.","fun_headline_variants_meta":{"raw":{"variants":["Julia+C++ solvers mesh for gravity check","Two frameworks, one coupled gas test","Adaptive solver coupling passes gravity benchmark","Cross-language pair verifies Euler-Poisson order","Coupling Trixi and deal.II for self-gravity"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000199,"raw_usage":{"total_tokens":1197,"prompt_tokens":725,"completion_tokens":472,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":469,"completion_tokens_details":{"reasoning_tokens":400}},"tokens_in":469,"tokens_out":472,"duration_ms":4589,"temperature":1.0,"reasoning_tokens":400,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T01:13:18.833965+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the manufactured-solution problem on meshes with hanging nodes and aggressive refinement while the projection between Q^k and Q^{k+1,0} is active; if the observed order drops below p+1, or the Jeans-instability energies drift from their analytical curves under adaptation, then the small-projection-error premise fails.","supporting_citations":[],"review_version":1}