Hi Axel,
I have a very limited knowledge about forward and reverse communication, so
please forgive and correct me if I'm wrong. As far as I understand, the Comm
class uses OpenMP and MPI implementation to parallelize the code. OpenMP
controls threads on processors, and MPI commands control the communication
between procs. LAMMPS supports spatial decomposition scheme, and
communication is established in 6 directions, west -> east, north -> south,
up -> down, and reverse.
I also can see in comm.cpp, there are MPI_Bcast, MPI_Allreduce, MPI_Send and
MPI_Recv commands. Not forget to mention that the Universe class set up the
procs partition. In the MPI_Send syntax:
MPI Send(&buf, count, type, dest, tag, comm, &status)
count = integer indicating the length of the data type sent.
So long story short, these numbers (e.g. size_velocity; size_data_atom;
size_data_vel; xcol_data) changes the length of the message that contains
the information belong to each individual atom on a specific processor.
That's all I know about forward and reverse communication.
which means, you know nothing. ...and that also means, that you will
have to read *much* more of LAMMPS' source code and the available
documentation.
forward communication is the update of position (or position and
velocity, if requested) from local atoms to their respective ghost
atoms of the neighboring domains or periodic copies. reverse
communication is the collection of force (or force and torque or
related) information on ghost atoms to the respective local atoms.
this latter step is not needed when support for newton's third law is
disabled and interactions between local and ghost atoms are computed
multiple times and then only tallied into the respective local atoms..
additional forward and reverse communications can be registered by
various styles, but the purpose is always the same. forward
synchronizes ghost atom data with the respective original data (for
atom style atomic, these are only positions) and reverse collects
information from ghosts to local atoms (for atomic this is only
forces). these steps are needed in every time step. other
communication between domains only happens when atoms migrate during
reneighboring. in this case *all* information is communicated
including registered add-on properties. in forward communication, you
only send data that is needed to be updated on the ghost atoms in
every step to compute interactions (usually only positions, for pair
styles like DPD also velocities), in reverse you collect data from
ghosts to local atoms (usually only forces). everything else is
doesn't change or is only needed on local atoms. typically, if data is
only updated from a fix, these forward/reverse communications are done
by the fix itself and not part of the atom style (see e.g. fix qeq/*
which updates charges).. atom styles usually only update information
required for computing interactions.
I have explained what I know about this topic; can you please show me how to
you still haven't answered my question about why you need to write a
new atom style.
as atom_vec.h says, size_velocity is the number of velocity-like items
that are added to the communication when velocity updates are
requested to be included in the forward communication.
count these numbers ( size_velocity; size_data_atom; size_data_vel;
xcol_data) ?
i already told you that all items with "data" have nothing to do with
communication, but with the data file format.
Also, where is "Atom line" and "Velocity line"?
i already told you: in a data file.
if these things *still* don't mean anything to you, there is little
else i can recommend you to do but spend more time reading source code
(and more carefully so and experimenting with it, very carefully). and
the information in the manual and developer's guide. it is practically
impossible to explain how to do a modification to some rather low
level part of the code without having some common understanding of how
this relates to the rest of the code. this is a case of "if you cannot
stand the heat, don't go into the kitchen". if you insist on doing
these modifications, you will have to understand on a sufficient level
what LAMMPS does and the only way to get there is to read
documentation and source code. nobody will sit down and do your work
for you to implement and debug what you are adding to the code (and
before you ask, telling you in detail what to do exactly is the same,
only it takes even more time)
axel.