Hi,.. Are eam/he potentials currently supported by GPU acceleration in LAMMPS, or is this functionality not yet implemented?
Thanks!
@jwachter You can see whether any pair style has an accelerated variant in the command overview pages in the documentation 6.8. Pair styles — LAMMPS documentation
(make sure you look at the “latest” version that represents the developmen branch).
As you can see, no accelerated style exists. But this would be a rather straightforward task to hand off to an AI coding agent. The LAMMPS development team has experimented with this recently and we have now a bunch of validated directives for such tasks that it should be possible to generate this with rather little effort and submit this as a draft pull request on GitHub for you to evaluate.
Axel,
Thank you for the clarification. I do not have much experience with the LAMMPS source code, but I may give an eam/he/kk implementation a try. It would certainly be a good excuse to learn more about the internals of LAMMPS.
Of course, considering how quickly both LAMMPS and AI-assisted development are evolving, there is a fair chance that somebody else will implement it before I get there!
Thanks again for the suggestion.
In my opinion, that is not a good way to learn. KOKKOS is specifically very different and special. But more importantly, it is far more educational to implement a completely new potential and starting with something simple that is pairwise additive. EAM potentials are special in multiple ways and those complications are rather something for later.
Please have a look at: 4.8.1. Writing new pair styles — LAMMPS documentation
In this specific case, I would suggest that I task the coding agent for this, because we have already the information collected to avoid common pitfalls with agentic coding and to produce code that matches our programming style preferences. The next LAMMPS feature release will have a massive amount of code ported to both KOKKOS and OPENMP that was missing and that is rather straightforward (but tedious) to do. However, we only looked at cases that we could test properly and a lot of porting attempts were deleted and requested again because the coding agents could not understand the code well enough or were “cheating”. This is where we now have the specific porting instructions from. 
However, I would need you to do a thorough testing of the resulting code. I would also request a port to GPU, KOKKOS, and OPENMP in one go.
@jwachter There is now a draft pull request: Add eam/he pair style variants for the OPENMP, KOKKOS, and GPU packages by akohlmey · Pull Request #5032 · lammps/lammps · GitHub
This turned out to be a bigger change, since there was some refactoring done (included in the PR) that should make things easier in the future and removes a lot of redundant code. You have now the choice between trying the GPU or the KOKKOS package for GPU support (or both) with pair style eam/he.
@akohlmey Axel,
Thank you for implementing the accelerated variants.
I tested the PR on a workstation with:
-
Intel i9 (24 cores)
-
192 GB RAM
-
NVIDIA RTX 4000 Ada SFF (20 GB)
The code compiled successfully and I was able to run my W-H-He irradiation simulations using pair_style eam/he/gpu.
For a preliminary performance test, I obtained:
-
4 MPI ranks: 545357 timesteps/s
-
8 MPI ranks: 610694 timesteps/s
-
16 MPI ranks: 422199 timesteps/s
So far, 8 MPI ranks appears to be the optimal configuration on my system.
I am currently performing additional tests to compare the accelerated version against the original CPU implementation and to verify that energies and trajectories remain consistent.
From a user perspective, the new GPU-enabled version appears to be working correctly and is already useful for real W-He simulation workloads.
I need to update my cuda driver for testing eam/he/kk, so I will perform the corresponding tests and report the results
Thank you again for the effort that went into this implementation.