can new atom's property be calculated using an existing pair_style?

Hi,

I am skeptical this is not possible, but just want to ask before shooting. For the new property, says foo, defined using fix property/atom command, can I allocate an existing pair_style so that the value of foo property can be calculated at each time step? Example: I want to have LJ potential to be applied to foo. Can I called the existing LJ potential pair_style or do I have to write new cpp/h files to define the pair_style for foo?

Thanks,
Quang

I might not be the best person to reply to this question, but I think I can answer it anyway.

Unless the pair_style you plan to use explicitly takes custom atom properties into account (and I’m not aware of any that do this), you will have to create your own pair style that does. If this is not possible for whatever reason, you can accomplish the same thing by writing your own fix that loops over all pairs of nearby atoms and applies a force to these atom pairs. (…as opposed to creating a new pair_style. See fix_bond_create.cpp for an example how to loop over nearby atoms.)

Don’t know if I helped.

andrew

Hi,

I am skeptical this is not possible, but just want to ask before shooting.
For the new property, says foo, defined using fix property/atom command, can
I allocate an existing pair_style so that the value of foo property can be
calculated at each time step? Example: I want to have LJ potential to be
applied to foo. Can I called the existing LJ potential pair_style or do I
have to write new cpp/h files to define the pair_style for foo?

you are not making sense here.
the LJ potential is a pairwise interaction. what fix property/atom
provides is a per-atom property. how will you generate the latter from
the former?
pair style hybrid is an example for how you can maintain multiple
instances of a pair style, however, if you want to capture any results
from that, you will have to do your own data management, since each
pair style will tally its results into global arrays and variables.

axel.

Thanks, Axel.

A quick follow-up question - if I just want my new property (i.e. concentration) to diffuse from one atom to nearby, would it be sufficient to write only my fix subroutine or does it have to be coupled with a pair_style as well?

Quang

Thanks, Axel.

A quick follow-up question - if I just want my new property (i.e.
concentration) to diffuse from one atom to nearby, would it be sufficient to
write only my fix subroutine or does it have to be coupled with a pair_style
as well?

you can read from and write to your custom property from anywhere you like.

the only issue, that you have to be careful with is whether you access
that property from "ghost" atoms, i.e. atoms that are copies from
neighboring subdomains.
these are usually not updated unless explicitly requested, and you may
have to do an explicit reverse and/or forward communication to update
those after you made changes to "local" atoms (index in atom->x[] <
atom->nlocal).

axel.

Is there any implemented fixes that calculate the atom properties and do timestep update (i.e. update the change of the property at each time step) that I could use as a reference? I feel lost skimming through the documentation page with such abundant available options…

QT

Is there any implemented fixes that calculate the atom properties and do
timestep update (i.e. update the change of the property at each time step)
that I could use as a reference? I feel lost skimming through the
documentation page with such abundant available options...

it is difficult to give a specific advice here, since different fixes
solve different problems in different ways.
many times the computation of a property is imported from requesting a
compute from inside the fix or requiring the compute to be defined and
passing the compute-id as an argument to the fix command.

the most obvious case of a fix manipulating a per-atom property are
the charge equilibration fixes (fix qeq/*). NOTE: those are run
*before* the pair forces are computed. if you want to update your
per-atom data at a different point in the time stepping, you have to
implement a different fix function and use different fix-flags in
Fix::setmask().

axel.