forked from lijiext/lammps
218 lines
8.9 KiB
HTML
218 lines
8.9 KiB
HTML
<HTML>
|
|
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
|
</CENTER>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<HR>
|
|
|
|
<H3>fix property/atom command
|
|
</H3>
|
|
<P><B>Syntax:</B>
|
|
</P>
|
|
<PRE>fix ID group-ID property/atom vec1 vec2 ... keyword value ...
|
|
</PRE>
|
|
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
|
|
|
|
<LI>property/atom = style name of this fix command
|
|
|
|
<LI>vec1,vec2,... = <I>mol</I> or <I>q</I> or <I>i_name</I> or <I>d_name</I>
|
|
|
|
<PRE> <I>mol</I> = molecule IDs
|
|
<I>q</I> = charge
|
|
<I>i_name</I> = new integer vector referenced by name
|
|
<I>d_name</I> = new floating-point vector referenced by name
|
|
</PRE>
|
|
<LI>zero of more keyword/value pairs may be appended
|
|
|
|
<LI>keyword = <I>ghost</I>
|
|
|
|
<PRE> <I>ghost</I> value = <I>no</I> or <I>yes</I> for whether ghost atom info in communicated
|
|
</PRE>
|
|
|
|
</UL>
|
|
<P><B>Examples:</B>
|
|
</P>
|
|
<PRE>fix 1 all property/atom mol
|
|
fix 1 all property/atom i_myflag1 i_myflag2
|
|
fix 1 all property/atom d_sx d_sy d_sz
|
|
</PRE>
|
|
<P><B>Description:</B>
|
|
</P>
|
|
<P>Create one or more additional per-atom vectors to store information
|
|
about atoms and to use during a simulation. The specified <I>group-ID</I>
|
|
is ignored by this fix.
|
|
</P>
|
|
<P>The atom style used for a simulation defines a set of per-atom
|
|
properties, as explained on the <A HREF = "atom_style.html">atom_style</A> and
|
|
<A HREF = "read_data.html">read_data</A> doc pages. The latter command allows these
|
|
properties to be defined for each atom in the system when a data file
|
|
is read. This fix will augment the set of properties with new custom
|
|
ones.
|
|
</P>
|
|
<P>This can be useful in at least two scenarios.
|
|
</P>
|
|
<P>If the atom style does not define molecule IDs or per-atom charge,
|
|
they can be added using the <I>mol</I> or <I>q</I> keywords. This can be
|
|
useful, e.g, to define "molecules" to use as rigid bodies with the
|
|
<A HREF = "fix_rigid.html">fix rigid</A> command, or just to carry around an extra
|
|
flag with the atoms (stored as a molecule ID). An alternative is to
|
|
use an atom style that does define molecule IDs or charge or to use a
|
|
hybrid atom style that combines two styles to allow for molecule IDs
|
|
or charge, but that has 2 practical drawbacks. First it typically
|
|
necessitates changing the format of the data file. And it may define
|
|
additional properties that aren't needed such as bond lists, which has
|
|
some overhead when there are no bonds.
|
|
</P>
|
|
<P>In the future, we may add additional per-atom properties similar to
|
|
<I>mol</I> or <I>q</I>, which "turn-on" specific properties defined by some atom
|
|
styles, so they can be used by atom styles that don't define them.
|
|
</P>
|
|
<P>More generally, the <I>i_name</I> and <I>d_name</I> vectors allow one or more
|
|
new custom per-atom properties to be defined. Each name must be
|
|
unique and can use alphanumeric or underscore characters. These
|
|
vectors can store whatever values you decide are useful in your
|
|
simulation. As explained below there are several ways to initialize
|
|
and access and output these values, both via input script commands and
|
|
in new code that you add to LAMMPS.
|
|
</P>
|
|
<P>This is effectively a simple way to add per-atom properties to a model
|
|
without needing to write code for a new <A HREF = "atom_style.html">atom style</A>
|
|
that defines the properties. Note however that implementing a new
|
|
atom style allows new atom properties to be more tightly and
|
|
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>
|
|
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
|
|
style</A> or <A HREF = "fix.html">fix</A> or <A HREF = "compute.html">compute</A>
|
|
that you write.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>This fix is one of a small number that can be defined in an input
|
|
script before the simulation box is created or atoms are defined.
|
|
This is so it can be used with the <A HREF = "read_data.html">read_data</A> command
|
|
as described below.
|
|
</P>
|
|
<P>Per-atom properties that are defined by the <A HREF = "atom_style.html">atom
|
|
style</A> are initialized when atoms are created, e.g. by
|
|
the <A HREF = "read_data.html">read_data</A> or <A HREF = "create_atoms.html">create_atoms</A>
|
|
commands. The per-atom properaties defined by this fix are not. So
|
|
you need to initialize them explicitly. This can be done by the
|
|
<A HREF = "read_data.html">read_data</A> command, using its <I>fix</I> keyword and
|
|
passing it the fix-ID of this fix.
|
|
</P>
|
|
<P>Thus these commands:
|
|
</P>
|
|
<PRE>fix prop all property/atom mol d_flag
|
|
read_data data.txt fix prop NULL Molecules
|
|
</PRE>
|
|
<P>would allow a data file to have a section like this:
|
|
</P>
|
|
<PRE>Molecules
|
|
</PRE>
|
|
<PRE>1 4 1.5
|
|
2 4 3.0
|
|
3 10 1.0
|
|
4 10 1.0
|
|
5 10 1.0
|
|
...
|
|
N 763 4.5
|
|
</PRE>
|
|
<P>where N is the number of atoms, and the first field on each line is
|
|
the atom-ID, followed by a molecule-ID and a floating point value that
|
|
will be stored in a new property called "flag". Note that the list of
|
|
per-atom properties can be in any order.
|
|
</P>
|
|
<P>Another way of initializing the new properties is via the
|
|
<A HREF = "set.html">set</A> command. For example, if you wanted molecules
|
|
defined for every set of 10 atoms, based on their atom-IDs,
|
|
these commands could be used:
|
|
</P>
|
|
<PRE>fix prop all property/atom mol
|
|
variable cluster atom ((id-1)/10)+1
|
|
set id * mol v_cluster
|
|
</PRE>
|
|
<P>The <A HREF = "variable.html">atom-style variable</A> will create values for atoms
|
|
with IDs 31,32,33,...40 that are 4.0,4.1,4.2,...,4.9. When the
|
|
<A HREF = "set.html">set</A> commands assigns them to the molecule ID for each atom,
|
|
they will be truncated to an integer value, so atoms 31-40 will all be
|
|
assigned a molecule ID of 4.
|
|
</P>
|
|
<P>Note that <A HREF = "variable.html">atomfile-style variables</A> can also be used in
|
|
place of atom-style variables, which means in this case that the
|
|
molecule IDs could be read-in from a separate file and assinged by the
|
|
<A HREF = "set.html">set</A> command. This allows you to initialize new per-atom
|
|
properties in a completely general fashion.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>For new atom properties specified as <I>i_name</I> or <I>d_name</I>, the
|
|
<A HREF = "compute_property_atom.html">compute property/atom</A> command can access
|
|
their values. This means that the values can be output via the <A HREF = "dump.html">dump
|
|
custom</A> command, accessed by fixes like <A HREF = "fix_ave_atom.html">fix
|
|
ave/atom</A>, accessed by other computes like <A HREF = "compute_reduce.html">compute
|
|
reduce</A>, or used in <A HREF = "variables">atom-style
|
|
variables</A>.
|
|
</P>
|
|
<P>For example, these commands will output two new properties to a custom
|
|
dump file:
|
|
</P>
|
|
<PRE>fix prop all property/atom i_flag1 d_flag2
|
|
compute 1 all property/atom i_flag1 d_flag2
|
|
dump 1 all custom 100 tmp.dump id x y z c_1<B>1</B> c_1<B>2</B>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<P>If you wish to add new <A HREF = "pair_style.html">pair styles</A>,
|
|
<A HREF = "fix.html">fixes</A>, or <A HREF = "compute.html">computes</A> that use the per-atom
|
|
properties defined by this fix, see <A HREF = "Section_modify.html#mod_1">Section
|
|
modify</A> of the manual which has some details
|
|
on how the properties can be accessed from added classes.
|
|
</P>
|
|
<HR>
|
|
|
|
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
|
|
</P>
|
|
<P>This fix writes the per-atom values it stores to <A HREF = "restart.html">binary restart
|
|
files</A>, so that the values can be restored when a
|
|
simulation is restarted. See the <A HREF = "read_restart.html">read_restart</A>
|
|
command for info on how to re-specify a fix in an input script that
|
|
reads a restart file, so that the operation of the fix continues in an
|
|
uninterrupted fashion.
|
|
</P>
|
|
<P>None of the <A HREF = "fix_modify.html">fix_modify</A> options
|
|
are relevant to this fix. No global or per-atom quantities are stored
|
|
by this fix for access by various <A HREF = "Section_howto.html#howto_15">output
|
|
commands</A>. No parameter of this fix can
|
|
be used with the <I>start/stop</I> keywords of the <A HREF = "run.html">run</A> command.
|
|
This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
|
|
</P>
|
|
<P><B>Restrictions:</B> none
|
|
</P>
|
|
<P><B>Related commands:</B>
|
|
</P>
|
|
<P><A HREF = "read_data.html">read_data</A>, <A HREF = "set.html">set</A>, <A HREF = "compute_property_atom.html">compute
|
|
property/atom</A>
|
|
</P>
|
|
<P><B>Default:</B>
|
|
</P>
|
|
<P>The default keyword values are ghost = no.
|
|
</P>
|
|
</HTML>
|