Skip to content

Commit b21e596

Browse files
authored
Merge branch 'brucefan1983:master' into mini
2 parents 0da9f83 + afc0f1a commit b21e596

135 files changed

Lines changed: 73280 additions & 38027 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ src/gnep*
1111

1212
.history
1313
.vscode
14+
.DS_Store
1415
*~
1516
local
1617
public

README.md

Lines changed: 13 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -70,13 +70,15 @@ There is a standalone C++ implementation of the neuroevolution potential (NEP) i
7070
| [Fan2024] | linear-scaling quantum transport |
7171
| [Song2024] | NEP4 or UNEP-v1 (General-purpose machine-learned potential for 16 elemental metals and their alloys)|
7272
| [Xu2024] | TNEP (tensorial NEP models of dipole and polarizability) |
73-
| [Song2025] | MCMD (hybrid Monte Carlo and molecular dynamics simulations) |
73+
| [Song2026] | MCMD (hybrid Monte Carlo and molecular dynamics simulations) |
7474
| [Ying2025] | PIMD/TRPMD (path-integral molecular dynamics/thermostatted ring-polymer molecular dynamics) |
7575
| [Pan2024] | NEMD and NPHug shock methods |
7676
| [Jiang2025] | SW + ILP (hybrid Stillinger-Weber potential with anisotropic interlayer potential) |
77-
| [Bu2025] | NEP + ILP (hybrid NEP with anisotropic interlayer potential) |
7877
| [Liang2025] | NEP89 (Universal neuroevolution potential for inorganic and organic materials across 89 elements) |
7978
| [Huang2026] | GNEP: An alternative training scheme for NEP models |
79+
| [Fan2026a] | qNEP: NEP with dynamic charge (q) |
80+
| [Fan2026b] | NEP-CG and NEP-AACG: NEP with coarse graining |
81+
| [Bu2026] | NEP + ILP (hybrid NEP with anisotropic interlayer potential) |
8082

8183
## References
8284

@@ -127,8 +129,8 @@ Nature Communications **15**, 10208 (2024).
127129
[Tensorial properties via the neuroevolution potential framework: Fast simulation of infrared and Raman spectra](https://doi.org/10.1021/acs.jctc.3c01343),
128130
J. Chem. Theory Comput. **20**, 3273 (2024).
129131

130-
[Song2025] Keke Song, Jiahui Liu, Shunda Chen, Zheyong Fan, Yanjing Su, Ping Qian, [Solute segregation in polycrystalline aluminum from hybrid Monte Carlo and molecular dynamics simulations with a unified neuroevolution potential](https://arxiv.org/abs/2404.13694),
131-
arXiv:2404.13694 [cond-mat.mtrl-sci]
132+
[Song2026] Keke Song, Jiahui Liu, Yuanxu Zhu, Shunda Chen, Zheyong Fan, Yanjing Su, Ping Qian, [Solute Segregation in Polycrystalline Aluminum From Hybrid Monte Carlo and Molecular Dynamics Simulations With a Unified Neuroevolution Potential](https://onlinelibrary.wiley.com/doi/10.1002/mgea.70049),
133+
Materials Genome Engineering Advances, e70049 (2026).
132134

133135
[Ying2025] Penghua Ying, Wenjiang Zhou, Lucas Svensson, Esmée Berger, Erik Fransson, Fredrik Eriksson, Ke Xu, Ting Liang, Jianbin Xu, Bai Song, Shunda Chen, Paul Erhart, Zheyong Fan, [Highly efficient path-integral molecular dynamics simulations with GPUMD using neuroevolution potentials: Case studies on thermal properties of materials](https://doi.org/10.1063/5.0241006),
134136
J. Chem. Phys. **162**, 064109 (2025).
@@ -139,10 +141,13 @@ Phys. Rev. B **110**, 224101 (2024).
139141
[Jiang2025] Wenwu Jiang, Ting Liang, Hekai Bu, Jianbin Xu, and Wengen Ouyang, [Moiré-driven interfacial thermal transport in twisted transition metal dichalcogenides](https://doi.org/10.1021/acsnano.4c12148),
140142
ACS Nano **19**, 16287 (2025).
141143

142-
[Bu2025] Hekai Bu, Wenwu Jiang, Penghua Ying, Ting Liang, Zheyong Fan, and Wengen Ouyang, [Accurate modeling of LEGO-like vdW heterostructures: Integrating machine learned with anisotropic interlayer potentials](https://arxiv.org/abs/2504.12985),
143-
arXiv:2504.12985 [physics.comp-ph].
144-
145144
[Liang2025] Ting Liang, Ke Xu, Eric Lindgren, Zherui Chen, Rui Zhao, Jiahui Liu, Esmée Berger, Benrui Tang, Bohan Zhang, Yanzhou Wang, Keke Song, Penghua Ying, Nan Xu, Haikuan Dong, Shunda Chen, Paul Erhart, Zheyong Fan, Tapio Ala-Nissila, Jianbin Xu, [NEP89: Universal neuroevolution potential for inorganic and organic materials across 89 elements](https://arxiv.org/abs/2504.21286), arXiv:2504.21286 [cond-mat.mtrl-sci].
146145

147146
[Huang2026] Hongfu Huang, Junhao Peng, Kaiqi Li, Jian Zhou, Zhimei Sun, [Efficient GPU-accelerated training of a neuroevolution potential with analytical gradients](https://doi.org/10.1016/j.cpc.2025.109994),
148-
Computer Physics Communications **320**, 109994 (2026).
147+
Computer Physics Communications **320**, 109994 (2026).
148+
149+
[Fan2026a] Zheyong Fan, Benrui Tang, Esmée Berger, Ethan Berger, Erik Fransson, Ke Xu, Zihan Yan, Zhoulin Liu, Zichen Song, Haikuan Dong, Shunda Chen, Lei Li, Ziliang Wang, Yizhou Zhu, Julia Wiktor, Paul Erhart [qNEP: A highly efficient neuroevolution potential with dynamic charges for large-scale atomistic simulations](https://arxiv.org/abs/2601.19034), arXiv:2601.19034 [physics.comp-ph].
150+
151+
[Fan2026b] Zheyong Fan, Wenjun Zhang, Zhenhao Zhang, Ke Xu, Xuecheng Shao, Haikuan Dong, [NEP-CG and NEP-AACG: Efficient coarse-grained and multiscale all-atom-coarse-grained neuroevolution potentials](https://arxiv.org/abs/2603.01234), arXiv:2603.01234 [physics.comp-ph] (2026).
152+
153+
[Bu2026] Hekai Bu, Wenwu Jiang, Penghua Ying, Ting Liang, Zheyong Fan, and Wengen Ouyang, [Modular hybrid machine learning and physics-based potentials for scalable modeling of Van der Waals heterostructures](https://doi.org/10.1016/j.jmps.2026.106540), J. Mech. Phys. Solids **210**, 106540 (2026).

doc/GPUMD-Manual.pdf

9.6 KB
Binary file not shown.

doc/bibliography.rst

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -352,8 +352,14 @@ Bibliography
352352
| The Journal of chemical physics, 138(4), (2013).
353353
| DOI: `10.1063/1.4774084 <https://doi.org/10.1063/1.4774084>`_
354354
355-
.. [Bu2025]
355+
.. [Jiang2025]
356+
| Wenwu Jiang, Ting Liang, Hekai Bu, Jianbin Xu, and Wengen Ouyang
357+
| *Moiré-driven interfacial thermal transport in twisted transition metal dichalcogenides*
358+
| ACS Nano **19**, 16287 (2025)
359+
| DOI: `10.1021/acsnano.4c12148 <https://doi.org/10.1021/acsnano.4c12148>`_
360+
361+
.. [Bu2026]
356362
| Hekai Bu, Wenwu Jiang, Penghua Ying, Ting Liang, Zheyong Fan, and Wengen Ouyang
357-
| *Accurate modeling of LEGO-like vdW heterostructures: integrating machine learned with anisotropic interlayer potentials*
358-
| arXiv, 2504, 12985 (2025)
359-
| DOI: `10.48550/arXiv.2504.12985 <https://doi.org/10.48550/arXiv.2504.12985>`_
363+
| *Modular hybrid machine learning and physics-based potentials for scalable modeling of Van der Waals heterostructures*
364+
| J. Mech. Phys. Solids **210**, 106540 (2026)
365+
| DOI: `10.1016/j.jmps.2026.106540 <https://doi.org/10.1016/j.jmps.2026.106540>`_

doc/gpumd-mdi/README.md

Lines changed: 150 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,150 @@
1+
# GPUMD MDI Interface
2+
3+
MDI (MolSSI Driver Interface) integration for GPUMD, allowing GPUMD to be used as an MD engine interfaced with other codes like VASP.
4+
5+
---
6+
7+
## 1. Prerequisites
8+
9+
- **MDI library**
10+
- Install the MDI library following the official instructions:
11+
[MDI installation guide](https://molssi-mdi.github.io/MDI_Library/user_guide/installation.html).
12+
- Note the installation prefix, in particular:
13+
- `MDI_INC_PATH`: directory that contains `mdi.h`
14+
(for example, `/path/to/MDI_Library/install/include`)
15+
- `MDI_LIB_PATH`: directory that contains the MDI library
16+
(for example, `/path/to/MDI_Library/install/lib64`)
17+
18+
- **VASP**
19+
- A working VASP executable (for example, `vasp_std` or `mpirun -n N vasp_std`) available in your `PATH` or referenced via a full path.
20+
21+
- **Python**
22+
- Python 3
23+
- Python MDI interface:
24+
25+
```bash
26+
pip install mdi
27+
```
28+
29+
- `numpy`
30+
31+
---
32+
33+
## 2. Compiling `GPUMD` with MDI support
34+
35+
From the `src` directory:
36+
37+
```bash
38+
cd src
39+
make -f makefile_mdi USE_MDI=1 MDI_LIB=1 \
40+
MDI_LIB_PATH=/path/to/MDI_Library/install/lib64 \
41+
MDI_INC_PATH=/path/to/MDI_Library/install/include
42+
```
43+
44+
Adjust `MDI_LIB_PATH` and `MDI_INC_PATH` to match your local MDI installation.
45+
This will build a `gpumd-mdi` executable that is linked against MDI and can run in ENGINE mode.
46+
47+
---
48+
49+
## 3. MDI Commands Supported
50+
51+
GPUMD as an MDI ENGINE supports the following commands:
52+
53+
- `<NATOMS`: Returns the number of atoms
54+
- `>COORDS`: Receives atomic coordinates from driver
55+
- `<COORDS`: Sends atomic coordinates to driver
56+
- `<FORCES`: Computes and sends forces to driver
57+
- `>FORCES`: Receives forces from driver (for QM/MM coupling)
58+
- `<ENERGY`: Computes and sends potential energy to driver
59+
- `>ENERGY`: Receives energy from driver
60+
- `>STRESS`: Receives stress tensor from driver
61+
- `EXIT`: Exit the MDI communication loop
62+
63+
---
64+
65+
## 4. Files and layout for the VASP–GPUMD example
66+
67+
MDI-related helper scripts are collected under:
68+
69+
- `tools/gpumd-mdi/run_mdi_vasp_gpumd.sh` where:
70+
- `GPUMD` runs as MDI ENGINE (MD integrator)
71+
- `vasp_mdi_driver.py` runs as DRIVER (QM calculator)
72+
73+
- `tools/gpumd-mdi/vasp_mdi_driver.py`
74+
Python MDI DRIVER that:
75+
- connects to the `GPUMD` ENGINE over MDI,
76+
- launches VASP for QM calculations,
77+
- reads forces (and energy) from `vasprun.xml`,
78+
- sends QM forces and energy back to `GPUMD`.
79+
80+
An example input system is provided in:
81+
82+
- `examples/gpumd_mdi/` (Cu dimer), containing
83+
- `INCAR_template`, `POSCAR_template`, `POTCAR`, `run.in`, `model.xyz`
84+
85+
---
86+
87+
## 5. Running the minimal VASP–GPUMD MDI example
88+
89+
Assuming:
90+
- `GPUMD` has been compiled with MDI support as described above, and
91+
- you have a working VASP executable (e.g. `vasp_std`),
92+
93+
you can run the minimal example as follows (from the repository root):
94+
95+
```bash
96+
cd examples/gpumd_mdi
97+
98+
bash ../../tools/mdi/run_mdi_vasp_gpumd.sh \
99+
--gpumd-bin ../../src/gpumd-mdi \
100+
--run-in run.in \
101+
--vasp-cmd "vasp_std" \
102+
--poscar POSCAR \
103+
--steps 3
104+
--no-cleanup
105+
```
106+
107+
Key options:
108+
109+
- `--gpumd-bin`
110+
Path to the `gpumd-mdi` binary.
111+
112+
- `--run-in`
113+
GPUMD input file (default: `run.in`).
114+
115+
- `--vasp-cmd`
116+
Command used to run VASP (`vasp_std`, `mpirun -n 8 vasp_std`, etc.).
117+
118+
- `--poscar`
119+
POSCAR template file (default: `POSCAR_template`).
120+
121+
- `--steps`
122+
Number of MD steps controlled by the DRIVER.
123+
124+
- `--no-cleanup`
125+
Keep all the log directories and files
126+
127+
The script:
128+
129+
1. Starts `GPUMD` as MDI ENGINE in the background.
130+
2. Starts the Python VASP DRIVER (`vasp_mdi_driver.py`) as MDI DRIVER.
131+
3. Runs VASP at each MD step to compute QM energies and forces.
132+
4. Sends QM forces and energy back to `GPUMD` via MDI.
133+
5. Lets `GPUMD` perform the MD time integration.
134+
135+
Standard `GPUMD` dump and compute keywords in `run.in` (for example, `dump_force`, `dump_thermo`, etc.) work as usual, so forces and thermodynamic quantities can be written to the standard output files while using QM forces from VASP.
136+
137+
---
138+
139+
## 6. Extending to other DRIVER codes
140+
141+
The current example focuses on `VASP` as the QM DRIVER.
142+
In principle, any external code that implements the MDI protocol can be used as a DRIVER:
143+
144+
- Replace `vasp_mdi_driver.py` with a DRIVER that:
145+
- connects to `GPUMD` over MDI,
146+
- requests coordinates from `GPUMD`,
147+
- computes energies and forces,
148+
- sends them back via the appropriate MDI commands.
149+
150+
The MDI-specific logic inside `GPUMD` is generic and not tied to VASP.

doc/gpumd/input_parameters/compute_cohesive.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,22 +14,22 @@ Syntax
1414

1515
This keyword is used as follows::
1616

17-
compute_cohesive <e1> <e2> <num_points>
17+
compute_cohesive <e1> <e2> <direction>
1818

1919
Here,
2020
:attr:`e1` is the smaller box-scaling factor,
2121
:attr:`e2` is the larger box-scaling factor, and
22-
:attr:`num_points` is the number of points sampled uniformly from :attr:`e1` to :attr:`e2`.
22+
:attr:`direction` specifies the direction of the scaling, which can take values from 0 to 6, corresponding to the x, y, z, xy, yz, zx, and xyz directions, respectively.
2323

2424

2525
Examples
2626
--------
2727

2828
The command::
2929

30-
compute_cohesive 0.9 1.2 301
30+
compute_cohesive 0.9 1.2 0
3131

32-
means that one wants to compute the cohesive energy curve from the box-scaling factor 0.9 to the box-scaling factor 1.2, with 301 points.
32+
means that one wants to compute the cohesive energy curve in the x-direction from the box-scaling factor 0.9 to the box-scaling factor 1.2, with ``(e2 - e1)*1000 +1`` points.
3333
The box-scaling points will be 0.9, 0.901, 0.902, ..., 1.2.
3434

3535

doc/gpumd/input_parameters/compute_elastic.rst

Lines changed: 3 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -13,20 +13,18 @@ Syntax
1313

1414
This keyword is used as follows::
1515

16-
compute_elastic <strain_value> <symmetry_type>
16+
compute_elastic <strain_value>
1717

1818
:attr:`strain_value` is the amount of strain to be applied in the calculations.
1919

20-
:attr:`symmetry_type` is the symmetry type of the material considered.
21-
Currently, it can only be :attr:`cubic`.
2220

2321
Example
2422
-------
2523
For example, the command::
2624

27-
compute_elastic 0.01 cubic
25+
compute_elastic 0.01
2826

29-
means that one wants to compute the elastic constants for a cubic system with a strain of 0.01.
27+
means that one wants to compute the elastic constants with a strain of 0.01.
3028

3129
Caveats
3230
-------

doc/gpumd/input_parameters/compute_rdf.rst

Lines changed: 3 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -33,18 +33,13 @@ Syntax
3333

3434
This keyword is used as follows::
3535

36-
compute_rdf <cutoff> <num_bins> <interval> [atom <i1> <i2> atom <i3> <i4> ...]
36+
compute_rdf <cutoff> <num_bins> <interval>
3737

3838
This means that the :term:`RDF` calculations will be performed every :attr:`interval` steps, with :attr:`num_bins` data points evenly distributed from 0 to :attr:`cutoff` (in units of Ångstrom) in terms of the distance between atom pairs.
3939

40-
Without the optional parameters, only the total :term:`RDF` will be calculated.
41-
42-
To additionally calculate the partial :term:`RDF` for a pair of species, one can specify the types of the two species after the word "atom".
43-
The types 0, 1, 2, ... correspond to the species in the potential file in order.
44-
Currently, one can specify at most 6 pairs.
40+
Starting from GPUMD-v4.9, there is no need to specify the atom pairs and the code will calculate the partial :term:`RDF`\s for all atom pairs.
4541

4642
Example
4743
-------
4844

49-
compute_rdf 8.0 400 1000 # total RDF every 1000 MD steps with 400 data up to 8 Angstrom
50-
compute_rdf 8.0 400 1000 atom 0 0 atom 1 1 atom 0 1 # additionally calculate 3 partial RDFs
45+
compute_rdf 8.0 400 1000 # Calculate all RDFs every 1000 MD steps with 400 data up to 8 Angstrom

doc/nep/input_parameters/cutoff.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ One syntax is::
1111
cutoff <radial_cutoff> <angular_cutoff>
1212

1313
where :attr:`<radial_cutoff>` and :attr:`<angular_cutoff>` correspond to :math:`r_\mathrm{c}^\mathrm{R}` and :math:`r_\mathrm{c}^\mathrm{A}`, respectively.
14-
The cutoffs must satisfy the conditions 2.5 Å :math:`\leq r_\mathrm{c}^\mathrm{A} \leq r_\mathrm{c}^\mathrm{R} \leq` 10 Å.
14+
The cutoffs must satisfy the conditions 3 Å :math:`\leq r_\mathrm{c}^\mathrm{A} \leq r_\mathrm{c}^\mathrm{R} \leq` 10 Å.
1515

1616
The defaults are :math:`r_\mathrm{c}^\mathrm{R}` = 8 Å and :math:`r_\mathrm{c}^\mathrm{A}` = 4 Å.
1717
It can be computationally beneficial to use (possibly much) smaller :math:`r_\mathrm{c}^\mathrm{R}` but the default values should be reasonable in most cases.

doc/nep/input_parameters/lambda_q.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,6 @@ The syntax is::
1010

1111
lambda_q <weight>
1212

13-
Here, :attr:`<weight>` represents :math:`\lambda_q`, which must satisfy :math:`\lambda_q \geq 0` and defaults to :math:`\lambda_q = 0.5`.
13+
Here, :attr:`<weight>` represents :math:`\lambda_q`, which must satisfy :math:`\lambda_q \geq 0` and defaults to :math:`\lambda_q = 0.1`.
1414

1515
This keyword is only relevant for the qNEP models.

0 commit comments

Comments
 (0)