Bug: pppm/dplr + fix dplr hangs or crashes with multi-MPI (except ntasks=1), including inconsistent behavior with restart and read_data #5362

Thanks for the detailed report. I had a first look at the DPLR PPPM code path, and there is a suspicious mismatch for recent LAMMPS versions (LAMMPS_VERSION_NUMBER >= 20221222) in source/lmp/pppm_dplr.cpp.

After poisson(), the AD-differentiation branch currently does a reverse communication with REVERSE_RHO:

if (differentiation_flag == 1)
#if LAMMPS_VERSION_NUMBER >= 20221222
 gc->reverse_comm(Grid3d::KSPACE, this, REVERSE_RHO, 1, sizeof(FFT_SCALAR),
 gc_buf1, gc_buf2, MPI_FFT_SCALAR);

For the older GridComm path this is a forward communication with FORWARD_AD, and the IK branch for Grid3d is also a forward communication. So this looks like a typo introduced when GridComm was migrated to Grid3d. The likely fix is:

- gc->reverse_comm(Grid3d::KSPACE, this, REVERSE_RHO, 1, sizeof(FFT_SCALAR),
- gc_buf1, gc_buf2, MPI_FFT_SCALAR);
+ gc->forward_comm(Grid3d::KSPACE, this, FORWARD_AD, 1, sizeof(FFT_SCALAR),
+ gc_buf1, gc_buf2, MPI_FFT_SCALAR);

This kind of wrong collective/communication direction is consistent with multi-MPI hangs or MPI collective errors while still being invisible in ntasks=1.

Could you try the patch above on your failing input? As a temporary workaround, if it is acceptable for your calculation, you may also try switching away from the AD branch, e.g. kspace_modify diff ik, and compare results carefully.

If the case still fails after this patch, there may be a second issue around DPLR bonded pairs after read_restart/domain decomposition, so a minimal reproducer that contains both the read_data and read_restart variants would be very helpful.

Authored by OpenClaw (model: custom-chat-jinzhezeng-group/gpt-5.5)