GPUMD: GPU Molecular Dynamics with Neuroevolution Potentials
Graphics Processing Units Molecular Dynamics
At a glance
- What is it?
- GPUMD is a GPL-3.0 CUDA molecular dynamics package that trains and runs neuroevolution potentials (NEP) entirely on the GPU. It suits groups simulating heat transport and thermal properties at scale, and it assumes you already have the hardware and the CUDA toolchain.
- Who is it for?
- Adopt GPUMD if your group already owns NVIDIA GPUs with compute capability 3.5 or newer, your work centres on thermal transport, phonons, or NEP-based potentials, and you are comfortable with a plain-text input file rather than a scripting API. Do not adopt it if you need CPU-only execution, if your force fields are classical and already served by LAMMPS, or if GPL-3.0 redistribution is a problem for your product.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Cuda, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What GPUMD Is For: Thermal Transport and NEP Potentials
GPUMD stands for Graphics Processing Units Molecular Dynamics. The README describes it as a general-purpose MD package fully implemented on GPUs. The phrase fully implemented is the part that matters: this is not a CPU code with GPU offload for the neighbour list. The whole integration loop lives on the device.
The second half of the project is machine-learned potentials. GPUMD trains and runs a class called neuroevolution potentials, abbreviated NEP. The repository points to a separate nep-data GitLab repo holding published NEP potentials together with their training and testing data. So the intended workflow is a loop: generate reference data, train a NEP with the nep executable, then run large-scale simulations with the gpumd executable using that potential.
The citation table in the README maps specific papers to specific capabilities, which is unusual and useful. Heat current and virial formulas trace to Fan2015. Homogeneous non-equilibrium molecular dynamics (HNEMD) traces to Fan2019. Spectral decomposition of thermal conductivity traces to Fan2017 and Gabourie2021. The NEP generations are versioned by paper: NEP1 in Fan2021, NEP2 in Fan2022JPCM, NEP3 in Fan2022JCP, NEP4 or UNEP-v1 in Song2024. Later entries cover dispersion corrections, path-integral MD, shock methods, and charge-aware variants. If your work is thermal conductivity, phonon modal analysis, or potential training, the feature list is aimed directly at you. If your work is biomolecular force fields, nothing here suggests that is the target.
The Two Executables and the Input Model
Compilation produces two binaries, gpumd and nep, both in the src directory. That split reflects the two jobs. The nep binary handles training and testing of a NEP model. The gpumd binary runs dynamics: integration, thermostats, heat current measurement, and whatever analysis the run requests.
The README does not reproduce the input file format, so treat that as documentation territory rather than something to infer. What can be said from the material is that the package ships an examples directory and a separate GPUMD-Tutorials repository, and the README instructs you to run the executables from inside an example directory. That is the conventional layout for this class of code: a directory of plain-text control files alongside the run.
There is a Colab tutorial linked from the README that walks through constructing a NEP model and applying it to large-scale atomistic simulation of PbTe. The README states it runs entirely on Google's cloud virtual machine. That is the cheapest way to see the workflow without provisioning a GPU, and it is worth doing before you read the manual end to end.
One design consequence worth naming: because the executables are self-contained and driven by files rather than a Python session, GPUMD does not offer the interactive scripting that ASE or a LAMMPS Python wrapper provides. You get a fast kernel and you give up the ability to compose simulations in a REPL. For production runs that is fine. For exploratory work it is friction.
Getting It Running: Prerequisites and Build Commands
The prerequisites are stated plainly. You need a GPU card with compute capability no less than 3.5, and a CUDA toolkit no older than CUDA 9.0. Both Linux with GCC and Windows with MSVC are listed as supported operating systems.
The build is short. Go to the src directory and type make. When compilation finishes, the README states that two executables, gpumd and nep, will be generated in the src directory. There is no CMake step, no dependency manager, and no Python packaging described in the README. That is a deliberate simplicity, and it also means the build is a plain Makefile that you may need to edit if your CUDA installation is not where the Makefile expects it.
Running is equally direct. Go to the directory of an example in the examples directory and type either path/to/gpumd or path/to/nep. The README gives those as the literal commands.
The compute capability floor of 3.5 is worth reading carefully. It is a low bar by current standards, which suggests the code targets a wide range of deployed hardware rather than only recent data-centre cards. Whether a given feature, such as a particular NEP generation or the path-integral MD support, has a higher effective requirement is not something the README states. Check the manual at gpumd.org for the released version or gpumd.org/dev for the development version before assuming your card covers everything.
Where the Design Bites: GPU-Only, GPL-3.0, and Thin Build Docs
The most consequential limitation is in the name. GPUMD is a GPU code. There is no CPU fallback described in the README. If your cluster queue gives you CPU nodes, or your laptop has integrated graphics, this is the wrong tool and no amount of configuration will fix it.
The second constraint is licensing. The README states the software is distributed under the GNU General Public License version 3. For academic and open research that is unremarkable. For anyone embedding the code in a proprietary product or linking it into a closed workflow, GPL-3.0 is a real boundary. I am not giving legal advice; the point is that the licence is stated up front and you should treat it as a design fact, not a footnote.
The third is documentation depth at the repository level. The README is a pointer document. It tells you what GPUMD is, how to build it, and where the manual lives. It does not document input file keys, units, or the training data format. Everything operational lives in the manual and the tutorials. If you are evaluating GPUMD from the repository alone, you cannot judge the input schema from what is here, and you should not pretend otherwise.
A fourth, softer issue: the citation table is long and the feature surface is broad. Heat transport, shock, path integrals, coarse graining, charge-aware models, dispersion corrections. A code that spans this much physics carries a maintenance surface to match. The release cadence visible in the repository is rapid, with v5.7, v5.8, and v5.8.1 all appearing within roughly two weeks. That pace is good for users and demanding for anyone pinning a version for a long study.
Alternatives and the Actual Difference in Approach
The README itself names the most relevant comparison: NEP_CPU, a standalone C++ implementation of the neuroevolution potential that serves as the engine for many Python packages and provides an interface to the LAMMPS package. This is the right alternative to consider when you want NEP but cannot or will not run everything on a GPU. The difference is not a matter of polish. NEP_CPU is a CPU implementation of the potential, and it is the bridge that lets LAMMPS use NEP. GPUMD keeps the potential and the dynamics in one GPU-resident code. If your workflow is already built around LAMMPS input decks and fix commands, going through NEP_CPU plus LAMMPS is the lower-friction path, at the cost of the CPU execution model.
A second related package is listed: a GPU-native interface between GPUMD and PySAGES for enhanced-sampling molecular dynamics on machine-learning potentials. That is worth knowing about if your problem needs free-energy sampling rather than plain dynamics, because it suggests the intended way to extend GPUMD is through a companion interface rather than by rewriting the core.
Beyond the README, the obvious comparison class is any GPU-accelerated MD engine with its own machine-learned potential support. The distinguishing claim here is the pairing: a GPU-resident MD core plus a training scheme (NEP) that lives in the same repository. You are not gluing a trainer from one project to a simulator from another and hoping the potential format matches. That integration is the reason to pick GPUMD over assembling parts, and it is also the reason to be cautious: adopting GPUMD means adopting its potential format and its training pipeline together.
Maintenance, Releases, and What You Inherit
The repository shows a fast release cadence: v5.7 on 2026-08-24, v5.8 on 2026-09-02, v5.8.1 on 2026-09-04. The last push is dated 2026-09-10. A project moving this quickly gives you current physics and current bug fixes, and it also means a version pinned at the start of a long simulation campaign may be several minor versions behind by the time you write the paper.
For reproducibility, that argues for recording the exact tag you built from, and for noting that both the released manual (gpumd.org) and the development manual (gpumd.org/dev) exist as separate documents. The README explicitly distinguishes them. If you read the dev manual while running a released build, you will read about features you do not have.
The upgrade cost is not documented in the README. Whether input files remain compatible across minor versions is something you would have to check in the manual or the release notes for each tag. The material here does not say, and I will not guess. What the material does say is that the code is GPL-3.0, that it is copyrighted to Zheyong Fan from 2017, and that the citation requirements are itemised by feature. Any work using GPUMD cites Xu2025; historical work cites Fan2017. That citation table is effectively part of the maintenance cost, because a correct methods section needs the right entry for the right capability.
Who Should Build From Source and Who Should Walk Away
Build from source if you have NVIDIA hardware at or above compute capability 3.5, a CUDA toolkit at or above 9.0, and a problem in thermal transport, phonon analysis, or machine-learned potential development. The combination of a GPU-resident dynamics core and an in-repository trainer for NEP is the specific thing you cannot easily assemble elsewhere without format glue.
Walk away if you need CPU execution, if you depend on a classical empirical potential that LAMMPS already handles, or if GPL-3.0 is incompatible with how you ship software. Walk away also if you want a Python-first API for building simulations interactively. Nothing in the README suggests GPUMD is trying to be that.
Before committing a production study, do three concrete things. Confirm your card's compute capability and your CUDA version against the stated floor of 3.5 and 9.0. Run make in src and verify that both gpumd and nep appear, since the README says they should. Then run the linked Colab tutorial on the PbTe system, which the README states executes entirely on Google's cloud virtual machine, and use it to learn the input file conventions that the repository README does not document. If the tutorial workflow makes sense to you, the manual will be readable. If it does not, the gap between this README and a working simulation is larger than the build instructions suggest.
Editorial conclusion
Adopt GPUMD if your group already owns NVIDIA GPUs with compute capability 3.5 or newer, your work centres on thermal transport, phonons, or NEP-based potentials, and you are comfortable with a plain-text input file rather than a scripting API. Do not adopt it if you need CPU-only execution, if your force fields are classical and already served by LAMMPS, or if GPL-3.0 redistribution is a problem for your product. Verify first that the compute capability of your cards and your CUDA toolkit version meet the stated floor, then reproduce one tutorial example before committing a production study.
Community notes