editing atom style atom_vec_atomic.cpp

Hello all,

I’m editing the atom style to add 3 more variables, namely xrad, vrad, frad, exactly the same dimension with x, v, f for each atoms. So I rewrite the atom_vec_atomic.cpp file and everything seems pretty clear, except for the constants defined at the top of the code, such as: comm_x_only; comm_f_only; size_velocity; size_data_atom; size_data_vel; xcol_data.

I’m aware of the atom_vec.h comments but still don’t understand how they are counted. So I’m extremely unsure about these 6 quantities for my modified file; my guess is that everything needs to add 3 because I’m adding 3 more data for each communication channel. Please let me know if these constants are not correct.

Many thanks,
Anh Tran

PhD student

Multiscale Systems Engineering Research Group

Georgia Institute of Technology

modified atom_vec_atomic.cpp

Hello all,

I'm editing the atom style to add 3 more variables, namely xrad, vrad, frad,

this is a *very* bad idea. if anything, you should write a _new_ atom
vec class. but for simply adding three properties, the situation is
much simpler and can be done without adding any code by using fix
property/atom.

exactly the same dimension with x, v, f for each atoms. So I rewrite the
atom_vec_atomic.cpp file and everything seems pretty clear, except for the
constants defined at the top of the code, such as: comm_x_only; comm_f_only;
size_velocity; size_data_atom; size_data_vel; xcol_data.

I'm aware of the atom_vec.h comments but still don't understand how they are
counted. So I'm extremely unsure about these 6 quantities for my modified
file; my guess is that everything needs to add 3 because I'm adding 3 more
data for each communication channel. Please let me know if these constants
are not correct.

fix property/atom was particularly written for people like you. if you
don't understand the code you are modifying, you should not be
modifying it. if you insist, you will have to learn how to debug code
you write as well.

axel.

Hello Axel,

Thank you for your response. Because these values are also related to the ensemble (which is also to-be-modified), I find that the fix property/atom command itself won’t be sufficient to achieve my goal. But as you said, I should have created another style to do so. So anyway, would you please tell me if these constants are correct? I’m not 100% sure about the code, but I know these constants are later called in comm.cpp to MPI_Send, according to spatial decomposition scheme, and these variables define the length of the message to be sent or to be received.

Thanks,
Anh

Hello Axel,

Thank you for your response. Because these values are also related to the
ensemble (which is also to-be-modified), I find that the fix property/atom
command itself won't be sufficient to achieve my goal. But as you said, I

i don't understand what you are saying here. specifically, what is
"ensemble" supposed to mean in this context?
outside of a matter of convenience in accessing those properties there
really isn't much of a difference.
you have to come up with a better argument. if fix property/atom had
been around earlier in the development of LAMMPS, there would
definitely be much fewer AtomVecXXX classes.

should have created another style to do so. So anyway, would you please tell
me if these constants are correct? I'm not 100% sure about the code, but I
know these constants are later called in comm.cpp to MPI_Send, according to
spatial decomposition scheme, and these variables define the length of the
message to be sent or to be received.

like i already wrote, debugging *your* code is *your* job. if you are
not sure, you have to come of with strategies to verify what you have
programmed. this will happen anyway, as soon as you move on
implementing new features.

how can you even expect me to even *want* to look at a code and an
approach that i called "a *very* bad idea" (and that was the sanitized
and polite version of expressing myself on this)?

axel.

Your settings look fine, except comm_x_only and
comm_f_only should be 0, since you are not only
communicating x and f. You added xrad and frad.

There is one main thing that fix property/atom
won’t do, which is communicate extra atom
properties at every timestep (only at reneigh steps
and exchange steps). So if you need to do
that, (like for xrad, frad), defining a new atom
style is fine. You could also have your own
fix (e.g. a new integration fix) do that comm,
but the atom style is fine as well.

Steve

Steve and Axel, thank you very much for your helpful responses. Steve, if you don’t mind, would you please elaborate how one can count these quantities? They are written in atom_vec.h that I pull out.

int comm_x_only; // 1 if only exchange x in forward comm
int comm_f_only; // 1 if only exchange f in reverse comm

int size_data_atom; // number of values in Atom line
int size_data_vel; // number of values in Velocity line

int xcol_data; // column (1-N) where x is in Atom line

I’m not sure what Atom line and Velocity line are referred to.

Thanks again for your help,

Anh

Steve and Axel, thank you very much for your helpful responses. Steve, if
you don't mind, would you please elaborate how one can count these
quantities? They are written in atom_vec.h that I pull out.

  int comm_x_only; // 1 if only exchange x in forward
comm
  int comm_f_only; // 1 if only exchange f in reverse
comm

  int size_data_atom; // number of values in Atom line
  int size_data_vel; // number of values in Velocity line

  int xcol_data; // column (1-N) where x is in Atom
line

I'm not sure what Atom line and Velocity line are referred to.

obviously a line in the data file.

Steve and Axel, thank you very much for your helpful responses. Steve, if
you don't mind, would you please elaborate how one can count these
quantities? They are written in atom_vec.h that I pull out.

count which quantities where and for what purpose?

Hi Axel,

If possible, I would like to learn how to determine these following quantities: comm_x_only; comm_f_only; size_velocity; size_data_atom; size_data_vel; xcol_data for an arbitrary atomic_style; for instance, atom_vec_charge.cpp defines these as
comm_x_only = comm_f_only = 1;
size_velocity = 3;
size_data_atom = 6;
size_data_vel = 4;
xcol_data = 4;

but I don’t know why these numbers. I’m aware of the thread http://lammps.sandia.gov/threads/msg16693.html but it still doesn’t make a lot of sense to me. I must be missing something in between.

Thanks,
Anh

Hi Axel,

If possible, I would like to learn how to determine these following
quantities: comm_x_only; comm_f_only; size_velocity; size_data_atom;
size_data_vel; xcol_data for an arbitrary atomic_style; for instance,
atom_vec_charge.cpp defines these as
  comm_x_only = comm_f_only = 1;

steve already told you about those two.

  size_velocity = 3;
  size_data_atom = 6;
  size_data_vel = 4;
  xcol_data = 4;
but I don't know why these numbers. I'm aware of the thread
http://lammps.sandia.gov/threads/msg16693.html but it still doesn't make a
lot of sense to me. I must be missing something in between.

their meaning is listed in atom_vec.h
for any of the "data" flags, you also have to look at the
documentation of the data file format.

it is difficult to give any detailed explanation unless you explain
what you *do* understand. particularly about forward and reverse
communication.
you also so far, have not explained why you need to include your
additional properties in those steps.

axel.

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.

I have explained what I know about this topic; can you please show me how to count these numbers ( size_velocity; size_data_atom; size_data_vel; xcol_data) ? Also, where is “Atom line” and “Velocity line”?

Many thanks,
Anh

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.

size_velocity = 3;

How many extra values are communicated in
pack_comm_vel() versus pack_comm(), when
you also communicate velocities

size_data_atom = 6;

the # of values in a per-atom line
of the Atoms section of a data file > size_data_vel = 4;

size_data_vel = 4;

the # of values in a per-atom line
of the Velocities section of a data file