DeePMD-kit: fine-tuning pretrained DPA4 potentials and running them in LAMMPS, i-PI and ASE

The gap DeePMD-kit fills between DFT output and long molecular dynamics

Density functional theory gives you energies and forces you can trust and a simulation length you cannot afford. Classical force fields run for nanoseconds and get the chemistry wrong for anything outside their fitting set. DeePMD-kit sits in that gap: it turns quantum-mechanical reference data into interatomic potentials that are cheap enough to run at simulation scale. The README describes the scope as molecular and materials science, from finite molecules and covalent systems to periodic solids and metals. That breadth is the point. A group studying a metal oxide and a group studying a small organic molecule can use the same training pipeline, the same data format and the same deployment interfaces. The intended user is someone who already has reference data, or can obtain it, and who needs forces rather than only energies. The project also targets people who have neither the data nor the patience to train from scratch: the README frames a pretrained checkpoint as a starting point rather than an end result, which is a genuine change in how the tool is meant to be entered.

Two entry points, one export path: the workflow the README draws

The README includes a flowchart with two starting points that converge. On one side, a pretrained DPA4 model is fine-tuned on target data. On the other, a model configuration is trained from scratch against the same target reference data. Both branches meet at a single stage labelled test, compress, export, and from there the model goes to Python and native APIs or into a molecular dynamics engine. That convergence is the architectural claim worth examining. It means the validation and export tooling is not specific to the fine-tuning route. A team that starts from a released checkpoint and a team that trains a new model both run dp test and dp freeze. The data side is equally explicit: reference data lives in DeePMD's NumPy format, and structures and trajectories are converted with dpdata. The model side is a portfolio rather than a single architecture. DPA4 is positioned for accuracy and DPA4C for throughput and scale, and the README shows a Pareto frontier figure for the DPA4 family across Matbench Discovery CPS and saturated inference throughput. I cannot verify that figure from the repository text alone, and the README does not publish the underlying numbers in prose, so treat the plot as a claim to check against the linked release material rather than a settled result.

Backends, precision targets and the parts of the stack you can swap

DeePMD-kit does not commit to one deep learning framework. The README lists TensorFlow, PyTorch, JAX and Paddle as supported backends for training or running supported models, with backend-aware model formats and conversion paths for compatible architectures. The qualifier matters: conversion exists where architectures are compatible, not universally. The same caution applies to what the models predict. Energy and force are the baseline, but the README also names virials, Hessians, spin and magnetic forces, dipoles, polarizabilities, electronic density of states, atomic populations, and arbitrary intensive or extensive properties. This is a wide surface, and the README's own note that backend and interface support varies by model and feature is the honest reading. If your scientific target is a Hessian or a spin-dependent force, the relevant question is not whether DeePMD-kit supports it in general but whether the specific model you plan to fine-tune exposes it on the specific backend you plan to train with. The documentation is said to mark compatibility and limitations on each feature page, which is where that check belongs.

Getting it running: the commands the README actually gives

The README states a Python 3.10 or later requirement and offers a one-line install script as the fastest path: curl -fsSL https://dp1s.deepmodeling.com | bash, followed by dp --version and dp -h to confirm the CLI is present. For fine-tuning, the documented sequence downloads a checkpoint and its matching training configuration. The example uses DPA4-Neo and runs dp pretrained download DPA4-Neo-OMat24-v20260805, then fetches the corresponding input_finetune.json from the DPA4-OMat24 release on Hugging Face with curl. The README notes that the release provides Nano, Mini, Neo, Air and Plus checkpoints together with their matching training configurations, so the JSON is not a generic template: it is paired with the checkpoint. Validation and packaging go through dp test and dp freeze, with backend conversion, embedding extraction and compression as separate steps in the same stage. Installation alternatives are covered in the installation guide: pip, conda-forge, containers, offline packages, GPU builds, LAMMPS, i-PI and source builds. Note that piping a remote script into bash is convenient and also an act of trust; the guide lists the package-manager routes for anyone who would rather not.

Where the pretrained-first pitch breaks down

Fine-tuning is not a substitute for understanding your system. A checkpoint trained on a broad inorganic dataset carries the biases of that dataset, and the README's own framing of DPA4-OMat24 as general purpose does not promise transfer to every chemistry. The failure mode is quiet: a fine-tuned model can fit your training structures well and still produce unphysical forces in a configuration your reference data never sampled, and the README gives no automatic detector for that. The compression claim needs the same care. The README states that on supported descriptors and workloads, compression can deliver more than 10x inference speedup and reduce memory usage by as much as 20x, and immediately qualifies that actual gains depend on the model, system and hardware. That is a stated range, not a guarantee, and the word supported is doing real work in that sentence. The other limitation is structural rather than scientific: the project is large. Four backends, a C and C++ API, a Node.js binding, plugins for external GNNs such as MACE and NequIP, and integrations with LAMMPS, i-PI, ASE, GROMACS, JAX MD, nvalchemi, OpenMM, Amber, CP2K and ABACUS. That breadth is useful when your engine is on the list and irrelevant when it is not. If your simulation code is not among the supported interfaces, you are writing the coupling yourself against the C or C++ API, and that is a different project from the one the quick start describes.

How it differs from training a MACE or NequIP model directly

The obvious alternative is to train a graph neural network potential directly in the framework that defines it, MACE or NequIP, and skip the intermediate layer. The difference is in what each project owns. MACE and NequIP are architectures with their own training code and their own conventions for data and checkpoints; you get the model and you build the surrounding workflow. DeePMD-kit is the surrounding workflow, with the model portfolio as one component inside it. Its value is the shared path from reference data through dpdata conversion, training or fine-tuning, dp test, dp freeze, and then loading the result into a molecular dynamics engine that already knows how to call it. That matters most when the deployment target is a legacy engine such as LAMMPS or i-PI, where a bespoke Python model is not directly usable. It matters less if you are running everything inside JAX or PyTorch and never leave Python. The README also acknowledges the boundary by offering plugins for external GNNs such as MACE and NequIP, which suggests the project would rather host those models than compete with them. If your whole workflow is already Python-native, the wrapper may be overhead rather than help.

Maintenance, versioning and what LGPL-3.0 means for distribution

The repository is active, not archived, with v3.2.0 released in August 2026, a v3.2.0b0 beta two months earlier, and v3.1.3 before that. The presence of a beta line alongside stable releases tells you the project ships features ahead of finalisation, so pinning to a stable tag rather than tracking master is the lower-risk choice for production work. The version pace also implies upgrade cost: a four-backend project changes its compatibility matrix between releases, and a model format that works on one backend may need conversion after an upgrade. That is the maintenance budget you should plan for, and the README's warning about backend-aware formats is the reason. On licensing, the project is LGPL-3.0-or-later, stated in the README badge and the LICENSE file. The practical consequence is that if you distribute a modified version of the library itself, the copyleft terms attach to that modified library. Using the library as a dependency, or shipping trained model files and inputs, is a different question from modifying and redistributing the code. I am not a lawyer and this is not legal advice; if you are embedding DeePMD-kit in a distributed product, get the licence reviewed rather than inferring the answer from the badge.

Editorial conclusion

Adopt DeePMD-kit if you need a machine-learning potential that can be fine-tuned from a released DPA4 checkpoint and then loaded into LAMMPS, i-PI, ASE or a Python loop without rewriting your simulation stack. Do not adopt it if your target property falls outside the documented model portfolio, or if you cannot tolerate an LGPL-3.0-or-later dependency in a distributed product. Before committing, verify three things against the documentation for your exact model and backend: which pretrained checkpoint matches your chemistry, whether the compression and export path you intend to use is listed as supported for that architecture, and whether the backend you want (TensorFlow, PyTorch, JAX or Paddle) is marked compatible with the features you need. The README itself warns that backend and interface support varies by model and feature, so that matrix, not the headline feature list, is the real decision surface.

Official sources

1. deepmodeling/deepmd-kit on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases