forked from lijiext/lammps
295 lines
13 KiB
HTML
295 lines
13 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>prd command
|
|
</H3>
|
|
<P><B>Syntax:</B>
|
|
</P>
|
|
<PRE>prd N t_event n_dephase t_dephase t_correlate compute-ID seed keyword value ...
|
|
</PRE>
|
|
<UL><LI>N = # of timesteps to run (not including dephasing/quenching)
|
|
|
|
<LI>t_event = timestep interval between event checks
|
|
|
|
<LI>n_dephase = number of velocity randomizations to perform in each dephase run
|
|
|
|
<LI>t_dephase = number of timesteps to run dynamics after each velocity randomization during dephase
|
|
|
|
<LI>t_correlate = number of timesteps within which 2 consecutive events are considered to be correlated
|
|
|
|
<LI>compute-ID = ID of the compute used for event detection
|
|
|
|
<LI>random_seed = random # seed (positive integer)
|
|
|
|
<LI>zero or more keyword/value pairs may be appended
|
|
|
|
<LI>keyword = <I>min</I> or <I>temp</I> or <I>vel</I>
|
|
|
|
<PRE> <I>min</I> values = etol ftol maxiter maxeval
|
|
etol = stopping tolerance for energy, used in quenching
|
|
ftol = stopping tolerance for force, used in quenching
|
|
maxiter = max iterations of minimize, used in quenching
|
|
maxeval = max number of force/energy evaluations, used in quenching
|
|
<I>temp</I> value = Tdephase
|
|
Tdephase = target temperature for velocity randomization, used in dephasing
|
|
<I>vel</I> values = loop dist
|
|
loop = <I>all</I> or <I>local</I> or <I>geom</I>, used in dephasing
|
|
dist = <I>uniform</I> or <I>gaussian</I>, used in dephasing
|
|
</PRE>
|
|
|
|
</UL>
|
|
<P><B>Examples:</B>
|
|
</P>
|
|
<PRE>prd 5000 100 10 10 100 1 54982
|
|
prd 5000 100 10 10 100 1 54982 min 0.1 0.1 100 200
|
|
</PRE>
|
|
<P><B>Description:</B>
|
|
</P>
|
|
<P>Run Parallel Replica Dynamics (PRD) as described in <A HREF = "#Voter">this
|
|
paper</A> by Art Voter. PRD is a method for performing
|
|
accelerated dynamics that is suitable for infrequent-event systems
|
|
that obey first-order kinetics. A good overview of accelerated
|
|
dynamics methods for such systems in given in <A HREF = "#Voter2">this review
|
|
paper</A> from the same group. To quote from the paper: "The
|
|
dynamical evolution is characterized by vibrational excursions within
|
|
a potential basin, punctuated by occasional transitions between
|
|
basins." The transition probability is characterized by p(t) =
|
|
k*exp(-kt) where k is the rate constant.
|
|
</P>
|
|
<P>A PRD run is performed by running independent simulations on multiple
|
|
replicas of the same system, which gives an effective enhancement in
|
|
the timescale spanned by the multiple simulations, waiting for an
|
|
event to occur. To run with M replicas, you must launch LAMMPS on M
|
|
partitions, where a partition is one or more processors. This is done
|
|
by using the "-partition" command-line argument when LAMMPS is
|
|
launched. See <A HREF = "Section_start.html#2_6">this section</A> of the manual for
|
|
details. A PRD run can be performed on a single partition, though
|
|
this offers no effective parallel speed-up in searching for infrequent
|
|
events.
|
|
</P>
|
|
<P>When a PRD run is performed, it is assumed that each replica is
|
|
running the same model, though LAMMPS does not check for this.
|
|
I.e. the simulation domain, the number of atoms, the interaction
|
|
potentials, etc are the same for every replica.
|
|
</P>
|
|
<P>A PRD run has several stages, which are repeated each time an "event"
|
|
occurs in one of the replicas, as defined below. The logic for a PRD
|
|
run is as follows:
|
|
</P>
|
|
<PRE>while (time remains):
|
|
dephase for n_dephase*t_dephase steps
|
|
until (event occurs on some replica):
|
|
run dynamics for t_event steps
|
|
quench
|
|
check for uncorrelated event on any replica
|
|
until (no correlated event occurs):
|
|
run dynamics for t_correlate steps
|
|
quench
|
|
check for correlated event on this replica
|
|
event replica shares state with all replicas
|
|
</PRE>
|
|
<P>Before this loop begins, the state of the system on replica 0 is
|
|
shared with all replicas, so that all replicas begin from the same
|
|
initial state. The first potential energy basin is identified by
|
|
quenching (an energy minimization, see below) the initial state and
|
|
storing the resulting coordinates for reference.
|
|
</P>
|
|
<P>In the first stage, dephasing is performed by each replica
|
|
independently to eliminate correlations between replicas. This is
|
|
done by choosing a random set of velocities, based on the
|
|
<I>random_seed</I> that is specified, and running <I>t_dephase</I> timesteps of
|
|
dynamics. This is repeated <I>n_dephase</I> times. If the <I>temp</I> keyword
|
|
is not specified, the target temperature for velocity randomization
|
|
for each replica is the temperature at the timestep replication
|
|
occured, otherwise, it is the specified <I>Tdephase</I> temperature. The
|
|
style of velocity randomization is controlled using the keyword <I>vel</I>
|
|
with arguments that have the same meaning as their counterparts in the
|
|
<A HREF = "velocity.html">velocity</A> command.
|
|
</P>
|
|
<P>In the second stage, each replica runs dynamics continuously, stopping
|
|
every <I>t_event</I> steps to check if a transition event has occurred.
|
|
This check is performed by quenching the system and comparing the
|
|
resulting atom coordinates to the coordinates from the previous basin.
|
|
The first time through the PRD loop, the "previous basin" is the set
|
|
of quenched coordinates from the initial state of the system.
|
|
</P>
|
|
<P>A quench is an energy minimization and is performed by whichever
|
|
algorithm has been defined by the <A HREF = "min_style.html">min_style</A> command.
|
|
Minimization parameters may be set via the
|
|
<A HREF = "min_modify.html">min_modify</A> command and by the <I>min</I> keyword of the
|
|
PRD command. The latter are the settings that would be used with the
|
|
<A HREF = "minimize.html">minimize</A> command. Note that typically, you do not
|
|
need to perform a highly-converged minimization to detect a transition
|
|
event.
|
|
</P>
|
|
<P>The event check is performed by a compute with the specified
|
|
<I>compute-ID</I>. Currently there is only one compute that works with the
|
|
PRD commmand, which is the <A HREF = "compute_event_displace.html">compute
|
|
event/displace</A> command. Other
|
|
event-checking computes may be added. <A HREF = "compute_event_displace.html">Compute
|
|
event/displace</A> checks whether any atom in the
|
|
compute group has moved further than a specified threshold distance.
|
|
If so, an "event" has occurred.
|
|
</P>
|
|
<P>In the third stage, the replica on which the event occurred continues
|
|
to run dynamics to search for correlated events. This is done by
|
|
running dynamics for <I>t_correlate</I> steps, quenching every <I>t_event</I>
|
|
steps, and checking if another event has occurred. The first time no
|
|
correlated event occurs, the final state of the system is shared with
|
|
all replicas, the new basin reference coordinates are updated with the
|
|
quenched state, and the outer loop begins again.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>Four kinds of output can be generated during a PRD run: event
|
|
statistics, thermodynamic output by each replica, dump files, and
|
|
restart files.
|
|
</P>
|
|
<P>When running with multiple partitions (each of which is a replica in
|
|
this case), the print-out to the screen and master log.lammps file is
|
|
limited to event statistics. Note that if a PRD run is performed on
|
|
only a single replica then the event statistics will be intermixed
|
|
with the usual thermodynamic output discussed below.
|
|
</P>
|
|
<P>The quantities printed each time an event occurs are the timestep,
|
|
clock, event number, a correlation flag, and the replica number.
|
|
</P>
|
|
<P>The timestep is the usual LAMMPS timestep, except that time does not
|
|
advance during dephasing or quenches, but only during dynamics. Note
|
|
that are two kinds of dynamics in the PRD loop listed above. The
|
|
first is when all replicas are performing independent dynamics. The
|
|
second is when correlated events are being searched for and only one
|
|
replica is running dynamics.
|
|
</P>
|
|
<P>The clock is the same as the timestep except that it advances by M
|
|
steps every timestep during the first kind of dynamics when the M
|
|
replicas are running independently. The clock represents the real
|
|
time that effectively elapses during a PRD simulation of <I>N</I> steps on
|
|
M replicas. If most of the PRD run is spent in the second stage of
|
|
the loop above, searching for infrequent events, then the clock will
|
|
advance nearly N*M steps. Note the clock time between events will be
|
|
drawn from p(t).
|
|
</P>
|
|
<P>The event number is a counter that increments with each event, whether
|
|
it is uncorrelated or correlated.
|
|
</P>
|
|
<P>The correlation flag will be 0 when an uncorrelated event occurs
|
|
during the second stage of the loop listed above. I.e. when all
|
|
replicas are running independently. The correlation flag will be 1
|
|
when a correlated event occurs during the third stage of the loop
|
|
listed above. I.e. when only one replica is running dynamics.
|
|
</P>
|
|
<P>The replica number is the ID of the replica (from 0 to M-1) that
|
|
found the event.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>When running on multiple partitions, LAMMPS produces additional log
|
|
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
|
|
the PRD command, these contain the thermodynamic output for each
|
|
replica. You will see short runs and minimizations corresponding to
|
|
the dynamics and quench operations of the loop listed above. The
|
|
timestep will be reset aprpopriately depending on whether the
|
|
operation advances time or not.
|
|
</P>
|
|
<P>After the PRD command completes, timing statistics for the PRD run are
|
|
printed in each replica's log file, giving a breakdown of how much CPU
|
|
time was spent in each stage (dephasing, dynamics, quenching, etc).
|
|
</P>
|
|
<HR>
|
|
|
|
<P>Any <A HREF = "dump.html">dump files</A> defined in the input script, will be
|
|
written to during a PRD run at timesteps corresponding to both
|
|
uncorrelated and correlated events. This means the the requested dump
|
|
frequency in the <A HREF = "dump.html">dump</A> command is ignored. There will be
|
|
one dump file (per dump command) created for all partitions.
|
|
</P>
|
|
<P>The atom coordinates of the dump snapshot are those of the minimum
|
|
energy configuration resulting from quenching following a transition
|
|
event. The timesteps written into the dump files correspond to the
|
|
timestep at which the event occurred and NOT the clock. A dump
|
|
snapshot corresponding to the initial minimum state used for event
|
|
detection is written to the dump file at the beginning of each PRD
|
|
run.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>If the <A HREF = "restart.html">restart</A> command is used, a single restart file
|
|
for all the partitions is generated, which allows a PRD run to be
|
|
continued by a new input script in the usual manner.
|
|
</P>
|
|
<P>The restart file is generated at the end of the loop listed above. If
|
|
no correlated events are found, this means it contains a snapshot of
|
|
the system at time T + <I>t_correlate</I>, where T is the time at which the
|
|
uncorrelated event occurred. If correlated events were found, then it
|
|
contains a snapshot of the system at time T + <I>t_correlate</I>, where T
|
|
is the time of the last correlated event.
|
|
</P>
|
|
<P>The restart frequency specified in the <A HREF = "restart.html">restart</A> command
|
|
is interpreted differently when performing a PRD run. It does not
|
|
mean the timestep interval between restart files. Instead it means an
|
|
event interval for uncorrelated events. Thus a frequency of 1 means
|
|
write a restart file every time an uncorrelated event occurs. A
|
|
frequency of 10 means write a restart file every 10th uncorrelated
|
|
event.
|
|
</P>
|
|
<P>When an input script reads a restart file from a previous PRD run, the
|
|
new script can be run on a different number of replicas or processors.
|
|
However, it is assumed that <I>t_correlate</I> in the new PRD command is
|
|
the same as it was previously. If not, the calculation of the "clock"
|
|
value for the first event in the new run will be slightly off.
|
|
</P>
|
|
<HR>
|
|
|
|
<P><B>Restrictions:</B>
|
|
</P>
|
|
<P>This command can only be used if LAMMPS was built with the "prd"
|
|
package. See the <A HREF = "Section_start.html#2_3">Making LAMMPS</A> section for
|
|
more info on packages.
|
|
</P>
|
|
<P><I>N</I> and <I>t_correlate</I> settings must be integer multiples of
|
|
<I>t_event</I>.
|
|
</P>
|
|
<P>Runs restarted from restart file written during a PRD run will not
|
|
produce identical results due to changes in the random numbers used
|
|
for dephasing.
|
|
</P>
|
|
<P>This command cannot be used when any fixes are defined that keep track
|
|
of elapsed time to perform time-dependent operations. Examples
|
|
include the "ave" fixes such as <A HREF = "fix_ave_spatial.html">fix
|
|
ave/spatial</A>. Also <A HREF = "fix_dt_reset.html">fix
|
|
dt/reset</A> and <A HREF = "fix_deposity.html">fix deposit</A>.
|
|
</P>
|
|
<P><B>Related commands:</B>
|
|
</P>
|
|
<P><A HREF = "compute_event_displace.html">compute event/displace</A>,
|
|
<A HREF = "min_modify.html">min_modify</A>, <A HREF = "min_style.html">min_style</A>,
|
|
<A HREF = "run_style.html">run_style</A>, <A HREF = "minimize.html">minimize</A>,
|
|
<A HREF = "velocity.html">velocity</A>
|
|
</P>
|
|
<P><B>Default:</B>
|
|
</P>
|
|
<P>The option defaults are <I>min</I> = 40 50 0.1 0.1, no <I>temp</I> setting, and
|
|
<I>vel</I> = <I>geom</I> <I>gaussian</I>.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "Voter"></A>
|
|
|
|
<P><B>(Voter)</B> Voter, Phys Rev B, 57, 13985 (1998).
|
|
</P>
|
|
<A NAME = "Voter2"></A>
|
|
|
|
<P><B>(Voter2)</B> Voter, Montalenti, Germann, Annual Review of Materials
|
|
Research 32, 321 (2002).
|
|
</P>
|
|
</HTML>
|