2006-09-22 00:22:34 +08:00
|
|
|
<HTML>
|
2014-01-18 03:02:13 +08:00
|
|
|
<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>
|
2006-09-22 00:22:34 +08:00
|
|
|
</CENTER>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<H3>atom_modify command
|
|
|
|
|
</H3>
|
|
|
|
|
<P><B>Syntax:</B>
|
|
|
|
|
</P>
|
2010-01-14 04:56:56 +08:00
|
|
|
<PRE>atom_modify keyword values ...
|
2006-09-22 00:22:34 +08:00
|
|
|
</PRE>
|
|
|
|
|
<UL><LI>one or more keyword/value pairs may be appended
|
|
|
|
|
|
2014-01-18 03:02:13 +08:00
|
|
|
<LI>keyword = <I>id</I> or <I>map</I> or <I>first</I> or <I>sort</I>
|
2006-09-22 00:22:34 +08:00
|
|
|
|
2014-01-18 03:02:13 +08:00
|
|
|
<PRE> <I>id</I> value = <I>yes</I> or <I>no</I>
|
|
|
|
|
<I>map</I> value = <I>array</I> or <I>hash</I>
|
2014-01-18 05:51:23 +08:00
|
|
|
<I>first</I> value = group-ID = group whose atoms will appear first in internal atom lists
|
2014-01-18 03:02:13 +08:00
|
|
|
<I>sort</I> values = Nfreq binsize
|
|
|
|
|
Nfreq = sort atoms spatially every this many time steps
|
|
|
|
|
binsize = bin size for spatial sorting (distance units)
|
2006-09-22 00:22:34 +08:00
|
|
|
</PRE>
|
|
|
|
|
|
|
|
|
|
</UL>
|
|
|
|
|
<P><B>Examples:</B>
|
|
|
|
|
</P>
|
2008-02-16 03:09:18 +08:00
|
|
|
<PRE>atom_modify map hash
|
2010-01-14 04:56:56 +08:00
|
|
|
atom_modify map array sort 10000 2.0
|
2008-02-16 03:09:18 +08:00
|
|
|
atom_modify first colloid
|
2006-09-22 00:22:34 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P><B>Description:</B>
|
|
|
|
|
</P>
|
2014-01-18 03:02:13 +08:00
|
|
|
<P>Modify certain attributes of atoms defined and stored within LAMMPS,
|
|
|
|
|
in addition to what is specified by the <A HREF = "atom_style.html">atom_style</A>
|
|
|
|
|
command. The <I>id</I> and <I>map</I> keywords must be specified before a
|
|
|
|
|
simulation box is defined; other keywords can be specified any time.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The <I>id</I> keyword determines whether non-zero atom IDs can be assigned
|
|
|
|
|
to each atom. If the value is <I>yes</I>, which is the default, IDs are
|
|
|
|
|
assigned, whether you use the <A HREF = "create_atoms.html">create atoms</A> or
|
|
|
|
|
<A HREF = "read_data.html">read_data</A> or <A HREF = "read_restart.html">read_restart</A>
|
|
|
|
|
commands to initialize atoms. If atom IDs are used, they must all be
|
|
|
|
|
positive integers. They should also be unique, though LAMMPS does not
|
|
|
|
|
check for this. Typically they should also be consecutively numbered
|
|
|
|
|
(from 1 to Natoms), though this is not required. Molecular <A HREF = "atom_style.html">atom
|
|
|
|
|
styles</A> are those that store bond topology information
|
|
|
|
|
(styles bond, angle, molecular, full). These styles require atom IDs
|
|
|
|
|
since the IDs are used to encode the topology. Some other LAMMPS
|
|
|
|
|
commands also require the use of atom IDs. E.g. some many-body pair
|
|
|
|
|
styles use them to avoid double computation of the I-J interaction
|
|
|
|
|
between two atoms.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The only reason not to use atom IDs is if you are running an atomic
|
|
|
|
|
simulation so large that IDs cannot be uniquely assigned. For a
|
2014-01-18 05:51:23 +08:00
|
|
|
default LAMMPS build this limit is 2^31 or about 2 billion atoms.
|
|
|
|
|
However, even in this case, you can use 64-bit atom IDs, allowing 2^63
|
|
|
|
|
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
|
|
|
|
|
switch. This is described in <A HREF = "Section_start.html#start_2">Section 2.2</A>
|
|
|
|
|
of the manual. If atom IDs are not used, they must be specified as 0
|
|
|
|
|
for all atoms, e.g. in a data or restart file.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<P>The <I>map</I> keyword determines how atom ID lookup is done for molecular
|
2014-01-18 03:02:13 +08:00
|
|
|
atom styles. Lookups are performed by bond (angle, etc) routines in
|
2006-09-22 00:22:34 +08:00
|
|
|
LAMMPS to find the local atom index associated with a global atom ID.
|
2014-01-18 03:02:13 +08:00
|
|
|
</P>
|
|
|
|
|
<P>When the <I>array</I> value is used, each processor stores a lookup table
|
|
|
|
|
of length N, where N is the largest atom ID in the system. This is a
|
|
|
|
|
fast, simple method for many simulations, but requires too much memory
|
|
|
|
|
for large simulations. The <I>hash</I> value uses a hash table to perform
|
|
|
|
|
the lookups. This can be slightly slower than the <I>array</I> method, but
|
|
|
|
|
its memory cost is proportional to the number of atoms owned by a
|
|
|
|
|
processor, i.e. N/P when N is the total number of atoms in the system
|
|
|
|
|
and P is the number of processors.
|
|
|
|
|
</P>
|
|
|
|
|
<P>When this setting is not specified in your input script, LAMMPS
|
|
|
|
|
creates a map, if one is needed, as an array or hash. See the
|
|
|
|
|
discussion of default values below for how LAMMPS chooses which kind
|
|
|
|
|
of map to build. Note that atomic systems do not normally need to
|
|
|
|
|
create a map. However, even in this case some LAMMPS commands will
|
|
|
|
|
create a map to find atoms (and then destroy it), or require a
|
|
|
|
|
permanent map. An example of the former is the <A HREF = "velocity.html">velocity loop
|
|
|
|
|
all</A> command, which uses a map when looping over all
|
|
|
|
|
atoms and insuring the same velocity values are assigned to an atom
|
|
|
|
|
ID, no matter which processor owns it.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2008-02-16 03:09:18 +08:00
|
|
|
<P>The <I>first</I> keyword allows a <A HREF = "group.html">group</A> to be specified whose
|
|
|
|
|
atoms will be maintained as the first atoms in each processor's list
|
|
|
|
|
of owned atoms. This in only useful when the specified group is a
|
|
|
|
|
small fraction of all the atoms, and there are other operations LAMMPS
|
|
|
|
|
is performing that will be sped-up significantly by being able to loop
|
|
|
|
|
over the smaller set of atoms. Otherwise the reordering required by
|
|
|
|
|
this option will be a net slow-down. The <A HREF = "neigh_modify.html">neigh_modify
|
|
|
|
|
include</A> and <A HREF = "communicate.html">communicate group</A>
|
|
|
|
|
commands are two examples of commands that require this setting to
|
|
|
|
|
work efficiently. Several <A HREF = "fix.html">fixes</A>, most notably time
|
|
|
|
|
integration fixes like <A HREF = "fix_nve.html">fix nve</A>, also take advantage of
|
|
|
|
|
this setting if the group they operate on is the group specified by
|
2010-01-15 03:44:28 +08:00
|
|
|
this command. Note that specifying "all" as the group-ID effectively
|
|
|
|
|
turns off the <I>first</I> option.
|
2008-02-16 03:09:18 +08:00
|
|
|
</P>
|
2010-01-14 04:56:56 +08:00
|
|
|
<P>It is OK to use the <I>first</I> keyword with a group that has not yet been
|
2010-01-15 03:44:28 +08:00
|
|
|
defined, e.g. to use the atom_modify first command at the beginning of
|
|
|
|
|
your input script. LAMMPS does not use the group until a simullation
|
|
|
|
|
is run.
|
2010-01-14 04:56:56 +08:00
|
|
|
</P>
|
|
|
|
|
<P>The <I>sort</I> keyword turns on a spatial sorting or reordering of atoms
|
2010-03-26 00:23:56 +08:00
|
|
|
within each processor's sub-domain every <I>Nfreq</I> timesteps. If
|
|
|
|
|
<I>Nfreq</I> is set to 0, then sorting is turned off. Sorting can improve
|
|
|
|
|
cache performance and thus speed-up a LAMMPS simulation, as discussed
|
|
|
|
|
in a paper by <A HREF = "#Meloni">(Meloni)</A>. Its efficacy depends on the problem
|
|
|
|
|
size (atoms/processor), how quickly the system becomes disordered, and
|
|
|
|
|
various other factors. As a general rule, sorting is typically more
|
|
|
|
|
effective at speeding up simulations of liquids as opposed to solids.
|
|
|
|
|
In tests we have done, the speed-up can range from zero to 3-4x.
|
2010-01-14 04:56:56 +08:00
|
|
|
</P>
|
|
|
|
|
<P>Reordering is peformed every <I>Nfreq</I> timesteps during a dynamics run
|
|
|
|
|
or iterations during a minimization. More precisely, reordering
|
|
|
|
|
occurs at the first reneighboring that occurs after the target
|
|
|
|
|
timestep. The reordering is performed locally by each processor,
|
|
|
|
|
using bins of the specified <I>binsize</I>. If <I>binsize</I> is set to 0.0,
|
|
|
|
|
then a binsize equal to half the <A HREF = "neighbor.html">neighbor</A> cutoff
|
|
|
|
|
distance (force cutoff plus skin distance) is used, which is a
|
|
|
|
|
reasonable value. After the atoms have been binned, they are
|
|
|
|
|
reordered so that atoms in the same bin are adjacent to each other in
|
|
|
|
|
the processor's 1d list of atoms.
|
|
|
|
|
</P>
|
2010-01-19 00:14:51 +08:00
|
|
|
<P>The goal of this procedure is for atoms to put atoms close to each
|
|
|
|
|
other in the processor's one-dimensional list of atoms that are also
|
|
|
|
|
near to each other spatially. This can improve cache performance when
|
|
|
|
|
pairwise intereractions and neighbor lists are computed. Note that if
|
|
|
|
|
bins are too small, there will be few atoms/bin. Likewise if bins are
|
|
|
|
|
too large, there will be many atoms/bin. In both cases, the goal of
|
|
|
|
|
cache locality will be undermined.
|
2010-01-14 04:56:56 +08:00
|
|
|
</P>
|
|
|
|
|
<P>IMPORTANT NOTE: Running a simulation with sorting on versus off should
|
2010-01-19 00:14:51 +08:00
|
|
|
not change the simulation results in a statistical sense. However, a
|
|
|
|
|
different ordering will induce round-off differences, which will lead
|
|
|
|
|
to diverging trajectories over time when comparing two simluations.
|
|
|
|
|
Various commands, particularly those which use random numbers
|
|
|
|
|
(e.g. <A HREF = "velocity.html">velocity create</A>, and <A HREF = "fix_langevin.html">fix
|
|
|
|
|
langevin</A>), may generate (statistically identical)
|
|
|
|
|
results which depend on the order in which atoms are processed. The
|
|
|
|
|
order of atoms in a <A HREF = "dump.html">dump</A> file will also typically change
|
|
|
|
|
if sorting is enabled.
|
2008-02-16 03:09:18 +08:00
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<P><B>Restrictions:</B>
|
|
|
|
|
</P>
|
2010-01-14 04:57:58 +08:00
|
|
|
<P>The <I>first</I> and <I>sort</I> options cannot be used together. Since sorting
|
|
|
|
|
is on by default, it will be turned off if the <I>first</I> keyword is
|
2010-01-15 03:44:28 +08:00
|
|
|
used with a group-ID that is not "all".
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<P><B>Related commands:</B> none
|
|
|
|
|
</P>
|
|
|
|
|
<P><B>Default:</B>
|
|
|
|
|
</P>
|
2014-01-18 03:02:13 +08:00
|
|
|
<P>By default, <I>id</I> is yes. By default, atomic systems (no bond topology
|
|
|
|
|
info) do not use a map. For molecular systems (with bond topology
|
|
|
|
|
info), a map is used. The default map style is array if no atom ID is
|
|
|
|
|
larger than 1 million, otherwise the default is hash. By default, a
|
|
|
|
|
"first" group is not defined. By default, sorting is enabled with a
|
|
|
|
|
frequency of 1000 and a binsize of 0.0, which means the neighbor
|
2010-01-14 04:56:56 +08:00
|
|
|
cutoff will be used to set the bin size.
|
|
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<A NAME = "Meloni"></A>
|
|
|
|
|
|
2012-03-29 06:15:27 +08:00
|
|
|
<P><B>(Meloni)</B> Meloni, Rosati and Colombo, J Chem Phys, 126, 121102 (2007).
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
</HTML>
|
