Accessing neighbor list in coupled code or via compute

Dear lammps users,

I have an order parameter code I’ve written that requires the neighbor list and I would like to implement it in a C++ code that is coupled with lammps and calls it as a library. I am familiar with this order parameter and have confirmed that my code works from using it in previous MC codes that do not use lammps.

Now I have written my order parameter as a lammps compute class but am having an issue where atoms at the edge of a subdomain are not being identified correctly by my compute, leading me to believe that atoms are not seeing their neighbors that are on another processor. To verify this, I tried running my code on a single processor and this time all atoms near the edge of my cubic box are not being identified by the compute. In this case it looks like these atoms do not see the image of their neighbors through the periodic boundary conditions. (Would running an mpi job on 1 processor cause an issue here? )

So it seems my issue has to do with incorrectly accessing the neighborlist in my compute. I have followed the compute_cna_atom.cpp/h codes as a guide since my order parameter is very similar to the CNA method, yet I can’t find where my problem lies. My init() function switches on the options for compute, full, occasional, and ghost (all = 1). I would highly appreciate any guidance on how to make sure that my lists include ghost atoms and their neighbors to help me solve this issue that I have already spent a significant amount of time trying to figure out on my own.

Alternatively, if there is a way to compile lammps’ neighbor list into a single full neighbor list array with global atom indices that I could extract to my C code, then I could calculate my order parameter on my side of the code rather than directly through lammps.

Thank you,
Abdullah

Dear lammps users,

I have an order parameter code I’ve written that requires the neighbor
list and I would like to implement it in a C++ code that is coupled with
lammps and calls it as a library. I am familiar with this order parameter
and have confirmed that my code works from using it in previous MC codes
that do not use lammps.

Now I have written my order parameter as a lammps compute class but am
having an issue where atoms at the edge of a subdomain are not being
identified correctly by my compute, leading me to believe that atoms are
not seeing their neighbors that are on another processor. To verify this, I
tried running my code on a single processor and this time all atoms near
the edge of my cubic box are not being identified by the compute. In this
case it looks like these atoms do not see the image of their neighbors
through the periodic boundary conditions. (Would running an mpi job on 1
processor cause an issue here? )

​i don't understand what you are saying here.​

So it seems my issue has to do with incorrectly accessing the neighborlist
in my compute. I have followed the compute_cna_atom.cpp/h codes as a guide
since my order parameter is very similar to the CNA method, yet I can’t
find where my problem lies. My init() function switches on the options for
compute, full, occasional, and ghost (all = 1). I would highly appreciate
any guidance on how to make sure that my lists include ghost atoms and
their neighbors to help me solve this issue that I have already spent a
significant amount of time trying to figure out on my own.

​neighbor lists will *always* contain ghost atoms. the "ghost" flag in the
neighbor list request will also include neighbors of ghost atoms, which is
not likely what you want. your problem must lie in your code. ​you did the
right step, by following some similar code example, but it looks like you
didn't study the code well enough. however, it is next to impossible to
give you specific advice. it looks to me, like you need to improve your
skills of reading and understanding C/C++ code.

Alternatively, if there is a way to compile lammps’ neighbor list into a

single full neighbor list array with global atom indices that I could
extract to my C code, then I could calculate my order parameter on my side
of the code rather than directly through lammps.

​no. that would be far too complex. neighbor lists are always created in
parallel for each subdomain only. if you absolutely want to do the
processing in your own code, it would be much easier to simply extract the
coordinates and write a simple spatial binning scheme by yourself. for the
kind of analysis you are doing, you will have most of the speedup by doing
a simple cell list scheme, you don't really need to build full neighbor
lists. for cubic boxes, cell lists can be done with rather little
programming. i've written a very simple implementation for a minimal MD
code, that i use regularly for programming projects in workshops (there is
a C and a Fortran version GitHub - akohlmey/ljmd-c: Lennard-Jones MD code in C for teaching purposes
GitHub - akohlmey/ljmd-f: Lennard-Jones MD code in Fortran for teaching purposes )

​axel.