Wrong bin number of atom when building neighbor list for compute_rdf

LAMMPS LAMMPS Mailing List Mirror
1

Dear all,

I encountered a problem with the neighborlist for computerdf. I got a following array of firstneigh[90] (The neighbor list of local atom with id 90):

{93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 107, 108,
82, 83, 84, 85, 86, 87, 89, 90, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 107, 108,
106, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 129, 134, 135, 136, 138, 139, 143, …}

Obviously, it can be found the second row shouldn’t be here. After debugging into Neighbor::half_bin_newton, which is called by build_one in to build neighborlist, I found the binhead of atom 90 was incorrect. It should be 282 but the one gotten by function coord2bin in line 380 of neigh_half_bin.cpp is 281. When the loop over all atoms in other bins in stencil is invoked and k=0, the first bin becomes 281+stencil[0] = 282, which is the bin containing the atom 90.

This problem doesn’t always happen. My input only has a fix_npt which changes the volume of simulation box. I’m curious if it is related to the setting of neigh_modify.

The following is the minimal input file. fix polarization is a post_force style fix developed by me which adds forces due to polarization to the atoms. It works with the modified LJ pair coefficient to model Dang and Chang’s polarized water model. It requires a full neighbor list by the following code:

int irequest = neighbor->request(this,instance_me);
neighbor->requests[irequest]->half = 0;
neighbor->requests[irequest]->full = 1;
neighbor->requests[irequest]->pair = 0;
neighbor->requests[irequest]->fix = 1;

Other influence of the code is to add additional force and virial to the system. Energy is added by fix_modify.

Hope someone could give me some advice in order to further debug the problem. Thanks in advance.

Input file:

2

Please provide an input script that illustrates the problem

that runs with the standard LAMMPS distro (current version),

with no additional code you have added. Is compute rdf giving

the wrong answer, or is it your interpretation of what is in

the internal data structs that you think is wrong?

I encountered a problem with the neighborlist for computerdf. I got a following array of firstneigh[90] (The >neighbor list of local atom with id 90):

{93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 107, 108,
82, 83, 84, 85, 86, 87, 89, 90, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 107, 108,

106, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 129, 134, 135, 136, 138, >139, 143, …}

Thanks,

Steve

3

Thanks, Steve.

I think it’s the problem with my code since no error will happen if it runs without my code. I guess I can only solve it by myself.

By the way, I have a question with Neighbor::build_one. In line 1596 of neighbor.cpp, binatomflag is turned off as it explains “to make sure it use the result from last re-neighbor”. But when the code runs to line 1597, for example, if we use half_bin_newton method to create the list, we need to get bin number by coord2bin function in line 380 of neigh_half_bin.cpp. Will it be possible that the current bin of an atom gotten by coord2bin is different from its bin number of last-re-neighbor if the atom moves out of the bin?

Thank you!

4

Thanks, Steve.

I finally solved my problem. It happens because the skin size 2.0A is not large enough when my code is added. After modifying to 3A, everything works. Thank you!