Node-Level Performance and Energy Characterization of Flagship Science Applications on SuperMUC-NG Phase 2
arXiv:2606.23265v1 [cs.DC] 22 Jun 2026
Intel Sapphire Rapids and Ponte Vecchio Salvatore Cielo1 , Elmira Birang1 , Alexander Pöppl2 , Sajad Azizi1 , Plamen Dobrev1 , Margarita Egelhofer1 , Ivan Pribec1 , and Gerald Mathias1 1
Leibniz Supercomputing Center (LRZ), Boltzmannstraße 1, 85748 Garching b. München, Germany {azizi, birang, cielo, dobrev, egelhofer, mathias, pribec}@lrz.de https://www.lrz.de 2 Intel Deutschland GmbH, Germany [email protected]
Abstract. We present a systematic performance and energy-efficiency characterization of five flagship scientific workloads on SuperMUC-NG phase 2, the 28 PetaFLOPs system at the Leibniz Supercomputing Center (LRZ) equipped with Intel Xeon Platinum 8480+ and Intel Data Center GPU Max 1550 (Ponte Vecchio, PVC) accelerators. The selected codes span molecular dynamics (gromacs, lammps), astrophysics and cosmology (OpenGadget3, AthenaK), and finite-element PDE solvers from the dealii-X Center of Excellence. For each code we measure throughput and energy efficiency per compute element – expressed as compute-elements per wall-clock second (or per Joule of consumed energy) – on a single compute node, comparing CPU-only (SPR) against combined CPU+GPU (SPR+PVC) configurations where available. Energy measurements rely on lightweight code instrumentation with p3em, or the Energy Aware Runtime (EAR) present on the system. Our results show that GPU offload yields 4–12× higher throughput and up to 15× better energy efficiency compared to CPU-only execution, with lammps and AthenaK benefiting most. However, both throughput and energy gains are sensitive to problem granularity: insufficient work per GPU tile erodes the accelerator advantage, as clearly observed in AthenaK at small mesh-block sizes. The power-budget utilization is systematically lower for CPUs than it is for GPUs, indicating that even at peak useful-work rate, most applications running on CPUs leave a significant fraction of the node’s thermal envelope unused. Keywords: Intel Data Center GPU Max 1550· Intel Xeon Platinum 8480+· Intel Sapphire Rapids · Intel Ponte Vecchio · performance characterization · energy efficiency · molecular dynamics · astrophysics · PDE solvers · HPC benchmarking
2
S. Cielo et al.
1
Introduction
Next-generation HPC platforms combine multi-socket CPU nodes with powerful accelerators on high-bandwidth intra-node interconnects, creating an increasingly heterogeneous compute landscape[9]. Understanding the performance and energy behavior of scientific applications on these platforms is essential for both users and system administrators; energy in particular is both a primary driver of total cost of ownership, and a convenient measure of intensive hardware performance for comparing different devices. SuperMUC-NG phase 2 at the Leibniz Supercomputing Center (LRZ) is one of the first production systems worldwide based on Intel’s general purpose data center GPU architecture, pairing Intel Xeon Platinum 8480+ CPUs with Intel Data Center GPU Max 1550. This paper presents a systematic, multi-application characterizations of this platform, covering five codes from three scientific domains: (i) Molecular dynamics (gromacs [2,15,14,12], lammps [19]) (ii) Astrophysics and cosmology (OpenGadget3 [16], AthenaK [17]) (iii) PDE solvers (selected kernels from the dealii-X Center of Excellence [8]). The codes present a variant degree of optimization and GPU utilization; we selected them based on usage cases and not efficiency. For each code we adopt holistic node-level metrics for throughput and energy efficiency, enabling fair, domain-agnostic comparison between CPU-only and CPU+GPU execution modes where available. The study directly informs practitioners migrating workloads to PVC-equipped systems and provides feedback to hardware and software vendors on real application behavior.
2
System Description
SuperMUC-NG phase 2 is hosted at the Leibniz Supercomputing Center (LRZ) (Garching, Germany). Its 240 compute nodes are each equipped with (i) two Intel Xeon Platinum 8480+ (codename Sapphire Rapids, 56 cores, 512 GB DDR5; SPR in the following), (ii) four Intel Data Center GPU Max 1550 (codename Ponte Vecchio, 128 GB HBM2e each, ∼52 TFLOP/s FP64, henceforth PVC), (iii) Intel XeLink interconnect within the node. With a Thermal Design Power (TDP) of 350 Watt for SPR and a nominal 600 Watt for PVC (power-capped to 450 Watt on this system), the single-node power budget used below is WTDP = 2500 Watt. All the benchmarks and their dependencies are built with the latest generation of Intel oneAPI compilers on the system (v2025.3.0), and Intel MPI (v2021.17.0). In this stack, the large compute cards default to be subdivided into two logical tiles each (explicit scaling), to which Intel MPI can pin tasks sequentially. Thus the simplest usage model to target all devices is to run in parallel with 8 MPI tasks per node. We specify below when a different strategy is used.
Title Suppressed Due to Excessive Length
3
3
Methodology
All measurements are single-node, isolating the per-node performance and energy cost without network effects. Throughput and specific energy-efficiency metrics are computed as: Nelements · Nsteps twall
Nelements · Nsteps enode (1) where Nelements is the number of compute elements (atoms, mesh zones, degrees of freedom), Nsteps is the number of time steps executed, twall is elapsed wall-clock time, and enode is total node energy consumption. As shown in previous work [5], we observe that the energy-efficiency definition is also valid for larger node counts, being the ratio of two extensive quantities (both the numerator and enode are proportional to the hardware size, e.g. number of used nodes). For throughput, an additional normalization by the number of used nodes would be necessary. For gromacs, energy readings are obtained via EAR [6], which wraps Intel Running Average Power Limit (RAPL) – CPU package + DRAM – and GPU power counters, yielding integrated energy measures over the full workload. For all other codes, consumed node energy is sampled using p3em3 , which offers finer time granularity (100 ms resolution for all benchmarks). p3em provides several energy meter options to adapt to different systems, vendors, and varying levels of user access to hardware counters. In this work, CPU energy is read via the Linux perf interface – which in turn 4 reads RAPL Model Specific Registers (MSRs) – and GPU energy via xpu-smi. A comparison between p3em and EAR on the same data (from the AthenaK benchmark) is discussed in Sect. 5.2. Throughput: T =
4
Energy efficiency: E =
Benchmarks and Results
Table 1 provides an overview of all five benchmarked codes, their offload strategies, throughput metrics, and single-node peak results. The following subsections describe each benchmark and discuss the corresponding measurements. 4.1
gromacs– Molecular Dynamics
gromacs [2,15,14,12]is an open-source, highly parallel software package for running classical molecular dynamics (MD). It is capable of utilizing almost all modern hardware, including computer-center-class GPUs, offloading the major part of particle interactions onto the latter, while only small parts of 3 4
https://github.com/svtcli/p3em https://www.intel.com/content/www/us/en/developer/articles/ technical/software-security-guidance/advisory-guidance/ running-average-power-limit-energy-reporting.html
4
S. Cielo et al.
Table 1: Summary of benchmarked applications and single-node peak results. Abbreviations: EAR = Energy Aware Runtime [6]; p3em = https://github.com/ svtcli/p3em gromacs
lammps
OpenGadget3
AthenaK
dealii-X kernels
Domain
Molecular dynamics
Molecular dynamics
Astrophysics and Cosmology
Astrophysics and Cosmology
PDE / FEM
Offload strategy
SYCL/OpenCL native GPU offload
Kokkos (SYCL)
Intel OpenMP offload
Kokkos Kokkos (SYCL) (SYCL/OpenMP)
Atom-steps
Atom-steps
Particle-steps
Throughput Metric
Zone-cycles
DoF
Energy tool
EAR
p3em
p3em
p3em
p3em
Largest tested problem size (node)
> 4.3 × 107 atomsa
3.5 × 106 atoms
3.36 × 107 particlesb
∼ 1.47 × 108 zonesc
8 × 108
Peak throughput
∼ 4 × 108
∼5 × 108
4.68 × 105
∼6 × 106
∼6 × 1010
Peak energy efficiency
∼ 2 × 105
∼4 × 105
∼660d
∼3 × 104
∼6 × 107
Only results up to 1.1 × 107 atoms are shown in this work; larger problems were also tested on one node. The simulation size is 2 × 2563 particles, half of which are gas particles and half dark matter particles. c Derived from 288 generated meshblocks, times user input of 803 mesh size; the maximum refinement level is 5. d The mean simulation energy efficiency is at ∼ 660, whereas the isolated HSML kernel reaches a peak efficiency of ∼ 6 × 103 . a
b
the calculations required for MD, such as pressure coupling, are still carried out on the CPUs. Here we use the SYCL implementation of gromacs, with all non-bonded and bonded interactions and the atomic coordinate updates offloaded to the PVC cards. To optimize communications among multiple GPUs, gromacs distributes the neighboring atoms on the same processing unit (domain decomposition). The long-range electrostatics is calculated across the entire system via Particle Mesh Ewald (PME) [7,10], and in this study was carried out on a separate GPU tile. Of an entire node comprised of 8 GPU tiles, 7 tiles were used for particle-particle interaction and 1 for PME calculation. The test cases shown in the current study are explicit solvent water solutions of 15% ethanol, with system sizes ranging from 2.5 × 105 to 1.1 × 107 atoms, increasing by roughly a factor of two at each step. Figure 1(a) shows atom-steps per second and per Joule as a function of system size. Each configuration was run 8 times; error bars in the figures represent one standard deviation. The GPU sustains ∼ 4 × 108 atom-steps/s across all tested system sizes, approximately ∼4× above the SPR CPU-only trajectory. The energy-efficiency picture is more nuanced: the GPU plateaus at ∼ 2 × 105 atomsteps/J for large systems, while the CPU efficiency decreases with system size (dropping from ∼ 2 × 105 at small sizes to ∼ 8 × 104 at 1.1 × 107 atoms), likely due to cache-pressure effects. The shape of the occupation curves is similar across
Title Suppressed Due to Excessive Length
5
throughput and energy, but with a clear shift: while the GPU raw throughput remains always higher, energy favors the CPU alone for smaller configurations. 4.2
lammps – Molecular Dynamics
lammps [19] is a classical molecular dynamics code with broad hardware support via its Kokkos package, here used with the SYCL backend to target the PVC cards. The test case is a three-dimensional Lennard-Jones (LJ) fluid; system sizes range from 3.2 × 104 to 3.5 × 106 atoms, again with the compute device size fixed at one node. Figure 1(b) shows that both GPU throughput and energy efficiency increase steeply up to ∼ 4 × 105 atoms and then plateau, reaching ∼ 5 × 108 atom-steps/s and ∼ 4 × 105 atom-steps/J respectively. The CPU throughput is nearly flat across all system sizes at ∼ 4 × 107 atom-steps/s, while its energy efficiency remains at ∼ 4 × 104 atom-steps/J, about ∼10× below the GPU at large sizes. Notably, at the smallest system size the CPU and GPU energy efficiencies are comparable, with the GPU becoming dominant only once sufficient parallelism is exposed. Here both energy and throughput convey rather similar information (save a slight GPU decrease versus a slight CPU increase at large sizes), hinting that lammps may have no hidden energy-consumption bottlenecks, making it one of the most efficient of the presented benchmarks. 4.3
OpenGadget3 – Large-Scale Cosmological Simulations
OpenGadget3 [16] is a large-scale cosmological hydrodynamics and N-body dynamics simulation code. It is highly parallel, utilizing MPI, OpenMP threads and either OpenACC or Intel OpenMP offload for computations on a GPU, making it portable to virtually all hardware systems today. In our test OpenGadget3 offloads the following kernels for computation on the GPU: gravitational tree, smoothing lengths (HSML), conduction, hydrodynamics, and density; while the rest are processed on the CPU. Communications between the CPU and GPU are kept at minimum, where only the updated values that are needed are transported. Making use of the hierarchical timer structure [13], we have collected energy information from the whole simulations as well as some of OpenGadget3’s kernels – gravitational tree, hydrodynamical acceleration, calculating smoothing length and calculating density. For our setup we run on one node, with 8 MPI tasks and 8 GPU tiles (2 tiles per GPU on the node) and 28 CPU threads per task, thus using all CPU cores and all GPUs. Figure 1(c) shows the throughput and energy efficiency for different resolution simulations. Both increase for all kernels with increasing resolution, as expected for OpenGadget3 [11]. In a further study we plan to increase the resolution to fill the node to maximum available memory and observe how that affects the performance. 4.4
AthenaK – Binary Black-Hole Merger
AthenaK [17] is a performance-portable astrophysical MHD code built on the Kokkos abstraction layer, here compiled with the SYCL backend to target the
6
S. Cielo et al.
(a) gromacs
(b) lammps (LJ fluid)
(c) OpenGadget3
(d) dealii-X matrix-free kernels
(e) AthenaK (GW150914 BBH merger) (f) p3em-EAR comparison (AthenaK data)
Fig. 1: Panels (a–e) show single-node performance (black, left axes) and energy efficiency (red, right axes) for the five benchmarks on SuperMUC-NG phase 2 (SPR CPU-only vs. SPR + PVC, where applicable). Solid circles / filled bars: PVC GPU; dashed triangles: SPR CPU only (where applicable). Panel (c) also includes the measured values for several kernels. Panel (f) compares AthenaK GPU energy efficiency across three measurement strategies (see Sect. 5.2).
Title Suppressed Due to Excessive Length
7
PVC cards. The test case is the GW150914 binary black-hole merger problem [1]; the key tuning parameter is the mesh-block edge length, which controls the granularity of work dispatched to each GPU tile. Figure 1(e) shows zone-cycles per second and per joule as a function of mesh-block size. The GPU configuration achieves peak throughput of ∼ 6 × 106 zone-cycles/s at mesh-block edge lengths ≥ 24, roughly ∼12× higher than the SPR CPU-only peak. From an energy-efficiency perspective the GPU reaches ∼ 3 × 104 zone-cycles/J at large block sizes, versus ∼ 2 × 103 zone-cycles/J for the CPU, a ∼15× advantage. Notably, at very small mesh-block edge lengths (≤ 10) the GPU throughput advantage narrows significantly, suggesting that launch overhead and occupancy effects dominate at coarse granularity. 4.5
dealii-X Kernels – Finite-Element Solvers
Scientific codes based on finite-element methods are a major consumer of compute cycles in the HPC environment. Notable applications used in production on the SuperMUC-NG phase 2 system at LRZ include SeisSol for earthquake simulations [20], the HyTeG operator framework used in large-scale mantle convection [4], or the ExaDG solver for incompressible fluid mechanics and acoustics [3]. An underlying theme of these solvers is the matrix-free evaluation of the multi-dimensional spatial PDE operators using either discontinuous or continuous Galerkin approaches. The use of tensor-product polynomial basis functions of high order, combined with with algebraic sum-factorization techniques provides these methods with a high arithmetic intensity well-suited for modern compute-heavy CPU and GPU architectures. As part of an ongoing collaboration in the dealii-X Center of Excellence we investigated the performance and energy usage of matrix-free kernels on the Intel PVC GPU using different offloading frameworks including Kokkos and OpenMP 5 . We also investigate the performance attainable using the Tiny Tensor Compiler 6 , a tensor language compiler from Intel. The Bake-off Kernel 1 (BK1) is a synthetic test from the CEED Bake-off Problems 7 . It corresponds to the action of the mass matrix, Bu = f , where B is the mass matrix for a discretized scalar PDE in 3-d. Specifically, we focus on the case with p = 2 (quadratic polynomials), (p + 1)3 nodal degrees of freedom per element and q = p + 2 quadrature points per spatial direction (64 quadrature points total). The setup consists of 100 billion elements per GPU stack, with the degrees of freedom (DoFs) stored in the E-vector format (element-local DoFs). The evaluation of the mass matrix action involves input and output vectors and the metric tensor, in FP32 precision, giving a total memory consumption of 108 · (2 · 33 + 43 )/10243 ≈ 44 GB. To saturate the node, 8 parallel instances of the benchmark are launched simultaneously via mpirun. This ensures a fair one-to-one pinning of processes to GPUs. Energy consumption https://github.com/dealii-X/benchmarks https://intel.github.io/tiny-tensor-compiler/ 7 https://ceed.exascaleproject.org/bps/ 5 6
8
S. Cielo et al.
was captured using the p3em energy-meter API, configured to sample at 100 Hz. The reported performance and energy consumption were recorded as an average of 100 repeated kernel invocations, to guarantee sufficient elapsed time of the benchmark. Originally, the benchmark programs were configured to measure the fastest single kernel invocation (i.e. minimum time), which resulted in high uncertainty when translated to the energy measurement. The baseline version is implemented in Kokkos; four variants named 1D, 1DS, 2D, and 2DS, correspond to different thread-mapping strategies (see [18] for a discussion). The OpenMP variant is derived from the serial kernel and uses the descriptive construct, #pragma omp target teams loop on the outer loop across elements, giving the compiler the freedom of automatic thread mapping and parallelization. Finally, the TinyTC approach used manual cross-element vectorization to maximize SIMD efficiency. Figure 1(d) compares the performance and energy efficiency of the different implementations. The OpenMP and TinyTC variants exhibit higher performance and better energy usage. A similar pattern of the two metrics is observed across different variants, hinting that the instant power draw remained roughly constant, thus energy mainly correlates with total runtime.
5
Discussion
5.1
Complementarity of throughput and energy efficency
Across the codes evaluated, the Intel Data Center GPU Max 1550 consistently outperforms the Intel Xeon Platinum 8480+ CPU in raw throughput, with gains ranging from ∼4× (gromacs) to ∼12× (AthenaK) depending on the application. Energy efficiency is more application-dependent: AthenaK achieves the largest GPU energy advantage (∼15× at large mesh-block sizes), followed by lammps (∼10×), while gromacs shows a more modest gain that disappears entirely at small system sizes, where the CPU alone is equally or more energy-efficient. OpenGadget3 shows the smallest energy efficiency, which could increase with simulation size and will be the subject of further study. Looking at the energy efficiency of isolated kernels (Fig. 1(c)), we see that, for example, the HSML calculation reaches higher values of ∼ 6 × 103 , about 10 times greater than the average for the whole simulation. A key observation is the sensitivity of both throughput and energy efficiency to device occupancy, as clearly visible in the AthenaK results (Fig. 1(e)): insufficient work per GPU kernel invocation leads to underutilization of PVC’s massive vector width. Practitioners porting codes to PVC-equipped systems should therefore ensure that tile-local problem sizes are large enough to saturate the GPU before expecting full throughput and energy benefits. Where throughput and energy efficiency track each other closely – as in lammps across its scaling range, or across the dealii-X kernel variants – instantaneous power is roughly constant and energy reduces to a runtime proxy. In Figure 2 we plot the power-budget parameter (defined as the ratio of throughput T and energy efficiency E, after normalizing the latter by the thermal
Title Suppressed Due to Excessive Length
9
Fig. 2: Power-budget parameter: T /(WT DP E) as a function of normalized degrees of freedom, for all runs except dealii-X (for which no workload size study was conducted). GPU runs are stable or converge around unity, indicating an efficient usage of power budget. CPU runs stabilize, but on values different from unity, indicating a systematic loss of power outside application computation.
design power WT DP ) as a function of the normalized degrees of freedom (which track workload size) for the above runs (except for dealii-X where no workload size study was conducted). A power budget of value unity means that E and T convey essentially the same information, and WT DP is an appropriate model of power consumption. As we see, this is the case for two of the most efficient codes: gromacs and AthenaK, when running on GPU. The other codes seem to converge or approach unit value at large DoF, suggesting that larger workload converge to optimal power budget utilization. At smaller value, the energy efficiency at the denominator is lower, suggesting that the GPU baseline power consumption is not fully amortized for smaller workloads. For the CPU-only runs, despite having used the reduced WT DP = 700W for the two combined SPR sockets alone, the power budget is systematically lower than unity. In reality, the lines do not diverge much from a stable value; meaning that for large workload sizes (but the CPUs are more easily filled even for lower DoF) T and E also track each other to some extent. The deviation from unity
10
S. Cielo et al.
seem to derive from a systematic fraction of the CPU power being spent on other tasks than the application computation; in other words, the WT DP is an unrealistically optimistic consumption model for CPUs. As noted previously, the code ability to use the device EUs efficiently matters: the energy consumption is dominated by compute-intense kernels, whereas wallclock is dominated by memory- or communication-bound kernels that contribute less to the energy total than their runtime share would suggest. As a result, two runs with similar throughput can show markedly different aggregate energy efficiency if their internal kernel mixes differ, and the same simulation can shift in efficiency across problem sizes purely because the relative time fractions of its kernels change. The OpenGadget3 breakdown (Fig. 1(c)) illustrates this directly: despite kernels such as HSML showing very high energy efficiency, the whole simulation has a lower overall power budget utilisation, indicating that the aggregate is dragged down by other kernels with substantially lower per-Joule efficiency that dominate the runtime. Together, these effects suggest that energy efficiency is a more sensitive probe of intra-node bottlenecks than throughput alone, and that codes with similar throughput scaling can have substantially different optimization headroom in the energy dimension. 5.2
EAR vs p3em Comparison
Figure 1(f) shows the AthenaK GPU energy efficiency measured with three configurations: (i) p3em (perf + xpu-smi), (ii) EAR with CPU package + GPU power, (iii) EAR with full node power. All three curves follow the same trend with mesh-block size, confirming consistency between tools. However, p3em systematically reports higher efficiency than both EAR variants, with the gap most pronounced at small block sizes. We attribute this offset to initialization and finalization energy captured by EAR’s job-level accounting but absent from p3em’s tighter measurement window, which brackets only the compute phase or any desired region of interest with low time latency (≲ 10 ms). The Node_POWER curve sits below PCK_POWER+GPU_POWER, as expected: integrating all node components (memory, interconnect, auxiliary boards) increases the denominator without contributing to useful computation. These findings motivate the use of p3em for the remaining benchmarks, where phase-accurate energy attribution is essential; a detailed account of p3em’s design and advantages is the subject of forthcoming work (Cielo et al., in prep).
6
Conclusions and Future Work
We have presented single-node performance and energy-efficiency measurements for five production-level scientific workloads on SuperMUC-NG phase 2, demonstrating both the strengths and the sensitivity of the Intel SPR+PVC platform to workload granularity. Our unified metric approach (compute-elements per second and per Joule) enables cross-domain comparison and provides actionable guidance for users migrating to PVC-equipped systems. The energy efficiency is
Title Suppressed Due to Excessive Length
11
especially significant, in that it allows for comparison between intensive performance (i.e., less dependent on the node/device size than the raw throughput) in a data-driven fashion (as opposed to more model-dependent reports such as roofline analysis). In some cases the two metrics provide similar information, as in lammps (Fig. 1(b)) and dealii-X kernels (Fig. 1(d)); in others, energy efficiency is relatively higher on the CPU (e.g. gromacs, Fig. 1(a)) or on the GPU (e.g. AthenaK, Fig. 1(e)). Future work will extend the study to multi-node configurations to assess the interplay of intra-node GPU performance with the system’s network fabric, and will include results from further benchmark applications, and comparison with a broader hardware base.
Acknowledgements Ivan Pribec acknowledges Carsten Uphoff (Intel) for his work on the optimized TinyTC kernels and his expertise in performance optimization. Special thanks also go to collaborators Eney Soydan and Martin Kronbichler (RUB) for their partnership on the dealii-X project.
References 1. Abbott, B., others, LIGO Scientific Collaboration and Virgo Collaboration: Observation of gravitational waves from a binary black hole merger. Physical Review Letters 116(6), 061102 (2016). https://doi.org/10.1103/PhysRevLett.116.061102 2. Abraham, M.J., Murtola, T., Schulz, R., Páll, S., Smith, J.C., Hess, B., Lindahl, E.: gromacs: High performance molecular simulations through multi-level parallelism from laptops to supercomputers. SoftwareX 1–2, 19–25 (2015). https://doi.org/ 10.1016/j.softx.2015.06.001 3. Arndt, D., Fehn, N., Kanschat, G., Kormann, K., Kronbichler, M., Munch, P., Wall, W.A., Witte, J.: Exadg: High-order discontinuous galerkin for the exa-scale. In: Software for exascale computing-SPPEXA 2016-2019, pp. 189–224. Springer (2020) 4. Böhm, F., Bauer, D., Kohl, N., Alappat, C.L., Thönnes, D., Mohr, M., Köstler, H., Rüde, U.: Code generation and performance engineering for matrix-free finite element methods on hybrid tetrahedral grids. SIAM Journal on Scientific Computing 47(1), B131–B159 (2025) 5. Cielo, S., Pöppl, A., Pribec, I.: SYCL for energy-efficient numerical astrophysics: the case of dpecho (2025), https://arxiv.org/abs/2508.14117 6. Corbalan, J., et al.: Ear: Energy management framework for supercomputers. International Journal of High Performance Computing Applications 37(5), 528–548 (2023). https://doi.org/10.1177/10943420231179036, https://github. com/eas4dc/EAR 7. Darden, T., York, D., Pedersen, L.: Particle mesh ewald: An n·log(n) method for ewald sums in large systems. J. Chem. Phys. 98, 10089–10092 (1995) 8. deal.II-X Centre of Excellence: deal.ii-x centre of excellence, https://www.dealii-x. eu/, formal reference if available (deliverable / paper)
12
S. Cielo et al.
9. Dobrev, P., Mathias, G.: Benchmarking of gpu performance saturation on accelerated cluster nodes via molecular dynamics software packages. In: Weiland, M., Neuwirth, S., Kruse, C., Weinzierl, T. (eds.) High Performance Computing. ISC High Performance 2024 International Workshops. pp. 115–126. Springer Nature Switzerland, Cham (2025) 10. Essmann, U., Perera, L., Berkowitz, M., Darden, T., Lee, H., Pedersen, L.: A smooth particle mesh ewald method. J. Chem. Phys. 103, 8577–8592 (1995) 11. Hammer, N., et al.: Extreme scale-out supermuc phase 2 - lessons learned (2016), https://arxiv.org/abs/1609.01507 12. Hess, B., Kutzner, C., van der Spoel, D., Lindahl, E.: GROMACS 4: Algorithms for highly efficient, load-balanced, and scalable molecular simulation. J. Chem. Theory Comput. (2008). https://doi.org/10.1021/ct700301q 13. Karademir, Geray S. ; Dolag, K.: Space-timers – a stack-based hierarchical timing system for c++ (2026), https://arxiv.org/abs/2603.01618 14. Pronk, S., Páll, S., Schulz, R., Larsson, P., Bjelkmar, P., Apostolov, R., Shirts, M.R., Smith, J.C., Kasson, P.M., van der Spoel, D., B. Hess, E.L.: Gromacs 4.5: a high-throughput and highly parallel open source molecular simulation toolkit. Bioinformatics (2013). https://doi.org/10.1093/bioinformatics/btt055 15. Páll, S., Abraham, M.J., Kutzner, C., Hess, B., Lindahl, E.: Tackling exascale software challenges in molecular dynamics simulations with gromacs. In S. Markidis and E. Laure (Eds.), Solving Software Challenges for Exascale (2015). https: //doi.org/10.1007/978-3-319-15976-8_1 16. Shukla, N., et al.: Eurohpc space coe: Redesigning scalable parallel astrophysical codes for exascale. CF ’25 Companion: Proceedings of the 22nd ACM International Conference on Computing Frontiers: Workshops and Special Sessions pp. 177–184 (2025). https://doi.org/10.1145/3706594.3728892 17. Stone, J.M., Mullen, P.D., Fielding, D., Grete, P., Guo, M., Kempski, P., Most, E.R., White, C.J., Wong, G.N.: Athenak: A performance-portable version of the athena++ adaptive mesh refinement framework. The Astrophysical Journal Supplement Series 283(1), 27 (2026). https://doi.org/10.3847/1538-4365/ae3717 18. Świrydowicz, K., Chalmers, N., Karakus, A., Warburton, T.: Acceleration of tensorproduct operations for high-order finite element methods. The International Journal of High Performance Computing Applications 33(4), 735–757 (2019) 19. Thompson, A.P., Aktulga, H.M., Berger, R., Bolintineanu, D.S., Brown, W.M., Crozier, P.S., in ’t Veld, P.J., Kohlmeyer, A., Moore, S.G., Nguyen, T.D., Shan, R., Stevens, M.J., Tranchida, J., Trott, C., Plimpton, S.J.: Lammps – a flexible simulation tool for particle-based materials modeling. Computer Physics Communications 271, 108171 (2022). https://doi.org/10.1016/j.cpc.2021.108171 20. Uphoff, C., Rettenberger, S., Bader, M., Madden, E.H., Ulrich, T., Wollherr, S., Gabriel, A.A.: Extreme scale multi-physics simulations of the tsunamigenic 2004 sumatra megathrust earthquake. In: Proceedings of the international conference for high performance computing, networking, storage and analysis. pp. 1–16 (2017)