Regarding the calculation speed issue of dplr

[yuanxiang-Ji]

My system consists of 2000 water molecules. My Deep-kit version is 2.2.11, installed via an offline installer. My graphics card is an RTX 3090. My issue is that my molecular dynamics simulations using the DPLR potential function are significantly slower than those using the DPSR potential function, by approximately 15 times. I would like to ask if anyone can help resolve this issue.

[dosubot[bot]]

Hi @yuanxiang-Ji! I'm Dosu and I’m helping the deepmd-kit team.

The main reason DPLR is much slower than DPSR is the long-range electrostatic calculation handled by LAMMPS's kspace_style pppm/dplr, which is CPU-bound and not accelerated by your GPU. This step can take over half of the total simulation time, while the neural network pair potential (DPSR) benefits from GPU acceleration and runs much faster. Increasing the number of GPUs doesn't help, since only the short-range part uses the GPU; the bottleneck remains in the kspace and modify steps on the CPU source.

This is a known limitation. Maintainers have acknowledged that a GPU-accelerated or OpenMP-parallelized version of pppm/dplr could help, but these improvements are not yet available source source.

You can try to maximize CPU thread usage by tuning environment variables like OMP_NUM_THREADS, DP_INTRA_OP_PARALLELISM_THREADS, and DP_INTER_OP_PARALLELISM_THREADS to match your hardware source source. Empirical tuning may help a bit, but it won't resolve the fundamental bottleneck. If your LAMMPS build supports it, you could experiment with kspace variants like pppm/omp or pppm/intel, but these are not guaranteed to work with DPLR and need testing source.

If high performance is critical and you don't strictly need DPLR's long-range features, DPSR is the better choice for now. Otherwise, keep an eye out for future updates to DeePMD-kit and LAMMPS that may address this bottleneck.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[dosubot[bot]]

You can't run a single DeePMD-kit DPLR simulation across both a CPU-only node and a GPU node at the same time. All calculations (short-range on GPU, long-range on CPU) must happen within each MPI process, and each process expects access to both CPU and GPU resources if needed. Heterogeneous runs (splitting the workload between a CPU-only node and a GPU node) are not supported for a single simulation run—there’s no mechanism to offload the short-range part to the GPU node and the long-range part to the CPU node in one job. This is a limitation of both DeePMD-kit and LAMMPS for DPLR models source.

For best performance, run your DPLR simulation on the GPU node, using all its CPU cores and the GPU, and tune your MPI and threading variables as discussed earlier source. You can use the CPU node for other tasks (like training, post-processing, or running non-DPLR jobs) while the GPU node runs DPLR MD.

If you want to automate job submission or manage resources across both nodes, you can use tools like DPDispatcher to submit separate jobs to each node, but this does not enable a single DPLR simulation to use both nodes at once source.

Let me know if you want an optimized submission script for either node!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[yuanxiang-Ji]

bulk water

variable BETA equal 0.3
variable KMESH equal 60 #should be twice the box size in A

units metal
boundary p p p
atom_style full

neighbor 2.0 bin
neigh_modify every 10 delay 0 check no exclude type 1 5

read_data water.data

group real_atom type 1 2
group virtual_atom type 5

pair_style deepmd ./dplrcompress.pb
pair_coeff * *
bond_style zero
bond_coeff *
special_bonds lj/coul 1 1 1 angle no

kspace_style pppm/dplr 1e-5
kspace_modify gewald ${BETA} diff ik mesh ${KMESH} ${KMESH} ${KMESH}

fix 0 all dplr model ./dplrcompress.pb type_associate 1 5 bond_type 1
fix_modify 0 virial yes

compute real_temp real_atom temp
compute real_press all pressure real_temp
velocity all create 300 18234589
fix 1 all npt temp 300 300 0.05 iso 1.01325 1.01325 0.5
fix_modify 1 temp real_temp press real_press

dump 1 all custom 1000 water.dump id type x y z
dump_modify 1 append yes sort id

timestep 0.0005
thermo_style custom step vol temp pe ke etotal press
thermo_modify temp real_temp press real_press
thermo 1000
thermo_modify flush yes

run 1000
write_data out.lmp nocoeff
#############################This is my inputs###########################
My current system is an NVT ensemble bulk water. I can delete the lines "fix_modify 0 virial yes" and "compute real_press all pressure real_temp". Then, can I modify the command "fix_modify 1 temp real_temp press real_press" to "fix_modify 1 temp real_temp"?@dosu

[dosubot[bot]]

Yes, for an NVT ensemble, you can safely delete the lines fix_modify 0 virial yes and compute real_press all pressure real_temp. You should also change fix_modify 1 temp real_temp press real_press to fix_modify 1 temp real_temp. In fact, you should also change fix 1 all npt ... to fix 1 all nvt temp 300 300 0.05, since NVT does not require pressure control—only temperature control is needed. This matches the recommended setup in the DPLR documentation and example scripts for NVT simulations, where only the temperature compute is specified for the thermostat, and pressure-related computes and modifications are omitted see example.

If you reference real_press elsewhere (like in thermo_modify), remove or adjust those as well. Your NVT input should look like:

fix             1 all nvt temp 300 300 0.05
fix_modify      1 temp real_temp

This setup ensures the thermostat acts only on the real atoms, as required for DPLR models.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[yuanxiang-Ji]

Could i write tiis like "fix 1 real_atom nvt temp 300 300 0.05" ? So I can delete "fix_modify 1 temp real_temp"@dosu

[dosubot[bot]]

You should not delete fix_modify 1 temp real_temp even if you use fix 1 real_atom nvt temp 300 300 0.05. The recommended and consistently used approach for DPLR/DeePMD-kit is to apply the thermostat to the real_atom group and also specify the temperature compute with fix_modify 1 temp real_temp. This ensures the thermostat uses the temperature of only the real atoms, excluding virtual atoms (Wannier centroids). Omitting fix_modify may cause warnings or incorrect thermostatting, and all authoritative examples and discussions include it—even when using fix nvt on a group see documentation see discussion.

So, keep both:

fix             1 real_atom nvt temp 300 300 0.05
fix_modify      1 temp real_temp

This setup is required for correct and reproducible DPLR simulations.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}