Neighborlist Algorithm

[William French]

Hello HOOMD Users,

I have a question that is mostly out of curiosity, nothing urgent at all.  I am running HOOMD on a 8790-particle system using the EAM potential.  I am comparing my results to running LAMMPS on my mac desktop, 8-cpu cores.  The thermodynamic output is consistent between the two runs, but I do notice that the neighborlist stats are different by about a factor of 2.  I'm assuming this is because of some differences between the two neighborlisting algorithms.  I am careful to issue the "same" commands between my HOOMD and LAMMPS input scripts:

In LAMMPS:

...
neighbor        0.5 bin
neigh_modify    every 1 delay 0 check yes
...

In HOOMD:

...
nlist.set_params(r_buff=0.5,check_period=1)
...

After 100k time steps, LAMMPS reports 205,782 total neighbors, while HOOMD reports 8790*n_neigh_avg (46.8416) = 411,738 total neighbors.  Similarly, while LAMMPS reports a total of 3979 neighborlist builds, HOOMD reports 7778 normal updates + 335 forced updates = 8113 updates.  Both numbers are off by about a factor of 2, which led me to believe that this is possibly related to the fact that Newton's Third Law is not invoked in HOOMD, but I don't think that would explain the total number of nlist rebuilds being different.  On a related note, what exactly is a "forced update" in the HOOMD context?

BTW, HOOMD on a GTX 580 beat LAMMPS on 8 cpu cores by almost a factor of 12 in this case.  Not too shabby!

Best,

Will French 

[Carolyn Phillips]

Hi William,

First, yes, because the third law is not exploited on the GPU, the neighbor list is twice as big.

Second, forced_updates are generally caused when the particles are resorted on the Hilbert Curve. Naturally after all the indices have internally changed, the neighborlists must be rebuilt.

Third, It is interesting that the number of rebuilds is different and by a factor of two. I am assuming you are using the same time step size for both simulations and they are running over the same elapsed time?

My only idea after that is that LAMMPS has some clever neighborlist tricks built into it for some use cases that are harder to implement on the GPU. I don't know if your use case would be one of those use cases or not. Maybe somebody else has an idea on this!

-Carolyn

> --
> You received this message because you are subscribed to the Google Groups "hoomd-users" group.
> To post to this group, send email to hoomd...@googlegroups.com.
> To unsubscribe from this group, send email to hoomd-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hoomd-users?hl=en.

[william....@gmail.com]

Turns out the other thing that was off by a factor of two was my time
step :-) Fixing that resulted in the total number of rebuilds being
very similar between LAMMPS and HOOMD. The total number of neighbors
remained larger by about a factor of two in HOOMD, as expected. Sorry
for the false alarm!

Thanks for the response, Carolyn.

Best,

Will