git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@11733 f3b2605a-c512-4ea7-a41b-209d697bcdaa

This commit is contained in:
sjplimp 2014-04-07 21:11:50 +00:00
parent eabcf5cd7d
commit 21d4fc077f
2 changed files with 14 additions and 14 deletions

View File

@ -87,18 +87,18 @@ seamlessly integrated with the rest of the code.
</P>
<P>The new atom properties encode values that migrate with atoms to new
processors and are written to restart files. If you want the new
properties to also be defined for ghost atoms, then use the <I>border</I>
properties to also be defined for ghost atoms, then use the <I>ghost</I>
keyword with a value of <I>yes</I>. This will invoke extra communication
when ghost atoms are created (at every re-neighboring) to insure the
new properties are also defined for the ghost atoms.
new properties are also defined for the ghost atoms.
</P>
<P>IMPORTANT NOTE: The properties for ghost atoms are not updated every
timestep, but only once every few steps when neighbor lists are
re-built. Thus the <I>border</I> keyword is suitable for static
properties, like molecule IDs, but not for dynamic properties that
change every step. In that case, the code you add to LAMMPS to change
the properties will also need to communicate their new values, an
operation that can be invoked from within a <A HREF = "pair_style.html">pair
re-built. Thus the <I>ghost</I> keyword is suitable for static properties,
like molecule IDs, but not for dynamic properties that change every
step. For the latter, the code you add to LAMMPS to change the
properties will also need to communicate their new values to/from
ghost atoms, an operation that can be invoked from within a <A HREF = "pair_style.html">pair
style</A> or <A HREF = "fix.html">fix</A> or <A HREF = "compute.html">compute</A>
that you write.
</P>

View File

@ -77,18 +77,18 @@ seamlessly integrated with the rest of the code.
The new atom properties encode values that migrate with atoms to new
processors and are written to restart files. If you want the new
properties to also be defined for ghost atoms, then use the {border}
properties to also be defined for ghost atoms, then use the {ghost}
keyword with a value of {yes}. This will invoke extra communication
when ghost atoms are created (at every re-neighboring) to insure the
new properties are also defined for the ghost atoms.
new properties are also defined for the ghost atoms.
IMPORTANT NOTE: The properties for ghost atoms are not updated every
timestep, but only once every few steps when neighbor lists are
re-built. Thus the {border} keyword is suitable for static
properties, like molecule IDs, but not for dynamic properties that
change every step. In that case, the code you add to LAMMPS to change
the properties will also need to communicate their new values, an
operation that can be invoked from within a "pair
re-built. Thus the {ghost} keyword is suitable for static properties,
like molecule IDs, but not for dynamic properties that change every
step. For the latter, the code you add to LAMMPS to change the
properties will also need to communicate their new values to/from
ghost atoms, an operation that can be invoked from within a "pair
style"_pair_style.html or "fix"_fix.html or "compute"_compute.html
that you write.