deepmd-gnn is a DeePMD-kit plugin for various graph neural network (GNN) models, which connects DeePMD-kit and atomistic GNN packages by enabling GNN models in DeePMD-kit.
Supported packages and models include:
After installing the plugin, you can train the GNN models using DeePMD-kit, run active learning cycles for the GNN models using DP-GEN, perform simulations with the MACE model using molecular dynamic packages supported by DeePMD-kit, such as LAMMPS and AMBER. You can follow DeePMD-kit documentation to train the GNN models using its PyTorch backend, after using the specific model parameters.
If you use this software, please cite the following paper:
- Jinzhe Zeng, Timothy J. Giese, Duo Zhang, Han Wang, Darrin M. York, DeePMD-GNN: A DeePMD-kit Plugin for External Graph Neural Network Potentials, J. Chem. Inf. Model., 2025, 65, 7, 3154-3160, DOI: 10.1021/acs.jcim.4c02441.
If you are in a conda environment where DeePMD-kit is already installed from the conda-forge channel,
you can use conda to install the DeePMD-GNN plugin:
conda install deepmd-gnn -c conda-forgeFirst, clone this repository:
git clone https://gitlab.com/RutgersLBSR/deepmd-gnn
cd deepmd-gnnPython 3.9 or above is required. A C++ compiler that supports C++ 14 (for PyTorch 2.0) or C++ 17 (for PyTorch 2.1 or above) is required.
Assume you have installed DeePMD-kit (v3.0.0b2 or above) and PyTorch in an environment, then execute
# expose PyTorch CMake modules
export CMAKE_PREFIX_PATH=$(python -c "import torch;print(torch.utils.cmake_prefix_path)")
pip install .DeePMD-kit version should be v3.0.0b4 or later.
Follow DeePMD-kit documentation to install DeePMD-kit C++ interface with PyTorch backend support and other related MD packages. After that, you can build the plugin
# Assume libtorch has been contained in CMAKE_PREFIX_PATH
mkdir -p build
cd build
cmake .. -D CMAKE_INSTALL_PREFIX=/prefix/to/install
cmake --build . -j8
cmake --install .libdeepmd_gnn.so will be installed into the directory you assign.
When using any DeePMD-kit C++ interface, set the following environment variable in advance:
export DP_PLUGIN_PATH=/prefix/to/install/lib/libdeepmd_gnn.soFollow Parameters section to prepare a DeePMD-kit input file.
dp --pt train input.json
dp --pt freezeA frozen model file named frozen_model.pth will be generated. You can use it in the MD packages or other interfaces.
For details, follow DeePMD-kit documentation.
GNN models use message passing neural networks,
so the neighbor list built with traditional cutoff radius will not work,
since the ghost atoms also need to build neighbor list.
By default, the model requests the neighbor list with a cutoff radius of r_max and num_interactions (MACE) / num_layers (NequIP),
and rebuilds the neighbor list for ghost atoms.
However, this approach is very inefficient.
The alternative approach for the MACE model (note: NequIP doesn't support such approach) is to use the mapping passed from LAMMPS, which does not support MPI.
One needs to set DP_GNN_USE_MAPPING when freezing the models,
DP_GNN_USE_MAPPING=1 dp --pt freezeand request the mapping when using LAMMPS (also requires DeePMD-kit v3.0.0rc0 or above).
By using the mapping, the ghost atoms will be mapped to the real atoms,
so the regular neighbor list with a cutoff radius of
atom_modify map array
In the future, we will explore utilizing the MPI to communicate the neighbor list, while this approach requires a deep hack for external packages.
To use the MACE model, set "type": "mace" in the model section of the training script.
Below is default values for the MACE model, most of which follows default values in the MACE package:
"model": {
"type": "mace",
"type_map": [
"O",
"H"
],
"r_max": 5.0,
"sel": "auto",
"num_radial_basis": 8,
"num_cutoff_basis": 5,
"max_ell": 3,
"interaction": "RealAgnosticResidualInteractionBlock",
"num_interactions": 2,
"hidden_irreps": "128x0e + 128x1o",
"pair_repulsion": false,
"distance_transform": "None",
"correlation": 3,
"gate": "silu",
"MLP_irreps": "16x0e",
"radial_type": "bessel",
"radial_MLP": [64, 64, 64],
"std": 1.0,
"precision": "float32"
}"model": {
"type": "nequip",
"type_map": [
"O",
"H"
],
"r_max": 5.0,
"sel": "auto",
"num_layers": 4,
"l_max": 2,
"num_features": 32,
"nonlinearity_type": "gate",
"parity": true,
"num_basis": 8,
"BesselBasis_trainable": true,
"PolynomialCutoff_p": 6,
"invariant_layers": 2,
"invariant_neurons": 64,
"use_sc": true,
"irreps_edge_sh": "0e + 1e",
"feature_irreps_hidden": "32x0o + 32x0e + 32x1o + 32x1e",
"chemical_embedding_irreps_out": "32x0e",
"conv_to_output_hidden_irreps_out": "16x0e",
"precision": "float32"
}In deepmd-gnn, the GNN model can be used in a DPRc way.
Type maps that starts with m (such as mH) or OW or HW will be recognized as MM types.
Two MM atoms will not build edges with each other.
Such GNN+DPRc model can be directly used in AmberTools24.
deepmd_gnn.mace_off provides a conservative bridge from selected official
MACE-OFF checkpoints into DeePMD-GNN. The goal is to recover the parts that are
really stored in the checkpoint while avoiding guesses about wrapper-only
runtime semantics.
In practice, this path intentionally does less inference than the broader DPRc/QM/MM machinery:
- it infers ordinary element
type_mapentries from checkpointatomic_numbers - it restores checkpoint-side model semantics such as
avg_num_neighborsfrom the originalScaleShiftMACEobject instead of reusing DeePMD's runtime neighbor cap - it requires an explicit
selvalue, becauseselis a DeePMD runtime neighbor-list cap and is not stored in the MACE-OFF checkpoint - it does not infer DPRc/MM labels such as
mH,mC,HW, orOW load_mace_off_model()keeps the original eager MACE checkpoint model inside the wrapper for closer native/wrapper parity, whileconvert_mace_off_to_deepmd()scripts the model only at export time- it uses
torch.load(..., weights_only=False)to recover the originalScaleShiftMACEobject, so callers should only use trusted checkpoints
Example:
deepmd-gnn mace-off convert mace_off23_small_dp.pt --model off23_small --sel 64This produces a scripted DeePMD-GNN wrapper. That serialization step is useful, but it is still a good idea to validate the final downstream workflow you care about (for example in LAMMPS or AMBER).