One part I can’t quite figure out is how the positions of ghosts are updated every time-step after neighbor list construction. Specifically how the new positions, velocities etc. are packed in one processor in the message and sent to the other to distribute among the ghosts in another processor without having to search through the indices to assign each piece of data to the correct ghost.
One part I can't quite figure out is how the positions of ghosts are
updated every time-step after neighbor list construction.
positions of ghosts are updated (and velocities, but only if requested)
on every time step *except* on those where neighbor lists are rebuilt via
comm->forward_comm(). the indices of atoms that need to be communicated are
identified *on* the time steps when neighbor lists are rebuilt.
on the steps where neighbor lists are rebuilt, there are calls to
comm->exchange() that migrates atoms between sub-domains and then
comm->borders() to define the stencil of atoms inside the communication
cutoff and update the lists used during comm->forward_comm()
Specifically how the new positions, velocities etc. are packed in one
processor in the message and sent to the other to distribute among the
ghosts in another processor without having to search through the indices to
assign each piece of data to the correct ghost.
LAMMPS uses lookup lists. for comm_style brick, they are in comm->sendlist
(see comm_brick.h)
axel.
I see that, is there an interface between the x data structure defined for atom_vec_atomic.h and the x for atom.h?
Pointers for the single Nx3 array like x (atom coords)
are stored in both atom.h and atom_vec.h. For
convenience in accessing them in the rest of the
code as atom->x. But it is the AtomVec classes
that really own the per-atom vecs/arrays and alloc/realloc
them.
Steve
Alright, but what I was wondering is where atom->x is updated for future binning etc. I’ve only found changes to the atom_vec->x.
Alright, but what I was wondering is where atom->x is updated for future
binning etc. I've only found changes to the atom_vec->x.
what do you mean by "updated for future binning". it looks to me, that
you are making assumptions about how LAMMPS work and manages its data,
that are not correct and hence you fail to find what you are looking
for. also, you must be looking at a different source code than me. i
don't see any references to atom_vec->x in my copy.
the x, v, f, and other general per-atom arrays are all all accessible
through the Atom class
(which is instantiated into the LAMMPS class and the Pointers class
holds a reference to it under "atom", so that all classes derived from
Pointers can refer to them via atom->x or atom->f or atom->tag).
the various classes derived from AtomVec (which one this is depends on
the "atom_style" setting) now *manage* the storage that is pointed to
by these per-atom data pointers. depending on the choice of atom
style, those will be just the minimal set or more. those classes now
also define the methods that pack and unpack per-atom data into
communication buffers for the various communication patterns of the
comm classes. now the *contents* of the x arrays are updated by the
various fixes and commands that change coordinates as usual, e.g. fix
nve, fix move or displace_atoms
HTH,
axel.