Re: [lammps-users] Pair-wise potencials changing custom atom proprieties
Axel Kohlmeyer <akohlmey@...24...>
Thu, 3 May 2018 21:17:38 -0400
On Thu, May 3, 2018 at 8:33 PM, Gonçalo Paulo <g-spaulo@...8...> wrote:
> 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
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.
> De: Axel Kohlmeyer <akohlmey@...24...>
> Enviado: 3 de maio de 2018 21:50:43
> Para: Gonçalo Paulo
> Cc: firstname.lastname@example.org
> Assunto: Re: [lammps-users] Pair-wise potencials changing custom atom
> On Thu, May 3, 2018 at 4:20 PM, Gonçalo Paulo <g-spaulo@...8...> wrote:
>> I'm setting up a pair-wise potencial that changes depending on a custom,
>> 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
>> 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
>> variable instead of using the custom arrays to store it? Any help would be
> 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
> 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.
>> Gonçalo Paulo
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> lammps-users mailing list
> Dr. Axel Kohlmeyer akohlmey@...24... http://goo.gl/1wk0
> College of Science & Technology, Temple University, Philadelphia PA, USA
> International Centre for Theoretical Physics, Trieste. Italy.
Dr. Axel Kohlmeyer akohlmey@...24... http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.