diff --git a/doc/prd.html b/doc/prd.html
index 6dc352508..00ae46641 100644
--- a/doc/prd.html
+++ b/doc/prd.html
@@ -1,281 +1,284 @@
<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 maxiter 100
</PRE>
<P><B>Description:</B>
</P>
-<P>Run Parallel Replica Dynamics (PRD) as described in <A HREF = "#Voter">(Voter)</A>.
-PRD is a method for performing accelerated dynamics that is suitable
-for infrequent-event systems that obey first-order kinetics. 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>Run Parallel Replica Dynamics (PRD) as described in <A HREF = "#Voter">Art Voter's
+paper</A>. PRD is a method for performing accelerated dynamics
+that is suitable for infrequent-event systems that obey first-order
+kinetics. 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. 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.
+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 that this is the
-case. I.e. the simulation domain, the number of atoms, the
-interaction potentials, etc are the same for every replica.
+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 basin is identified by quenching (an energy
-minimization, see below) the initial state and storing the resulting
-coordinates for reference.
+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">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><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, Montalenti, Germann, Annual Review of Materials
Research 32, 321 (2002).
</P>
</HTML>
diff --git a/doc/prd.txt b/doc/prd.txt
index 854bad2d9..f80282d2c 100644
--- a/doc/prd.txt
+++ b/doc/prd.txt
@@ -1,265 +1,268 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
prd command :h3
[Syntax:]
prd N t_event n_dephase t_dephase t_correlate compute-ID seed keyword value ... :pre
N = # of timesteps to run (not including dephasing/quenching) :ulb,l
t_event = timestep interval between event checks :l
n_dephase = number of velocity randomizations to perform in each dephase run :l
t_dephase = number of timesteps to run dynamics after each velocity randomization during dephase :l
t_correlate = number of timesteps within which 2 consecutive events are considered to be correlated :l
compute-ID = ID of the compute used for event detection :l
random_seed = random # seed (positive integer) :l
zero or more keyword/value pairs may be appended :l
keyword = {min} or {temp} or {vel} :l
{min} 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
{temp} value = Tdephase
Tdephase = target temperature for velocity randomization, used in dephasing
{vel} values = loop dist
loop = {all} or {local} or {geom}, used in dephasing
dist = {uniform} or {gaussian}, used in dephasing :pre
:ule
[Examples:]
prd 5000 100 10 10 100 1 54982
prd 5000 100 10 10 100 1 54982 maxiter 100 :pre
[Description:]
-Run Parallel Replica Dynamics (PRD) as described in "(Voter)"_#Voter.
-PRD is a method for performing accelerated dynamics that is suitable
-for infrequent-event systems that obey first-order kinetics. 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.
+Run Parallel Replica Dynamics (PRD) as described in "Art Voter's
+paper"_#Voter. PRD is a method for performing accelerated dynamics
+that is suitable for infrequent-event systems that obey first-order
+kinetics. 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.
A PRD run is performed by running independent simulations on multiple
-replicas of the same system. 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 "this section"_Section_start.html#2_6 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.
+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 "this section"_Section_start.html#2_6 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.
When a PRD run is performed, it is assumed that each replica is
-running the same model, though LAMMPS does not check that this is the
-case. I.e. the simulation domain, the number of atoms, the
-interaction potentials, etc are the same for every replica.
+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.
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:
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
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 basin is identified by quenching (an energy
-minimization, see below) the initial state and storing the resulting
-coordinates for reference.
+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.
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
{random_seed} that is specified, and running {t_dephase} timesteps of
dynamics. This is repeated {n_dephase} times. If the {temp} 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 {Tdephase} temperature. The
style of velocity randomization is controlled using the keyword {vel}
with arguments that have the same meaning as their counterparts in the
"velocity"_velocity.html command.
In the second stage, each replica runs dynamics continuously, stopping
every {t_event} 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.
A quench is an energy minimization and is performed by whichever
algorithm has been defined by the "min_style"_min_style.html command.
Minimization parameters may be set via the
"min_modify"_min_modify.html command and by the {min} keyword of the
PRD command. The latter are the settings that would be used with the
"minimize"_minimize.html command. Note that typically, you do not
need to perform a highly-converged minimization to detect a transition
event.
The event check is performed by a compute with the specified
{compute-ID}. Currently there is only one compute that works with the
PRD commmand, which is the "compute
event/displace"_compute_event_displace.html command. Other
event-checking computes may be added. "Compute
event/displace"_compute_event_displace checks whether any atom in the
compute group has moved further than a specified threshold distance.
If so, an "event" has occurred.
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 {t_correlate} steps, quenching every {t_event}
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.
:line
Four kinds of output can be generated during a PRD run: event
statistics, thermodynamic output by each replica, dump files, and
restart files.
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.
The quantities printed each time an event occurs are the timestep,
clock, event number, a correlation flag, and the replica number.
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.
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 {N} 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).
The event number is a counter that increments with each event, whether
it is uncorrelated or correlated.
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.
The replica number is the ID of the replica (from 0 to M-1) that
found the event.
:line
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.
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).
:line
Any "dump files"_dump.html 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 "dump"_dump.html command is ignored. There will be
one dump file (per dump command) created for all partitions.
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.
:line
If the "restart"_restart.html 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.
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 + {t_correlate}, 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 + {t_correlate}, where T
is the time of the last correlated event.
The restart frequency specified in the "restart"_restart.html 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.
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 {t_correlate} 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.
:line
[Restrictions:]
{N} and {t_correlate} settings must be integer multiples of
{t_event}.
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.
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 "fix
ave/spatial"_fix_ave_spatial.html. Also "fix
dt/reset"_fix_dt_reset.html and "fix deposit"_fix_deposity.html.
[Related commands:]
"compute event/displace"_compute_event_displace.html,
"min_modify"_min_modify.html, "min_style"_min_style.html,
"run_style"_run_style.html, "minimize"_minimize.html,
"velocity"_velocity.html
[Default:]
The option defaults are {min} = 40 50 0.1 0.1, no {temp} setting, and
{vel} = {geom} {gaussian}.
:line
:link(Voter)
[(Voter)] Voter, Montalenti, Germann, Annual Review of Materials
Research 32, 321 (2002).