Wrong bin number of atom when building neighbor list for compute_rdf

LAMMPS LAMMPS Mailing List Mirror
1

Dear Steve,

I’m sorry to bother you again. There is still a small problem with my calculation. I find if I turn “check” to “no” for neighbor_modify. The calculation is correct. Otherwise, no matter how I increase binsize, the rdf will be like the following. There are some atoms in the first bin of rdf.

500000 1000
1 0.00475 54332.4 0.00618672
2 0.01425 0 0.00618672
3 0.02375 0 0.00618672
4 0.03325 0 0.00618672
5 0.04275 0 0.00618672
6 0.05225 0 0.00618672
7 0.06175 0 0.00618672
8 0.07125 0 0.00618672
9 0.08075 0 0.00618672
10 0.09025 0 0.00618672

After debugging, I find a possible explanation. There might be some atoms (e.g. K atom) which don’t move larger than half of neighbor skin but move out of the bin since last-reneighboring.(bin is used in neighbor list construction, assume K atom moves from original I bin to J bin. I and J are heads of binlist which are gotten by coor2bin function.) Thus the neighborlist is not rebuilt. When rdf is calculated, a neighborlist is built for rdf by build_one method. However, it uses a wrong bin structure. K atom is still stored in the bin list leaded by binhead[I] but acctually it is not in that bin. If half_bin_newton method is called to construct the neighborlist, when code runs to line 380, the bin number gotten by coor2bin is J but not I. Then when the code runs into the following loop over bins, it might loop into I bin which stores K atom. Thus K atom itself appears in its neighborlist, which results abnormal value for first bin of RDF.

I’m not pretty sure if my explanation is correct. Could you please give me some advice on calibrating the input file? I don’t think check no is a smart way to deal with it. Thank you!

Han

2

Hi - you’ve posted many messages in several threads about neighbor

lists. I’m not following all the details. Sometimes you appear to have

changed or added code to LAMMPS and are asking about internal data

storage within LAMMPS. Other times you say problems have cleared

up when you change your code, indicating there actually was no problem

with LAMMPS.

As far as I know, neighbor lists in LAMMPS work fine for compute rdf. You only

have to insure your input script is building neighbor lists often enough to

track atom movement. Neigh_modify check yes every 1 delay 0 is

a conservative guarantee that is the case. If you have an example

where compute rdf is not calculating the right values, for current LAMMPS

with no code changes by you, then please post a simple-as-possible example

that illustrates the problem, and how you conclude that the results

of compute rdf are incorrect. E.g. if you dump atom coords, you can

calc the RDF yourself and get an obviously different answer.

Steve