2009-10-30 06:41:53 +08:00
|
|
|
<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>
|
2009-10-31 02:13:57 +08:00
|
|
|
<PRE>prd N t_event n_dephase t_dephase t_correlate compute-ID seed keyword value ...
|
2009-10-30 06:41:53 +08:00
|
|
|
</PRE>
|
2009-10-31 02:13:57 +08:00
|
|
|
<UL><LI>N = # of timesteps to run (not including dephasing/quenching)
|
2009-10-30 06:41:53 +08:00
|
|
|
|
|
|
|
|
<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
|
|
|
|
|
|
2009-10-31 02:13:57 +08:00
|
|
|
<LI>t_correlate = number of timesteps within which 2 consecutive events are considered to be correlated
|
2009-10-30 06:41:53 +08:00
|
|
|
|
2009-10-31 02:13:57 +08:00
|
|
|
<LI>compute-ID = ID of the compute used for event detection
|
2009-10-30 06:41:53 +08:00
|
|
|
|
|
|
|
|
<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
|
2010-01-29 05:25:54 +08:00
|
|
|
prd 5000 100 10 10 100 1 54982 min 0.1 0.1 100 200
|
2009-10-30 06:41:53 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P><B>Description:</B>
|
|
|
|
|
</P>
|
2010-10-01 04:38:58 +08:00
|
|
|
<P>Run a parallel replica dynamics (PRD) simulation using multiple
|
|
|
|
|
replicas of a system. One or more replicas can be used.
|
|
|
|
|
</P>
|
|
|
|
|
<P>PRD is described in <A HREF = "#Voter">this paper</A> by Art Voter. It 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.
|
|
|
|
|
Running multiple replicas gives an effective enhancement in the
|
|
|
|
|
timescale spanned by the multiple simulations, while waiting for an
|
|
|
|
|
event to occur.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Each replica runs on a partition of one or more processors. Processor
|
|
|
|
|
partitions are defined at run-time using the -partition command-line
|
2011-08-26 00:46:23 +08:00
|
|
|
switch; see <A HREF = "Section_start.html#start_6">this section</A> of the manual.
|
|
|
|
|
Note that if you have MPI installed, you can run a multi-replica
|
|
|
|
|
simulation with more replicas (partitions) than you have physical
|
|
|
|
|
processors, e.g you can run a 10-replica simulation on one or two
|
|
|
|
|
processors. For PRD, this makes little sense, since this offers no
|
|
|
|
|
effective parallel speed-up in searching for infrequent events. See
|
2011-08-26 01:01:01 +08:00
|
|
|
<A HREF = "Section_howto.html#howto_5">this section</A> of the manual for further
|
2011-08-26 00:46:23 +08:00
|
|
|
discussion.
|
2010-10-01 04:38:58 +08:00
|
|
|
</P>
|
|
|
|
|
<P>When a PRD simulation is performed, it is assumed that each replica is
|
2009-11-03 01:38:32 +08:00
|
|
|
running the same model, though LAMMPS does not check for this.
|
|
|
|
|
I.e. the simulation domain, the number of atoms, the interaction
|
2010-10-01 04:38:58 +08:00
|
|
|
potentials, etc should be the same for every replica.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2009-10-31 02:26:17 +08:00
|
|
|
check for uncorrelated event on any replica
|
|
|
|
|
until (no correlated event occurs):
|
2009-10-31 02:13:57 +08:00
|
|
|
run dynamics for t_correlate steps
|
|
|
|
|
quench
|
2009-10-31 02:26:17 +08:00
|
|
|
check for correlated event on this replica
|
|
|
|
|
event replica shares state with all replicas
|
2009-10-31 02:13:57 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P>Before this loop begins, the state of the system on replica 0 is
|
2009-10-31 03:28:00 +08:00
|
|
|
shared with all replicas, so that all replicas begin from the same
|
2009-11-03 01:38:32 +08:00
|
|
|
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.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2010-02-09 06:34:21 +08:00
|
|
|
for each replica is the current temperature of that replica.
|
|
|
|
|
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
|
2009-10-31 02:13:57 +08:00
|
|
|
<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
|
2009-10-31 03:28:00 +08:00
|
|
|
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.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2009-10-31 03:28:00 +08:00
|
|
|
<A HREF = "minimize.html">minimize</A> command. Note that typically, you do not
|
2009-10-31 02:13:57 +08:00
|
|
|
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
|
2010-01-29 03:48:57 +08:00
|
|
|
event-checking computes may be added. <A HREF = "compute_event_displace.html">Compute
|
2010-02-09 06:34:21 +08:00
|
|
|
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 (event
|
|
|
|
|
replica) 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
|
|
|
|
|
event replica is shared with all replicas, the new basin reference
|
|
|
|
|
coordinates are updated with the quenched state, and the outer loop
|
|
|
|
|
begins again. While the replica event is searching for correlated
|
|
|
|
|
events, all the other replicas also run dynamics and event checking
|
|
|
|
|
with the same schedule, but the final states are always overwritten by
|
|
|
|
|
the state of the event replica.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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,
|
2010-02-09 06:34:21 +08:00
|
|
|
CPU time, clock, event number, a correlation flag,
|
|
|
|
|
the number of coincident events, and the replica number of the chosen event.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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>
|
2010-02-09 06:34:21 +08:00
|
|
|
<P>The CPU time is the total processor time since the start of the PRD
|
|
|
|
|
run.
|
|
|
|
|
</P>
|
2009-10-31 02:13:57 +08:00
|
|
|
<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
|
2009-10-31 03:28:00 +08:00
|
|
|
advance nearly N*M steps. Note the clock time between events will be
|
|
|
|
|
drawn from p(t).
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2010-02-09 06:34:21 +08:00
|
|
|
during the second stage of the loop listed above, i.e. when all
|
2009-10-31 02:13:57 +08:00
|
|
|
replicas are running independently. The correlation flag will be 1
|
|
|
|
|
when a correlated event occurs during the third stage of the loop
|
2010-02-09 06:34:21 +08:00
|
|
|
listed above, i.e. when only one replica is running dynamics.
|
|
|
|
|
</P>
|
|
|
|
|
<P>When more than one replica detects an event at the end of the second
|
|
|
|
|
stage, then one of them is chosen at random. The number of coincident
|
|
|
|
|
events is the number of replicas that detected an event. Normally, we
|
|
|
|
|
expect this value to be 1. If it is often greater than 1, then either
|
|
|
|
|
the number of replicas is too large, or <I>t_event</I> is too large.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2009-10-30 06:41:53 +08:00
|
|
|
run.
|
|
|
|
|
</P>
|
2009-10-31 02:13:57 +08:00
|
|
|
<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
|
2009-10-31 03:28:00 +08:00
|
|
|
is the time of the last correlated event.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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
|
2009-10-31 03:28:00 +08:00
|
|
|
write a restart file every time an uncorrelated event occurs. A
|
|
|
|
|
frequency of 10 means write a restart file every 10th uncorrelated
|
|
|
|
|
event.
|
2009-10-31 02:13:57 +08:00
|
|
|
</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.
|
2009-10-30 06:41:53 +08:00
|
|
|
</P>
|
2009-10-31 02:26:17 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2009-10-30 06:41:53 +08:00
|
|
|
<P><B>Restrictions:</B>
|
|
|
|
|
</P>
|
2010-10-01 04:38:58 +08:00
|
|
|
<P>This command can only be used if LAMMPS was built with the "replica"
|
2011-08-26 00:46:23 +08:00
|
|
|
package. See the <A HREF = "Section_start.html#start_3">Making LAMMPS</A> section
|
|
|
|
|
for more info on packages.
|
2009-11-03 01:41:54 +08:00
|
|
|
</P>
|
2009-10-31 02:26:17 +08:00
|
|
|
<P><I>N</I> and <I>t_correlate</I> settings must be integer multiples of
|
2009-10-30 06:41:53 +08:00
|
|
|
<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
|
2010-05-07 23:11:21 +08:00
|
|
|
dt/reset</A> and <A HREF = "fix_deposit.html">fix deposit</A>.
|
2009-10-30 06:41:53 +08:00
|
|
|
</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>,
|
2011-01-05 07:39:13 +08:00
|
|
|
<A HREF = "velocity.html">velocity</A>, <A HREF = "temper.html">temper</A>, <A HREF = "neb.html">neb</A>,
|
|
|
|
|
<A HREF = "tad.html">tad</A>
|
2009-10-30 06:41:53 +08:00
|
|
|
</P>
|
|
|
|
|
<P><B>Default:</B>
|
|
|
|
|
</P>
|
2010-02-09 06:34:21 +08:00
|
|
|
<P>The option defaults are <I>min</I> = 0.1 0.1 40 50, no <I>temp</I> setting, and
|
2009-10-30 06:41:53 +08:00
|
|
|
<I>vel</I> = <I>geom</I> <I>gaussian</I>.
|
|
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<A NAME = "Voter"></A>
|
|
|
|
|
|
2009-11-03 23:06:46 +08:00
|
|
|
<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
|
2009-10-30 06:41:53 +08:00
|
|
|
Research 32, 321 (2002).
|
|
|
|
|
</P>
|
|
|
|
|
</HTML>
|
