programming question: neigh_list.cpp

Hello users,

I’m trying to understand the construction of neighbor list. These values are defined, for instance starting on line 86 in pair_lj_cut.cpp :

“”"
inum = list->inum;
ilist = list->ilist;
numneigh = list->numneigh;
firstneigh = list->firstneigh;
“”"

I’ve tracked them down in neigh_list.cpp, line 32:

“”"
inum = gnum = 0;
ilist = NULL;
numneigh = NULL;
firstneigh = NULL;
“”"

My question is, where are these values being initialized. In neigh_list.cpp, they are being set to 0 and NULL but at what point are they being set to actual values?

Thanks for the help and thanks Axel :slight_smile:

Hello users,

I'm trying to understand the construction of neighbor list. These values
are defined, for instance starting on line 86 in pair_lj_cut.cpp :

"""
inum = list->inum;
ilist = list->ilist;
numneigh = list->numneigh;
firstneigh = list->firstneigh;
"""

I've tracked them down in neigh_list.cpp, line 32:

"""
inum = gnum = 0;
ilist = NULL;
numneigh = NULL;
firstneigh = NULL;
"""

My question is, where are these values being initialized. In
neigh_list.cpp, they are being set to 0 and NULL but at what point are they
being set to actual values?

in one of the various neighbor list constructions subroutines.

have care, there be dragons if you keep on reading.
the neighbor list code is probably the most complex and difficult to
read code in LAMMPS.

let me step back a little bit. there is not 'the' neighbor list code,
but many variants

there are different "consumers" of neighbor lists: pair styles, fixes, computes
also, there are different "kinds" of neighbor lists: full/half/multi,
with/without binning, with/without newton's 3rd law for pairs between
local and ghost atoms, with shearing history for granular media, for
r-RESPA, with/without ghost atom velocities, for USER-DPD
and, there are different "variants" for how to compute them: regular
on the CPU, multi-threaded with OpenMP, accelerated via KOKKOS

this all leads to a plethora of actual neighbor list construction
functions in different files. the specific neighbor list code that is
needed to build the neighbor list, is determined by the various
neighbor list requests (which are stored in a list). the code in

void Neighbor::choose_build(int index, NeighRequest *rq)

will then try to match the request with various neighbor list build
functions. it also tries to determine, whether multiple requests
require the same neighbor lists, or if neighbor lists can be
constructed from other existing neighbor lists, and whether specific
accelerated variants are required.

example:
if you have a simple input with lj/cut pair style, the
Pair::init_style() method will request a persistent pair style half
neighbor list with binning and newton's 3rd law on.
that list is built via void Neighbor::half_bin_newton(NeighList *list)
in neigh_half_bin.cpp
if you change from the default settings to

neighbor 0.3 nsq

you will get void Neighbor::half_nsq_newton(NeighList *list) in
neigh_half_nsq.cpp

if you set in addition:

newton off

you will get void Neighbor::half_nsq_no_newton(NeighList *list) in
neigh_half_nsq.cpp

and if you turn on USER-OMP via: -pk omp 0 -sf omp

you will get void Neighbor::half_nsq_no_newton_omp(NeighList *list) in
neigh_half_nsq_omp.cpp

confused already? well, this is how it currently works.
there is a refactoring branch in the works, that makes this more
modular to accommodate the growing need for having more and more
permutations of multiple neighbor list request flags active. but it
possibly become even more complicated to read and understand, as the
parts are going to be scattered across even more files.

axel.

You’re looking at the constructor for a sort of “parent” interface which doesn’t perform those kinds of details, look at the implementation for a class like neigh_full or neigh_bin which implements the routines that alter those values (since they’re declared public in neigh_list.h). The implementation and design for neighbor list styles differs from other things like fixes and computes since it’s probably older.

Axel,

This is the exact answer I was looking for. Thanks!