An interesting paper in Nature Communications proposing a new way to do Ewald summation that appears better/faster/scales better than PME. They said they had implemented it in GROMACS - I wonder if developers have been in contact with them, and what the developers thought?
“Accelerating molecular dynamics simulations using fast Ewald summation with prolates: The evaluation of long-range Coulomb interactions is a significant cost in molecular dynamics (MD), even when using Particle Mesh Ewald (PME) or Particle-Particle-Particle-Mesh (PPPM) methods, which rely on Ewald splitting and the fast Fourier transform to achieve near-linear scaling. We introduce ESP—Ewald summation with prolate spheroidal wave functions (PSWFs)—which leads to a more efficient Fourier representation and a reduction in the required grid size, global communication, and particle-grid operations, without loss of accuracy. We have integrated the ESP method into two widely-used open-source MD packages, LAMMPS and GROMACS, enabling rapid comparison and adoption. Relative to PME/PPPM baselines at error tolerances 10−3 to 10−4, ESP gives roughly a 3-fold acceleration of electrostatic interactions, and a 2.5-fold speed-up in the MD simulation when using about 103 compute cores. At high accuracy (10−5), these increase to 10-fold for the far-field electrostatics and 5-fold for MD simulation. Furthermore, we show that the accelerated codes have improved strong scaling with core count, and validate them in realistic long-time biological and material simulations. ESP thus offers a practical, drop-in path to reduce the time-to-solution and energy footprint of MD workflows.”
Thanks for bringing this up. We have cleaned up the code a bit since the earlier version.
The current branch is here:
I think this is in better shape than the GitHub version, though I am still reluctant to open such a large MR.
Most of the diff is in nbnxm: roughly 93% of the total change, or 80,135 out of about 86k changed lines. This part is almost entirely additive, at +80,086/−49. The rest contains the main algorithmic implementation: about 2.9k lines in ewald for split/spread/solve, about 1.8k lines in math for PSWF support, and smaller changes in gmxpreprocess, tables, and fileio.
The nbnxm implementation uses compile-time specialization with runtime dispatch; in particular, the polynomial order is fixed as a compile-time constant.
There is still substantial work left, including parameter selection, rigorous accuracy/speed tests, and benchmarks.
Before opening an MR, I suggest opening a gitlab issue where we can discuss implementation and plan the upstreaming. Next, it might worth scheduling a technical discussion.
On the LOC of the diff: size is not necessarily the major / the only concern and it sounds like most of the code is in new nbnxm kernel flavors. Most extra careful review is typically required by code that touches changes current standard especially common mdrun features.
Thanks for the suggestions. I’ll try to open a GitLab issue so we can continue the discussion and plan the next steps there. I also think it would be helpful to schedule some meetings to discuss this in more detail. I’d like to spend more time carefully evaluating and refining the method. I think it takes time for a new method to mature, and careful implementation and benchmarking would benefit from more suggestions, feedback, and collaboration. I’d be happy to discuss this further and work together on improving and validating the approach.