{"id":"a06e2878-0be7-4d53-8179-9209b320de9e","arxiv_id":"2607.19631","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"svMultiPhysics, a C++ port of the svFSI solver with a GPU linear-algebra backend, runs coupled cardiovascular CFD, fluid-structure interaction, and cardiac electrophysiology simulations, scaling to 256 cores and showing preliminary 19-30x GPU speedups for a diagonal-preconditioned case.","lead":"A new open-source C++ solver from the SimVascular project simulates blood flow, vessel-wall mechanics, and heart electrical signals in one framework, with early GPU tests showing up to about 30 times faster runs for one linear solver choice. The paper reports three realistic test cases (aneurysm flow, fluid-structure interaction, cardiac electrophysiology) and measures how the solver scales on supercomputers.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"svMultiPhysics' inherited accuracy from svFSI is unsupported by any head-to-head comparison; the line-by-line translation claim is not verified.","rationale":"The reader's weakest assumption is exactly the load-bearing issue: the paper provides no evidence that svMultiPhysics reproduces svFSI results. My analysis of the manuscript confirms this: the accuracy claim in the Conclusions explicitly relies on validation of precursor formulations, and no direct comparison is presented anywhere in the results. I considered whether the GPU performance claim might be a more central weakness, but the paper labels it as 'preliminary' and explicitly acknowledges the hardware confound (different CPU and GPU platforms), so it is a recognized limitation rather than a hidden assumption. The numerical-correctness concern, by contrast, is unacknowledged and fundamental. I do not find internal inconsistencies in the governing equations or the numerical methods as described. The monolithic FSI formulation, the VMS stabilization, and the generalized-alpha time integration are standard and cited appropriately. The lack of a translation verification is an addressable gap, not a fatal flaw; the open-source repository and CI pipeline provide a foundation for such a test. Therefore, the conditional verdict remains appropriate: the paper should be accepted only if the authors add the head-to-head verification or clearly downgrade the inherited-validation claim to a claim about the original svFSI code, not svMultiPhysics.","tokens_in":22748,"tokens_out":3045,"duration_ms":35323,"concrete_test":"Run the three paper benchmarks (AAA CFD, AAA FSI, biventricular EP) with both svFSI and svMultiPhysics on the same CPU node, using identical meshes, boundary conditions, solver settings, time steps, and convergence tolerances. Compare output fields (velocity, pressure, displacement, activation times) at matched time steps using relative L2 norm differences. Separately, run the same cases on the GPU-enabled svMultiPhysics build and compare to the CPU build. Acceptable threshold: normalized field differences below the prescribed linear/nonlinear solver tolerance (e.g., 1e-6) or consistent with round-off. If differences exceed this threshold, the line-by-line translation or GPU execution alters the numerics and inherited validation does not hold.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central accuracy claim rests entirely on inheritance. The Introduction states svMultiPhysics is 'an essentially direct line-by-line translation of the svFSI solver code into C++,' and the Conclusions state that 'confidence in the accuracy of svMultiPhysics is supported by a broader validation history of the SimVascular solver ecosystem and its precursor formulations,' citing refs [99–102]. However, the paper presents no head-to-head comparison between svFSI and svMultiPhysics on any benchmark, no re-verification against an analytical or experimental reference, and no mesh/time-step convergence study. The CI/CD integration tests described in 'Software development platform' verify that benchmarks 'run successfully and exhibit consistent convergence behavior'—they do not establish that outputs match svFSI to within solver tolerance. If the translation introduced a sign error, a misordering of operations, a missing stabilization term, or a subtly altered residual assembly, the inherited validation would not apply, and every subsequent accuracy claim would be void. This risk is compounded for the GPU path: when Trilinos/Kokkos offloads linear algebra to the GPU, device-side reductions, solver tolerances, and preconditioner behavior may differ numerically from the CPU path, and the paper provides no CPU-vs-GPU consistency check for the same problem. This is the single most load-bearing concern because the paper's value as a trustworthy solver depends on behavioral identity with svFSI; without evidence of identity, the validated status of the precursor does not transfer.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces svMultiPhysics, an open-source C++ finite element solver for cardiovascular multiphysics simulation, positioned as the successor to the Fortran-based svFSI solver within the SimVascular ecosystem. It describes the governing equations for incompressible Navier-Stokes flow, solid mechanics, scalar advection-diffusion, and cardiac electrophysiology, together with the numerical methods (VMS stabilization, generalized-alpha time integration, Newton-Raphson, monolithic ALE-FSI) and the available linear algebra backends (FSILS, Trilinos, PETSc). The results section reports strong scaling and wall-clock measurements for three benchmark applications—an AAA CFD case, an AAA FSI case, and a biventricular cardiac electrophysiology case—and a preliminary CPU-vs-GPU comparison claiming up to approximately 30x wall-clock speedup for selected Trilinos preconditioners. The paper's accuracy argument rests on the claim that svMultiPhysics is a direct line-by-line translation of svFSI and therefore inherits svFSI's prior validation history.","tokens_in":23017,"tokens_out":4375,"duration_ms":50327,"significance":"If the central claims hold, svMultiPhysics would be a valuable open-source, GPU-capable multiphysics solver that consolidates CFD, FSI, and cardiac EP within one framework and is tightly integrated with the SimVascular patient-specific modeling pipeline. The paper has notable strengths: the solver is openly developed with CI/CD, Docker-based builds, unit and integration tests, and the three benchmarks are realistic, clinically relevant problems with concrete scaling and runtime data. The monolithic FSI formulation and the 1D-3D Purkinje-myocardium coupling are nontrivial capabilities that the paper documents. However, the manuscript currently establishes capability and performance more convincingly than numerical accuracy. The inherited-validation claim is not directly supported, and several paper-level accuracy statements exceed what is demonstrated. With the additions suggested below, the paper could serve as a useful reference for the community.","major_comments":[{"comment":"The accuracy claim is load-bearing and unsupported. The paper states that svMultiPhysics is an 'essentially direct line-by-line translation' of svFSI and that 'confidence in the accuracy of svMultiPhysics is supported by a broader validation history' (refs 99-102), while the Author summary claims the benchmarks demonstrate 'the ability to accurately reproduce key physiological quantities.' No head-to-head svFSI-vs-svMultiPhysics comparison is presented, no benchmark output is compared against an analytical or measured reference, and no mesh or time-step convergence study is included. The CI/CD integration tests described in 'Software development platform' verify only that benchmarks 'run successfully and exhibit consistent convergence behavior,' which does not establish quantitative equivalence. Please add at least one direct comparison of svMultiPhysics against svFSI (e.g., L2 differenc","section":"Conclusions; Software development platform"},{"comment":"The headline GPU speedup is based on a platform-confounded measurement. CPU runs used Stampede3 Intel Xeon CPU MAX 9480 nodes, while GPU runs used Sherlock nodes with NVIDIA Tesla A40 GPUs; the paper itself notes that 'the two platforms therefore do not constitute an otherwise identical software and hardware environment.' The 30x figure therefore includes both hardware and software-stack differences, not a controlled CPU-vs-GPU comparison of the same node with and without GPU offload. Additionally, timings cover only two time steps and include fixed setup costs. While the text appropriately labels these as preliminary, a headline claim of 'up to approximately 30x wall-clock speedup' should be supported by a same-node controlled experiment, or substantially qualified relative to this one limited configuration.","section":"AAA: Preliminary GPU Performance Comparison"},{"comment":"The manuscript states that the examples demonstrate 'nonlinear and linear convergence,' but the reported results contain no residual convergence histories, no nonlinear or linear solver tolerance settings, and no iteration counts. Figures 2-9 show only strong scaling and wall-clock times. Without residual convergence data or stated tolerances (e.g., Newton and Krylov tolerances, generalized-alpha rho_inf, time step sizes), the convergence behavior and the 'computational efficiency' claims cannot be assessed or reproduced. Please include convergence plots or tables for the three benchmarks and report the numerical settings used.","section":"Author summary; Results and discussion"},{"comment":"The cardiac EP benchmark is presented only through wall-clock scaling results; there is no quantitative output, such as activation times, action potential morphology, or comparison to a reference solution. Given that the case involves a patient-specific biventricular geometry, a rule-based fiber field, a generated Purkinje network, and Purkinje-myocardium coupling, the manuscript should report at least basic verification metrics (e.g., activation timing at selected points or ECG waveforms) and the spatial mesh resolution relative to the diffusion length scale, to establish that the numerical solution is meaningful rather than merely that the solver runs.","section":"Cardiac electrophysiology simulation"}],"minor_comments":[{"comment":"Typo: 'cardiac computed tomogrpahy' should be 'cardiac computed tomography.'","section":"Introduction"},{"comment":"The Author summary uses first-person singular ('I present', 'My goal') although the paper has multiple authors; please change to first-person plural or impersonal phrasing.","section":"Author summary"},{"comment":"The description of the code provenance is inconsistent: the Introduction says an 'essentially direct line-by-line translation' while the Conclusions say a 'systematic translation.' Please use one precise characterization, since the strength of the inheritance argument depends on it.","section":"Introduction; Conclusions"},{"comment":"Equation (3) writes the viscous stress as 2mu(u)epsilon, but the text defines mu as a function of shear rate; use mu(gamma_dot) for consistency with the non-Newtonian models discussed.","section":"Eq. (3)"},{"comment":"The caption says 'identical MPI configurations and solver settings' but the CPU and GPU runs used different hardware platforms; clarify that only MPI and solver settings were identical, not the execution environment.","section":"Figure 6 caption"},{"comment":"Formatting issues: 'T able 1' and 'V alve modeling' have stray spaces; 'Table 1' and 'Valve modeling' should be corrected.","section":"Headings and table titles"},{"comment":"Reference [4] is formatted inconsistently ('Hrvoje J' instead of a full author name); check all references for consistency with the journal style.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is a software-description manuscript whose central risk is the unverified inheritance of svFSI's validation record. The fix is feasible within the manuscript's scope: add a direct svFSI-vs-svMultiPhysics comparison on at least one benchmark and re-scope the accuracy language. The GPU speedup claim should also be re-benchmarked or carefully qualified. I do not see grounds for rejection; the solver itself appears substantial and well-integrated. The main question for the editor is whether a solver paper without new validation can be accepted in this venue; my recommendation of major revision reflects the expectation that a head-to-head comparison is feasible and should be required."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nBottom line: this is a solid infrastructure paper, not a validation study, and it is honest about that. What is new is the C++ reimplementation of the group's Fortran svFSI solver inside SimVascular, a Trilinos/Kokkos path that puts linear algebra on GPUs, and fresh performance numbers on three realistic cases: AAA CFD, AAA ALE-FSI, and biventricular EP with a coupled 1D Purkinje network. The physics is standard, and the contribution is the consolidation: one maintained open-source code that can do CFD, solid mechanics, FSI, scalar transport, and EP in the same finite-element framework. That is useful enabling infrastructure for cardiovascular modeling.\n\nCredit where it is due. The code is public, there is a CI/CD pipeline with Docker builds, unit and integration tests, and the benchmark descriptions are concrete. The strong-scaling data to 256 processes is plausible, and the wall-clock comparisons among preconditioners are informative. The authors also label the GPU results as preliminary and explicitly note that CPU and GPU runs happened on different hardware. That restraint makes the 19-30x GPU numbers easy to accept as a promising upper bound rather than a misleading claim.\n\nThe soft spot is exactly the one flagged in the stress test. Accuracy is inherited, not demonstrated. The conclusion says confidence in accuracy is supported by svFSI's prior validation history, and the paper presents no head-to-head svMultiPhysics-vs-svFSI comparison, no re-verification against an analytical or measured reference, and no mesh or time-step convergence study. The author summary claims the solver can accurately reproduce key physiological quantities, but the results section contains no comparison to measured data. The CI tests verify that cases run and converge consistently; they do not verify output equivalence to the precursor. For a direct translation the risk may be modest, but it is not zero, and the GPU path adds another layer where reductions and preconditioner behavior can differ. A single careful comparison would close this gap.\n\nWho is this for? Groups using SimVascular or evaluating a multiphysics solver for CFD/FSI/EP. They should read the performance claims as real but preliminary, and should not treat the inherited validation as a substitute for a reproducibility check.\n\nRecommendation: send it to peer review. It is a serious, reproducible software contribution; the referee's main job should be to require the accuracy comparison before publication.","headline":"Solid infrastructure paper that inherits rather than demonstrates accuracy; useful to the community once a head-to-head svFSI check is added.","tokens_in":23632,"tokens_out":4309,"would_cite":true,"duration_ms":46453,"reading_group":"yes","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 introduces svMultiPhysics, an open-source C++ finite element solver that unifies cardiovascular fluid dynamics, solid mechanics, diffusion, and cardiac electrophysiology in a single computational framework.","keywords":["svMultiPhysics","cardiovascular simulation","finite element method","fluid-structure interaction","cardiac electrophysiology","SimVascular","GPU acceleration","patient-specific modeling"],"falsifier":"Run the identical AAA CFD and FSI benchmarks (same mesh, boundary conditions, time step, solver settings, tolerances) in both svFSI and svMultiPhysics, on the same CPU hardware; if velocity, pressure, or displacement fields differ by more than round-off-level agreement, or if nonlinear/linear iteration counts diverge substantially, the inherited-validation claim collapses. A second check is to run the GPU configuration and the CPU configuration on the same platform for the same case and verify that results agree to the same tolerance as the CPU-only pipeline.","tokens_in":22577,"feed_emoji":"🫀","tokens_out":7941,"duration_ms":74538,"temperature":0.7,"pith_summary":"This paper presents svMultiPhysics, a new open-source finite element solver written in C++ that treats fluid dynamics, solid mechanics, scalar transport, and cardiac electrophysiology within one computational framework. The authors argue that because the code is an essentially direct line-by-line translation of the validated svFSI solver, it inherits that solver's numerical accuracy while gaining a more modular, extensible design and optional GPU-accelerated linear algebra. They support the claim with three patient-specific simulations — a rigid-wall abdominal aortic aneurysm CFD case, a monolithic ALE fluid–structure interaction case, and a biventricular electrophysiology case with a Purkinje network — showing good strong scaling to 256 processors and, in preliminary CPU–GPU comparisons, up to roughly 30× wall-clock speedup for selected linear solver configurations. If true, the field gains a single, openly developed multiphysics backend for the SimVascular patient-specific modeling pipeline.","feed_headline":"One C++ solver unifies cardiac flow, mechanics, and electrical signals","feed_subtitle":"C++ solver gives the SimVascular pipeline one code for CFD, FSI, and electrophysiology; GPU trials show up to 30x speedups.","key_machinery":"The carrying mechanism is the solver's unified residual-based variational multiscale (VMS) finite element formulation, applied consistently to fluid, solid, and fluid–structure interaction problems, together with a common data structure, a generalized-α time integrator, Newton–Raphson nonlinear iteration, and swappable linear algebra backends (in-house FSILS, plus third-party libraries with an optional GPU path). This shared infrastructure is what makes the modular 'solve independently or coupled' design possible, and it is the feature the three benchmarks are meant to demonstrate.","core_discovery":"The central claim is that svMultiPhysics provides a unified finite element framework in which the equations governing cardiovascular fluid dynamics, solid mechanics, diffusion, and cardiac electrophysiology can be solved independently or strongly coupled, with a monolithic ALE fluid–structure interaction formulation as the flagship coupling. The solver is a direct C++ translation of the Fortran svFSI solver, so its accuracy is claimed by inheritance from svFSI's published validation studies rather than by new verification. Three representative simulations demonstrate the range: CFD and FSI on a patient-specific abdominal aortic aneurysm and 1D–3D coupled cardiac electrophysiology on a bivent","pith_inferences":["The GPU speedup numbers are two-step timings that include host-side setup; a natural test is whether multi-cycle production runs show larger amortized gains, likely pushing the diagonal-preconditioner case beyond 30× while shrinking the multigrid gain.","The presence of active-stress solid mechanics and monodomain electrophysiology in one framework points toward a fully coupled cardiac electromechanics-fluid simulation as the likely next demonstration, which the paper does not itself run.","The performance results reproduce a general pattern: special-purpose physics-informed preconditioners win when one physical process dominates, while algebraic multigrid wins when coupling stiffens the system; that suggests user guidance for selecting solvers in new coupled cases.","A head-to-head equivalence test of the C++ translation against the Fortran solver on identical inputs would settle whether the inherited validation history applies in practice."],"forward_implications":["Cardiovascular researchers can simulate blood flow, wall mechanics, and electrical activation in one code with a consistent discretization, removing the need to couple separate solvers by hand.","Users of the SimVascular pipeline gain a single maintained 3D multiphysics solver that can be extended with new physics modules without rewriting the core.","GPU-accelerated linear algebra can reduce wall-clock time for linear-solve-dominated cardiovascular problems by up to roughly 30× in preliminary testing, making high-throughput parameter studies more practical.","The solver comparisons give practical guidance: the specialized resistance-based BIPN preconditioner is fastest for rigid-wall CFD, while algebraic multigrid is preferable for FSI; lightweight diagonal-preconditioned CG is best for electrophysiology.","If the direct-translation premise holds, the published validation history of svFSI transfers to svMultiPhysics, so existing patient-specific workflows can migrate confidence along with code."],"fun_headline_variants":["One open-source C++ solver couples cardiac flow, mechanics, and signals","Cardiac multiphysics in one solver: flow to electrical signals","30x faster GPU solves for coupled cardiac simulation in svMultiPhysics","SimVascular's solver unifies cardiac mechanics, flow, and electrical signals","One finite element solver for heart flow, mechanics, and signals"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the line-by-line C++ translation of svFSI is numerically equivalent to the original, so the solver's accuracy rests on inherited validation rather than on any comparison, re-verification, or convergence study presented in this paper.","fun_headline_variants_meta":{"raw":{"variants":["One open-source C++ solver couples cardiac flow, mechanics, and signals","Cardiac multiphysics in one solver: flow to electrical signals","30x faster GPU solves for coupled cardiac simulation in svMultiPhysics","SimVascular's solver unifies cardiac mechanics, flow, and electrical signals","One finite element solver for heart flow, mechanics, and signals"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000922,"raw_usage":{"total_tokens":3824,"prompt_tokens":813,"completion_tokens":3011,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":557,"completion_tokens_details":{"reasoning_tokens":2918}},"tokens_in":557,"tokens_out":3011,"duration_ms":21248,"temperature":1.0,"reasoning_tokens":2918,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T12:09:57.140291+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the identical AAA CFD and FSI benchmarks (same mesh, boundary conditions, time step, solver settings, tolerances) in both svFSI and svMultiPhysics, on the same CPU hardware; if velocity, pressure, or displacement fields differ by more than round-off-level agreement, or if nonlinear/linear iteration counts diverge substantially, the inherited-validation claim collapses. A second check is to run the GPU configuration and the CPU configuration on the same platform for the same case and verify that results agree to the same tolerance as the CPU-only pipeline.","supporting_citations":[],"review_version":1}