mirror of https://github.com/lammps/lammps.git
git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@11733 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
parent
eabcf5cd7d
commit
21d4fc077f
|
@ -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.
|
||||
</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>
|
||||
|
|
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue