Pair-wise potencials changing custom atom proprieties

LAMMPS LAMMPS Mailing List Mirror
1

Hi,

I’m setting up a pair-wise potencial that changes depending on a custom, per atom, propriety, and at the same time changes it’s value. When I’m using only one processor it works ok because it seems I can just ignore the ghost atoms because they dont have this custom propriety(it’s value is 0 for them). Now I want to try to run the script on multiple processors but I’ve run into the issue that I can’t do that without the use of ghost atoms. As this is done in a pair computation I can’t change the compute as I’ve seen sugested and I dont think that there is any pair style that does this. Is there way to do this? Should I just use a new atom style that includes this variable instead of using the custom arrays to store it? Any help would be apreciated.

Gonçalo Paulo

2

Hi,

I'm setting up a pair-wise potencial that changes depending on a custom, per
atom, propriety, and at the same time changes it's value. When I'm using
only one processor it works ok because it seems I can just ignore the ghost
atoms because they dont have this custom propriety(it's value is 0 for
them). Now I want to try to run the script on multiple processors but I've
run into the issue that I can't do that without the use of ghost atoms. As
this is done in a pair computation I can't change the compute as I've seen
sugested and I dont think that there is any pair style that does this. Is
there way to do this? Should I just use a new atom style that includes this
variable instead of using the custom arrays to store it? Any help would be
apreciated.

without knowing the details of the pair style you are working with, it
is only possible to give some generic advice.

what you describe sounds similar to how EAM and related pair styles
work. for EAM, there are two steps.
1) some local property (density from neighbors) is computed for all
pairs and stored in local and ghost atoms. afterwards, a *reverse*
communication is performed to sum the contributions from ghost atoms
to their corresponding local atom. ghost atoms are copies of atoms in
neighboring subdomains.
2) based on the per-atom density information, then some derived
properties are computed to be included in the force computation and
those need to be communicated to ghost atoms. this is done with a
*forward* communication.

to make forward/reverse communication work, you need to provide
routines pack/unpack_forward/reverse_comm() in your pair style and set
how many items per atom are communicated in the pair style
constructor. pair_eam.cpp is the simplest of these styles and a good
place to start reading the source to learn how this works. it is
impossible to say whether you need both or only the forward
communication.

for the forward-only case, you could consider using fix property/atom
with one or more custom properties and then look these up inside the
pair style. if you create the fix with the proper keywords added,
forward communication to ghost atoms is included. this is less
programming but also less powerful and more cumbersome to restart.

axel.

3

I’m doing a kuramoto style potential and I dont think I can use the same method as EAM because that density propriety is calculated each time set while I want the phase to be something that carries is altered each time set but that the atom remembers the next one. I dont think I can do that implementing that same comunication can I?

Gonçalo

4

I'm doing a kuramoto style potential and I dont think I can use the same
method as EAM because that density propriety is calculated each time set
while I want the phase to be something that carries is altered each time set
but that the atom remembers the next one. I dont think I can do that
implementing that same comunication can I?

i don't know this model, so i cannot comment on the details. whether
data is retained or not and whether you need a forward or reverse
communication or both depends on those details.

in principle, per-atom data remains with atoms, until atoms are
exchanged between between processors during the neighbor list rebuild
which redistributes atoms into subdomains.
if you need your data to persist between time steps, you have to do
that kind of communication, which is part of atom styles or can be
provided via fix property/atom. question here is: how is this data
initialized at the beginning of the run? fix property/atom has
mechanisms for that.

whether you need reverse or forward communication or none of them,
depends on how and when you need to update this property, and whether
this is happening via an intermediate data (like type or number of
neighbors or some distance related property or ...) that is computed
for each pair, and whether you are using a half or a full neighbor
list (and whether you use newton on or newton off).

the issue is, that with a full neighbor list, each pair is processed
twice. with a half neighbor list each pair is processed only once with
the default newton on setting: this means if you update some parameter
based on a pair interaction, you have to communicate it back from
ghost atoms to its matching atoms. that is what the reverse
communication is for (which is a summation, it doesn't make sense
otherwise).
with the newton off setting, however, this reverse communication is
not needed, since in this case, all pairs where one atom is a ghost
atom are listed twice and thus you only store the local contribution.

in either case, if you have computed/updated a local property (doing
the outer loop only) and now need to update this to ghost atoms, then
you need to do a forward communication.

hope that clarifies matters some more. if you want further advice, you
have to provide a much more detailed description of the computations
and flow of control (and data) that you are attempting.

axel.