Dear LAMMPS Community,
The comment above that line of code says:
// anyghostlist = 1 if any non-occasional list stores neighbors of ghosts
hence the check for whether its an occasional list or not.
LAMMPS has different rules for bulding frequent lists vs occasional lists.
Could anyone give me hint about why an occasional neigh_list should not contain ghost atoms’ neighbors.
I don’t know what you’re trying to do. Are you writing your own compute or fix that needs
neighbors of ghosts? I don’t believe there is any other such compute in LAMMPS
currently. So it’s possible there is no code to do that, since we’ve never needed
to do it before.
Or are you describing what you think is a bug in existing LAMMPS code? If so,
you haven’t explained what command is triggering it, or why you think the
command is doing the wrong thing.
Setve
Hi Steve,
Thanks for the prompt reply. I mean I see the comment above, but I don’t get the point why only non-occasional list can or should store neighbors of ghosts, i.e., why an occasional list that stores neighbors of ghosts is considered non-existent or, I mean ignored.
LAMMPS has different rules for bulding frequent lists vs occasional lists.
Sure. As far as I know frequent lists are built in Neighbor::build while the occasional lists should be built by manually calling Neighbor::build_one. I might be wrong so I appreciate it if you could make sure this is correct or give the appropriate way to build occasional lists which might hopefully solve my problem.
I don’t know what you’re trying to do. Are you writing your own compute or fix that needs
neighbors of ghosts? I don’t believe there is any other such compute in LAMMPS
currently. So it’s possible there is no code to do that, since we’ve never needed
to do it before.
Yes, I’m writing my own fix and accommodate my needs I’m also writing a thin pair_style wrapper on top of pair_lj_cut_coul_long in which I request a occasional full neighbor list that contains neighbors of ghosts as well. (I could use non-occasional version and maxatom will be correct, but this incurs overhead that might not be necessary so I decide to go for occasional list). As far as I can see it doesn’t matter whether I make the neighbor list request in the pair or in the fix, the code I describe will behave the same. I’m also not aware of any existing code requesting such kind of neighbor list, so I’m nervous about doing something silly.
Or are you describing what you think is a bug in existing LAMMPS code? If so,
you haven’t explained what command is triggering it, or why you think the
command is doing the wrong thing.
I’m not sure whether it is a bug or not that “an occasional list that stores neighbors of ghosts is ignored” because: 1) no existing code requests such kind of neighbor list so I think existing code will not trigger this “corner case”; 2) I still don’t get the point why such kind of neighbor list is ignored and I’m afraid there are some deeper consideration that will rule out such neighbor list. However, the member function Neighbor::full_bin_ghost exists to build such kind of neighbor list and this member function is used in Neighbor::choose_build, it seems such neighbor list should be legitimate. But I might be wrong about the purpose of Neighbor::full_bin_ghost.
So I think my point should be “I’m writing my extension code and hit a corner case, and I’m kind of confused now.”.
Thanks again for reading and replying my corner case.
Sincerely,
Wenjun Ouyang
If the code you’ve added works if you request a neigh list
with ghosts as frequent (non-occasional), but not when
you request it occasional, then it’s probably b/c this
option has never been used before (not needed for any current
LAMMPS code). So you are expecting the internal API to support
something it actually doesn’t (yet) do.
Doesn’t mean it couldn’t be augmented to do that, just
that nothing has needed it, so it hasn’t been coded for.
No other pair style requests occasional lists, so that could
be another unsupported thing you are expecting to work.
Since pair styles get called every time step, I don’t see
how they could work with an occasional (out-of-date) list.
You might look at the peridynamic pair styles. They use fix peri neigh
as a fix that requests an occasional (actually one time)
neighbor list they use for PD bonds. If you coded your pair/fix like
that it might work. The fix has the logic to insure the one-time
list info migrates with atoms, so that the neigh list can actually
be used in an occasional manner.
There is not enough hi-level description of what you want
to do in your emails to offer any further advice.
Steve