Default 2 neighbor list requests

Dear Users,

I recently updated to LAMMPS -May 2015 version. It seems that for all my runs regardless of neighbor command in the input file, the default number of neighbor list build has been switched to 2.

An example of pre-simulation information:

LAMMPS (15 May 2015)
Reading data file …
orthogonal box = (0 0 0) to (43.006 43.006 43.006)
2 by 2 by 2 MPI processor grid
reading atoms …
5998 atoms
Neighbor list info …
2 neighbor list requests
update every 1 steps, delay 10 steps, check yes
master list distance cutoff = 12
Setting up run …
Memory usage per processor = 129.934 Mbytes

I was wondering if it was an issue with the build an/or hoping for any suggestions to rectify the issue. Thank you in advance.

Sincerely,
Ruhil

Dear Users,

I recently updated to LAMMPS -May 2015 version. It seems that for all my
runs regardless of neighbor command in the input file, the default number
of neighbor list build has been switched to 2.

An example of pre-simulation information:

LAMMPS (15 May 2015)
Reading data file ...
  orthogonal box = (0 0 0) to (43.006 43.006 43.006)
  2 by 2 by 2 MPI processor grid
  reading atoms ...
  5998 atoms
Neighbor list info ...
  2 neighbor list requests
  update every 1 steps, delay 10 steps, check yes
  master list distance cutoff = 12
Setting up run ...
Memory usage per processor = 129.934 Mbytes

I was wondering if it was an issue with the build an/or hoping for any
suggestions to rectify the issue. Thank you in advance.

​why do you think there is something that needs to be rectified?
where is the evidence that there should be only one neighbor list request?
how should anybody be able to tell without *any* information about your
simulation input? mind reading??

axel.

Dear Axel and Users,

Sorry about that. Here’s a simple equilibration run on a 6000 atoms a 300K using ReaxFF. I realize for using neighbor list to simplify non bonded energy calculation, but I am not sure how it decides on applying two neighbor list.

REAX potential for Soda-aluminosilicate glass system

units real
dimension 3
boundary p p p
atom_style charge
read_data data.NaAlSi
#read_restart NaAlSi.rest

pair_style reax/c NULL
pair_coeff * * ffield.reax.NaAlSi O Na Al Si
fix 99 all qeq/reax 1 0.0 10.0 1.0e-6 reax/c
#neighbor 3.0 bin
#neigh_modify every 1 check yes
timestep 0.25
thermo 100

thermo_style custom step etotal temp press pe vol lx

sampling

fix 1 all nvt temp 300 300 25
run 150000

write_restart NaAlSi.restart
unfix 1

Thank you.

Sincerely,
Ruhil

Dear Axel and Users,

Sorry about that. Here's a simple equilibration run on a 6000 atoms a 300K
using ReaxFF. I realize for using neighbor list to simplify non bonded
energy calculation, but I am not sure how it decides on applying two
neighbor list.

​the second request originates from fix qeq/reax. it *also* needs to loop
over nearby neighbors and this needs to be ​efficiently as well. :wink:

as a test, you can comment out the charge equlibration fix, then there
should be only one neighbor list request.

axel.

Dear Alex,

That did solve the 2 neighbor lists issue. However, commenting out the fix qeq/reax uses static charge for the reax a fundamental issue with how reax is setup. I will stick with 2 neighbor lists, thank you for clearing the issue.

Sincerely,
Ruhil

Dear Alex,

That did solve the 2 neighbor lists issue. However, commenting out the fix
qeq/reax uses static charge for the reax a fundamental issue with how reax
is setup. I

​i didn't tell you to run your simulation this way, i was trying to make a
point. please do me the honor of paying sufficient attention to what i am
telling you.​

will stick with 2 neighbor lists, thank you for clearing the issue.

​there *is* no issue. full stop. you have still not explained why having
two neighbor requests is not correct. having two neighbor list *requests*
does not automatically mean that LAMMPS *computes* two neighbor lists. all
it means that two entities have requested a neighbor lists, and that IS THE
CORRECT AND EXPECTED​ BEHAVIOR FOR YOUR SIMULATION. if it would show only 1
request, now *that* would be a problem.

LAMMPS will figure out by itself, what is the best way of providing
suitable neighbor lists to its requestors. if the request parameters are
compatible, the same neighbor list is passed to both requestors. however,
if they are not, LAMMPS will construct two lists, but can sometimes save
time and effort by building one list from the other.

axel.

Dear Alex,

Initially, I was not sure on why there would be two neighbor requests since it is required only for non bonded interaction and assumed that it would be double counting neighbors and effect the simulation time. Since the idea of building neighbor lists is for efficiency, I felt it did not make sense for 2 lists. However, I did not realize that charge equilibration invokes a separate neighbor lists requests, which could be passed to both requesters. Thank you for your help in explaining the neighbor lists requests.

Sincerely,
Ruhil