addforce-compute property/atom

Greetings,

If I use fix addforce to a group of atoms and then use compute property/atom requesting the force components for that group of atoms will it include the force from addforce? At the moment I just see output that tends to average towards zero so my first hunch is that it doesn’t add the contribution.

Greetings,

If I use fix addforce to a group of atoms and then use
compute property/atom requesting the force components for that group of
atoms will it include the force from addforce? At the moment I just see
output that tends to average towards zero so my first hunch is that it
doesn't add the contribution.

​yes, it should include it. it may depend, however, when you add the force
and when you access the force data.

if i modify the melt example as follows:

pair_style zero 2.5
pair_coeff 1 1

fix 2 all addforce 1.0 2.0 3.0

compute 1 all property/atom fx fy fz

dump 1 all custom 50 dump.lammpstrj id x y z fx fy fz c_1[*]

i get the expected values of 1 2 3​ 1 2 3 in the last 6 columns.

axel.

I see, the likely culprit then is that my addforce is specified after the compute.

I see, the likely culprit then is that my addforce is specified after the
compute.

​it is not that simple. computes don't do anything unless something
requests their data.

e.g. if you request the data in a dump or with fix ave/atom, then the
compute is called very late in the timestep and thus it doesn't matter
where fix addforce is defined, as this is called at the "post_force" phase,
while fix ave_atom is called at "end_of_step" and dump is after that.

axel.

True, thanks for that reminder. The ave/time calling it was likewise placed however so same issue.

True, thanks for that reminder. The ave/time calling it was likewise
placed however so same issue.

​fix ave/time is called on "end_of_step", too. that is way after
"post_force"

if you want to make certain, just insert a debug printf()

axel.​

Hi axel and steve,

I want to know the difference between standard neighbor list and half list in lammps code. Regularly, we almost use the the half list, right?.

When the neighborlists were built, do the nearest/minimum image convention was followed for periodic boundary conditions? If not, how the lammps deal with it.

Hi axel and steve,

I want to know the difference between standard neighbor list and half list
in lammps code. Regularly, we almost use the the half list, right?.

​a full list has *all* i,j pairs show up twice: i as neighbor of j and j as
neighbor of i. in a half list each pair is contained only once for pairs
fully contained inside the subdomain. for pair where one atom is local and
the second is a "ghost" atom, it depends on the newton setting (with off,
those pairs are both listed, with on only one of them).

When the neighborlists were built, do the nearest/minimum image convention
was followed for periodic boundary conditions? If not, how the lammps deal
with it.

​LAMMPS does not need to apply minimum image conventions, because it uses
and maintains "ghost" atoms, i.e. copies​ of the original atoms, the
neighbor list code will find the *closest atom* (be it a local or a ghost
atom). thus in LAMMPS you can have a cutoff larger than half of the cell.

axel.

p.s.: please do not send an e-mail to us personally and the mailing list. just e-mailing to the mailing list has the exact same effect (after all, steve and i are both subscribed), but the additional benefit, that it causes less effort to handle, since one can already filter the messages into the proper folder.

thanks for your understanding,
axel.