diff --git a/doc/tad.html b/doc/tad.html
index d45fff1a64..e748692625 100644
--- a/doc/tad.html
+++ b/doc/tad.html
@@ -62,60 +62,51 @@ tad 2000 50 1800 2300 0.01 0.01 event 54985 &
Description:
-Run a temperature accelerated dynamics (TAD) simulation. This
-method requires two or more partitions to perform NEB transition
-state searches.
+
Run a temperature accelerated dynamics (TAD) simulation. This method
+requires two or more partitions to perform NEB transition state
+searches.
TAD is described in this paper by Art Voter. It is a method
-that uses accelerated dynamics at an elevated temperature to
-generate results at a specified lower temperature.
-A good
-overview of accelerated dynamics methods for such systems is given in
-this review paper from the same group. In general, these methods assume
-that the long-time dynamics is dominated by infrequent events i.e. the system is
-is confined to low energy basins for long periods,
-punctuated by brief, randomly-occurring transitions to adjacent basins.
-TAD is suitable for
-infrequent-event systems, where in addition, the transition
-kinetics are well-approximated
-by harmonic transition state theory (hTST). In hTST, the temperature
-dependence of transition rates follows the Arrhenius relation.
-As a consequence a set of event times generated in a high-temperature
-simulation can be mapped to a set of much longer estimated times
-in the low-temperature system. However, because this mapping involves
-the energy barrier of the transition event, which is different for each event,
-the first event at the high temperature may not be the earliest event at the
-low temperature. TAD handles this by first generating
-a set of possible events from the current basin. After each event,
-the simulation is reflected backwards into the current basin.
-This is repeated until the stopping criterion is satisfied,
-at which point the event with the earliest
-low-temperature occurrence time is selected.
-The stopping criterion is that the confidence measure
-be greater than 1-delta. The confidence measure is
-the probability that no earlier low-temperature
-event will occur at some later time
-in the high-temperature simulation.
-hTST provides an lower bound for this probability,
-based on the user-specified minimum pre-exponential
+that uses accelerated dynamics at an elevated temperature to generate
+results at a specified lower temperature. A good overview of
+accelerated dynamics methods for such systems is given in this review
+paper from the same group. In general, these methods assume
+that the long-time dynamics is dominated by infrequent events i.e. the
+system is is confined to low energy basins for long periods,
+punctuated by brief, randomly-occurring transitions to adjacent
+basins. TAD is suitable for infrequent-event systems, where in
+addition, the transition kinetics are well-approximated by harmonic
+transition state theory (hTST). In hTST, the temperature dependence of
+transition rates follows the Arrhenius relation. As a consequence a
+set of event times generated in a high-temperature simulation can be
+mapped to a set of much longer estimated times in the low-temperature
+system. However, because this mapping involves the energy barrier of
+the transition event, which is different for each event, the first
+event at the high temperature may not be the earliest event at the low
+temperature. TAD handles this by first generating a set of possible
+events from the current basin. After each event, the simulation is
+reflected backwards into the current basin. This is repeated until
+the stopping criterion is satisfied, at which point the event with the
+earliest low-temperature occurrence time is selected. The stopping
+criterion is that the confidence measure be greater than
+1-delta. The confidence measure is the probability that no earlier
+low-temperature event will occur at some later time in the
+high-temperature simulation. hTST provides an lower bound for this
+probability, based on the user-specified minimum pre-exponential
factor (reciprocal of tmax).
-In order to estimate the energy barrier for each event, the
-TAD method invokes the NEB method. Each NEB
-replica runs on a partition of processors. The current
-NEB implementation in LAMMPS restricts you to having
-exactly one processor per replica. For more information,
-see the documentation for the neb command.
-In the current LAMMPS implementation of TAD, all the non-NEB
-TAD operations are performed on the first partition, while the
-other partitions remain idle. Processor partitions are
-defined at run-time using the -partition command-line
-switch.
+
In order to estimate the energy barrier for each event, the TAD method
+invokes the NEB method. Each NEB replica runs on a
+partition of processors. The current NEB implementation in LAMMPS
+restricts you to having exactly one processor per replica. For more
+information, see the documentation for the neb command. In
+the current LAMMPS implementation of TAD, all the non-NEB TAD
+operations are performed on the first partition, while the other
+partitions remain idle. Processor partitions are defined at run-time
+using the -partition command-line switch.
-A TAD run has several stages,
-which are repeated each time an event
-is performed. The logic for a TAD
-run is as follows:
+
A TAD run has several stages, which are repeated each time an event is
+performed. The logic for a TAD run is as follows:
while (time remains):
while (time < tstop):
@@ -129,22 +120,20 @@ run is as follows:
reflect back into current basin
perform earliest event
-Before this outer loop begins,
-the initial potential energy basin is identified by
-quenching (an energy minimization, see below) the initial state and
-storing the resulting coordinates for reference.
+
Before this outer loop begins, the initial potential energy basin is
+identified by quenching (an energy minimization, see below) the
+initial state and storing the resulting coordinates for reference.
Inside the inner loop, dynamics is run continuously according to
-whatever integrator has been specified by the user, 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.
+whatever integrator has been specified by the user, 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.
A quench is an energy minimization and is performed by whichever
-algorithm has been defined by the min and min_style keywords or
-their default values. Note that typically, you do not
-need to perform a highly-converged minimization to detect a transition
-event.
+algorithm has been defined by the min and min_style keywords or
+their default values. 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
@@ -155,142 +144,134 @@ event/displace checks whether any atom in
the compute group has moved further than a specified threshold
distance. If so, an "event" has occurred.
-The neb calculation is similar to that invoked by the neb command,
-except that the final state is generated internally, instead of being read
-in from a file. The TAD implementation provides default values
-for the NEB settings, which can be overridden using the neb and neb_style
-keywords.
+
The neb calculation is similar to that invoked by the neb
+command, except that the final state is generated internally, instead
+of being read in from a file. The TAD implementation provides default
+values for the NEB settings, which can be overridden using the neb
+and neb_style keywords.
-A key aspect of the TAD method is setting the stopping criterion appropriately.
-If this criterion is
-too conservative, then many events must be generated before one is finally performed.
-Conversely, if this criterion is too aggressive, high-entropy high-barrier events will
-be over-sampled, while low-entropy low-barrier events will be under-sampled. If the lowest
-pre-exponential factor is known fairly accurately, then it can be used to estimate tmax,
-and the value of delta can be set to the desired confidence level e.g. delta = 0.05
-corresponds to 95% confidence. However, for systems where the dynamics are not well
-characterized (the most common case), it will be necessary to experiment with the values
-of delta and tmax to get a good trade-off between accuracy and performance. To aid
-with this, for each new event that is detected, a line is printed to the
-screen and log output for the first partition, as follows:
+
A key aspect of the TAD method is setting the stopping criterion
+appropriately. If this criterion is too conservative, then many
+events must be generated before one is finally performed. Conversely,
+if this criterion is too aggressive, high-entropy high-barrier events
+will be over-sampled, while low-entropy low-barrier events will be
+under-sampled. If the lowest pre-exponential factor is known fairly
+accurately, then it can be used to estimate tmax, and the value of
+delta can be set to the desired confidence level e.g. delta = 0.05
+corresponds to 95% confidence. However, for systems where the dynamics
+are not well characterized (the most common case), it will be
+necessary to experiment with the values of delta and tmax to get a
+good trade-off between accuracy and performance. To aid with this, for
+each new event that is detected, a line is printed to the screen and
+log output for the first partition, as follows:
New event: t_hi = 1950 ievent = 2 eb = 2.97066 dt_lo = 114049 dt_hi/t_stop = 0.610293
-t_hi is the timestep on which the event occurrred.
-ievent is the event index, zero for the first event in each basin.
-eb is the energy barrier for the event.
-dt_lo is the low-temperature time since entering the basin.
-dt_hi/t_stop is a measure of how close the stopping criterion is to
-being met (if > 1.0, then the criterion is met).
+
t_hi is the timestep on which the event occurrred. ievent is the
+event index, zero for the first event in each basin. eb is the
+energy barrier for the event. dt_lo is the low-temperature time
+since entering the basin. dt_hi/t_stop is a measure of how close
+the stopping criterion is to being met (if > 1.0, then the criterion
+is met).
-A second key aspect is the choice of t_hi. A larger value greatly increases
-the rate at which new events are generated.
-However, too large a value introduces errors due to anharmonicity (not accounted
-for within hTST). Once again, for any given system, experimentation is necessary
-to determine the best value of t_hi.
+
A second key aspect is the choice of t_hi. A larger value greatly
+increases the rate at which new events are generated. However, too
+large a value introduces errors due to anharmonicity (not accounted
+for within hTST). Once again, for any given system, experimentation is
+necessary to determine the best value of t_hi.
Five kinds of output can be generated during a TAD run: event
-statistics, NEB statistics, thermodynamic output by each replica,
-dump files, and restart files.
+statistics, NEB statistics, thermodynamic output by each replica, dump
+files, and restart files.
-Event statistics are printed to the screen and master log.lammps
-file each time an event is performed. The quantities are the timestep,
-CPU time, clock, and event number.
-The timestep is the usual LAMMPS
-timestep, which corresponds to
-the high-temperature time at which the event was detected,
-in units of timestep.
-The CPU time is the total processor
-time since the start of the TAD run.
-The clock is the low-temperature
-event time, in units of timestep.
-Each clock interval is equal to the timestep interval
-between events scaled by an exponential factor that depends on
-the hi/lo temperature ratio and the energy barrier for that event.
-The event number is a counter that increments with each performed
-event.
+
Event statistics are printed to the screen and master log.lammps file
+each time an event is performed. The quantities are the timestep, CPU
+time, clock, and event number. The timestep is the usual LAMMPS
+timestep, which corresponds to the high-temperature time at which the
+event was detected, in units of timestep. The CPU time is the total
+processor time since the start of the TAD run. The clock is the
+low-temperature event time, in units of timestep. Each clock interval
+is equal to the timestep interval between events scaled by an
+exponential factor that depends on the hi/lo temperature ratio and the
+energy barrier for that event. The event number is a counter that
+increments with each performed event.
-The NEB statistics are written to the file specified
-by the neb_log keyword. If the keyword value is "none",
-then no NEB statistics are printed out. The statistics
-are written every Nevery timesteps.
-See the neb command for a full description of
-the NEB statistics. When invoked from TAD, NEB statistics are
-never printed to the screen.
+
The NEB statistics are written to the file specified by the neb_log
+keyword. If the keyword value is "none", then no NEB statistics are
+printed out. The statistics are written every Nevery timesteps. See
+the neb command for a full description of the NEB
+statistics. When invoked from TAD, NEB statistics are never printed to
+the screen.
-Because the NEB calculation must run on multiple partitions,
-LAMMPS produces additional screen and log
-files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
-the TAD command, these contain the thermodynamic output of each
-NEB replica. In addition, the log file for the first partition,
-log.lammps.0, will contain thermodynamic output from short runs and
-minimizations corresponding to the dynamics and quench operations, as
-well as a line for each new detected event, as described above.
+
Because the NEB calculation must run on multiple partitions, LAMMPS
+produces additional screen and log files for each partition,
+e.g. log.lammps.0, log.lammps.1, etc. For the TAD command, these
+contain the thermodynamic output of each NEB replica. In addition, the
+log file for the first partition, log.lammps.0, will contain
+thermodynamic output from short runs and minimizations corresponding
+to the dynamics and quench operations, as well as a line for each new
+detected event, as described above.
After the TAD command completes, timing statistics for the TAD run are
printed in each replica's log file, giving a breakdown of how much CPU
time was spent in each stage (NEB, dynamics, quenching, etc).
-Any dump files defined in the input script will be
-written to during a TAD run at timesteps when an event
-is performed. This means the the requested dump
-frequency in the dump 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 the
-performed 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 TAD
-run.
+
Any dump files defined in the input script will be written
+to during a TAD run at timesteps when an event is performed. This
+means the the requested dump frequency in the dump 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 the performed 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 TAD run.
If the restart command is used, a single restart file
for all the partitions is generated, which allows a TAD run to be
-continued by a new input script in the usual manner.
-The restart file is generated after an event is performed. The restart
-file contains a snapshot of the system in the new quenched state,
-including the event number and the low-temperature time.
-The restart frequency specified in the restart command
-is interpreted differently when performing a TAD run. It does not
-mean the timestep interval between restart files. Instead it means an
-event interval for performed events. Thus a frequency of 1 means
-write a restart file every time an event is performed. A
-frequency of 10 means write a restart file every 10th performed
-event.
-When an input script reads a restart file from a previous TAD run, the
-new script can be run on a different number of replicas or processors.
+continued by a new input script in the usual manner. The restart file
+is generated after an event is performed. The restart file contains a
+snapshot of the system in the new quenched state, including the event
+number and the low-temperature time. The restart frequency specified
+in the restart command is interpreted differently when
+performing a TAD run. It does not mean the timestep interval between
+restart files. Instead it means an event interval for performed
+events. Thus a frequency of 1 means write a restart file every time
+an event is performed. A frequency of 10 means write a restart file
+every 10th performed event. When an input script reads a restart file
+from a previous TAD run, the new script can be run on a different
+number of replicas or processors.
Note that within a single state, the dynamics will typically
temporarily continue beyond the event that is ultimately chosen, until
-the stopping criterionis satisfied.
-When the event is eventually performed,
-the timestep counter is reset to the
-value when the event was detected. Similarly, after each quench
-and NEB minimization,
-the timestep counter is reset to the value at the start of the
+the stopping criterionis satisfied. When the event is eventually
+performed, the timestep counter is reset to the value when the event
+was detected. Similarly, after each quench and NEB minimization, the
+timestep counter is reset to the value at the start of the
minimization. This means that the timesteps listed in the replica log
-files do not always increase monotonically. However,
-the timestep values printed to the master log file, dump files, and
-restart files are always monotonically increasing.
+files do not always increase monotonically. However, the timestep
+values printed to the master log file, dump files, and restart files
+are always monotonically increasing.
+
+
Restrictions:
This command can only be used if LAMMPS was built with the "replica"
package. See the Making LAMMPS section for
more info on packages.
-N setting must be integer multiple of
-t_event.
+
N setting must be integer multiple of t_event.
Runs restarted from restart files written during a TAD run will only
-produce identical results if the user-specified integrator
-supports exact restarts. So fix nvt will produce an exact restart,
-but fix langevin will not.
+produce identical results if the user-specified integrator supports
+exact restarts. So fix nvt will produce an exact
+restart, but fix langevin will not.
This command cannot be used when any fixes are defined that keep track
of elapsed time to perform time-dependent operations. Examples
@@ -308,9 +289,9 @@ dt/reset and fix deposit.
Default:
-The option defaults are min = 0.1 0.1 40 50, neb = 0.01 100 100 10,
-min_style = cg, neb_style = quickmin,
-and neb_log = "none"
+
The option defaults are min = 0.1 0.1 40 50, neb = 0.01 100 100
+10, min_style = cg, neb_style = quickmin, and neb_log =
+"none"
diff --git a/doc/tad.txt b/doc/tad.txt
index b694a14859..7c55377841 100644
--- a/doc/tad.txt
+++ b/doc/tad.txt
@@ -51,60 +51,51 @@ tad 2000 50 1800 2300 0.01 0.01 event 54985 &
[Description:]
-Run a temperature accelerated dynamics (TAD) simulation. This
-method requires two or more partitions to perform NEB transition
-state searches.
+Run a temperature accelerated dynamics (TAD) simulation. This method
+requires two or more partitions to perform NEB transition state
+searches.
TAD is described in "this paper"_#Voter by Art Voter. It is a method
-that uses accelerated dynamics at an elevated temperature to
-generate results at a specified lower temperature.
-A good
-overview of accelerated dynamics methods for such systems is given in
-"this review paper"_#Voter2 from the same group. In general, these methods assume
-that the long-time dynamics is dominated by infrequent events i.e. the system is
-is confined to low energy basins for long periods,
-punctuated by brief, randomly-occurring transitions to adjacent basins.
-TAD is suitable for
-infrequent-event systems, where in addition, the transition
-kinetics are well-approximated
-by harmonic transition state theory (hTST). In hTST, the temperature
-dependence of transition rates follows the Arrhenius relation.
-As a consequence a set of event times generated in a high-temperature
-simulation can be mapped to a set of much longer estimated times
-in the low-temperature system. However, because this mapping involves
-the energy barrier of the transition event, which is different for each event,
-the first event at the high temperature may not be the earliest event at the
-low temperature. TAD handles this by first generating
-a set of possible events from the current basin. After each event,
-the simulation is reflected backwards into the current basin.
-This is repeated until the stopping criterion is satisfied,
-at which point the event with the earliest
-low-temperature occurrence time is selected.
-The stopping criterion is that the confidence measure
-be greater than 1-{delta}. The confidence measure is
-the probability that no earlier low-temperature
-event will occur at some later time
-in the high-temperature simulation.
-hTST provides an lower bound for this probability,
-based on the user-specified minimum pre-exponential
+that uses accelerated dynamics at an elevated temperature to generate
+results at a specified lower temperature. A good overview of
+accelerated dynamics methods for such systems is given in "this review
+paper"_#Voter2 from the same group. In general, these methods assume
+that the long-time dynamics is dominated by infrequent events i.e. the
+system is is confined to low energy basins for long periods,
+punctuated by brief, randomly-occurring transitions to adjacent
+basins. TAD is suitable for infrequent-event systems, where in
+addition, the transition kinetics are well-approximated by harmonic
+transition state theory (hTST). In hTST, the temperature dependence of
+transition rates follows the Arrhenius relation. As a consequence a
+set of event times generated in a high-temperature simulation can be
+mapped to a set of much longer estimated times in the low-temperature
+system. However, because this mapping involves the energy barrier of
+the transition event, which is different for each event, the first
+event at the high temperature may not be the earliest event at the low
+temperature. TAD handles this by first generating a set of possible
+events from the current basin. After each event, the simulation is
+reflected backwards into the current basin. This is repeated until
+the stopping criterion is satisfied, at which point the event with the
+earliest low-temperature occurrence time is selected. The stopping
+criterion is that the confidence measure be greater than
+1-{delta}. The confidence measure is the probability that no earlier
+low-temperature event will occur at some later time in the
+high-temperature simulation. hTST provides an lower bound for this
+probability, based on the user-specified minimum pre-exponential
factor (reciprocal of {tmax}).
-In order to estimate the energy barrier for each event, the
-TAD method invokes the "NEB"_neb.html method. Each NEB
-replica runs on a partition of processors. The current
-NEB implementation in LAMMPS restricts you to having
-exactly one processor per replica. For more information,
-see the documentation for the "neb"_neb.html command.
-In the current LAMMPS implementation of TAD, all the non-NEB
-TAD operations are performed on the first partition, while the
-other partitions remain idle. Processor partitions are
-defined at run-time using the -partition command-line
-switch.
+In order to estimate the energy barrier for each event, the TAD method
+invokes the "NEB"_neb.html method. Each NEB replica runs on a
+partition of processors. The current NEB implementation in LAMMPS
+restricts you to having exactly one processor per replica. For more
+information, see the documentation for the "neb"_neb.html command. In
+the current LAMMPS implementation of TAD, all the non-NEB TAD
+operations are performed on the first partition, while the other
+partitions remain idle. Processor partitions are defined at run-time
+using the -partition command-line switch.
-A TAD run has several stages,
-which are repeated each time an event
-is performed. The logic for a TAD
-run is as follows:
+A TAD run has several stages, which are repeated each time an event is
+performed. The logic for a TAD run is as follows:
while (time remains):
while (time < tstop):
@@ -118,22 +109,20 @@ while (time remains):
reflect back into current basin
perform earliest event :pre
-Before this outer loop begins,
-the initial potential energy basin is identified by
-quenching (an energy minimization, see below) the initial state and
-storing the resulting coordinates for reference.
+Before this outer loop begins, the initial potential energy basin is
+identified by quenching (an energy minimization, see below) the
+initial state and storing the resulting coordinates for reference.
Inside the inner loop, dynamics is run continuously according to
-whatever integrator has been specified by the user, 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.
+whatever integrator has been specified by the user, 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.
A quench is an energy minimization and is performed by whichever
-algorithm has been defined by the {min} and {min_style} keywords or
-their default values. Note that typically, you do not
-need to perform a highly-converged minimization to detect a transition
-event.
+algorithm has been defined by the {min} and {min_style} keywords or
+their default values. 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
@@ -144,128 +133,121 @@ event/displace"_compute_event_displace.html checks whether any atom in
the compute group has moved further than a specified threshold
distance. If so, an "event" has occurred.
-The neb calculation is similar to that invoked by the "neb"_neb.html command,
-except that the final state is generated internally, instead of being read
-in from a file. The TAD implementation provides default values
-for the NEB settings, which can be overridden using the {neb} and {neb_style}
-keywords.
+The neb calculation is similar to that invoked by the "neb"_neb.html
+command, except that the final state is generated internally, instead
+of being read in from a file. The TAD implementation provides default
+values for the NEB settings, which can be overridden using the {neb}
+and {neb_style} keywords.
:line
-A key aspect of the TAD method is setting the stopping criterion appropriately.
-If this criterion is
-too conservative, then many events must be generated before one is finally performed.
-Conversely, if this criterion is too aggressive, high-entropy high-barrier events will
-be over-sampled, while low-entropy low-barrier events will be under-sampled. If the lowest
-pre-exponential factor is known fairly accurately, then it can be used to estimate {tmax},
-and the value of {delta} can be set to the desired confidence level e.g. {delta} = 0.05
-corresponds to 95% confidence. However, for systems where the dynamics are not well
-characterized (the most common case), it will be necessary to experiment with the values
-of {delta} and {tmax} to get a good trade-off between accuracy and performance. To aid
-with this, for each new event that is detected, a line is printed to the
-screen and log output for the first partition, as follows:
+A key aspect of the TAD method is setting the stopping criterion
+appropriately. If this criterion is too conservative, then many
+events must be generated before one is finally performed. Conversely,
+if this criterion is too aggressive, high-entropy high-barrier events
+will be over-sampled, while low-entropy low-barrier events will be
+under-sampled. If the lowest pre-exponential factor is known fairly
+accurately, then it can be used to estimate {tmax}, and the value of
+{delta} can be set to the desired confidence level e.g. {delta} = 0.05
+corresponds to 95% confidence. However, for systems where the dynamics
+are not well characterized (the most common case), it will be
+necessary to experiment with the values of {delta} and {tmax} to get a
+good trade-off between accuracy and performance. To aid with this, for
+each new event that is detected, a line is printed to the screen and
+log output for the first partition, as follows:
New event: t_hi = 1950 ievent = 2 eb = 2.97066 dt_lo = 114049 dt_hi/t_stop = 0.610293 :pre
-{t_hi} is the timestep on which the event occurrred.
-{ievent} is the event index, zero for the first event in each basin.
-{eb} is the energy barrier for the event.
-{dt_lo} is the low-temperature time since entering the basin.
-{dt_hi/t_stop} is a measure of how close the stopping criterion is to
-being met (if > 1.0, then the criterion is met).
+{t_hi} is the timestep on which the event occurrred. {ievent} is the
+event index, zero for the first event in each basin. {eb} is the
+energy barrier for the event. {dt_lo} is the low-temperature time
+since entering the basin. {dt_hi/t_stop} is a measure of how close
+the stopping criterion is to being met (if > 1.0, then the criterion
+is met).
-A second key aspect is the choice of {t_hi}. A larger value greatly increases
-the rate at which new events are generated.
-However, too large a value introduces errors due to anharmonicity (not accounted
-for within hTST). Once again, for any given system, experimentation is necessary
-to determine the best value of {t_hi}.
+A second key aspect is the choice of {t_hi}. A larger value greatly
+increases the rate at which new events are generated. However, too
+large a value introduces errors due to anharmonicity (not accounted
+for within hTST). Once again, for any given system, experimentation is
+necessary to determine the best value of {t_hi}.
:line
Five kinds of output can be generated during a TAD run: event
-statistics, NEB statistics, thermodynamic output by each replica,
-dump files, and restart files.
+statistics, NEB statistics, thermodynamic output by each replica, dump
+files, and restart files.
-Event statistics are printed to the screen and master log.lammps
-file each time an event is performed. The quantities are the timestep,
-CPU time, clock, and event number.
-The timestep is the usual LAMMPS
-timestep, which corresponds to
-the high-temperature time at which the event was detected,
-in units of timestep.
-The CPU time is the total processor
-time since the start of the TAD run.
-The clock is the low-temperature
-event time, in units of timestep.
-Each clock interval is equal to the timestep interval
-between events scaled by an exponential factor that depends on
-the hi/lo temperature ratio and the energy barrier for that event.
-The event number is a counter that increments with each performed
-event.
+Event statistics are printed to the screen and master log.lammps file
+each time an event is performed. The quantities are the timestep, CPU
+time, clock, and event number. The timestep is the usual LAMMPS
+timestep, which corresponds to the high-temperature time at which the
+event was detected, in units of timestep. The CPU time is the total
+processor time since the start of the TAD run. The clock is the
+low-temperature event time, in units of timestep. Each clock interval
+is equal to the timestep interval between events scaled by an
+exponential factor that depends on the hi/lo temperature ratio and the
+energy barrier for that event. The event number is a counter that
+increments with each performed event.
-The NEB statistics are written to the file specified
-by the {neb_log} keyword. If the keyword value is "none",
-then no NEB statistics are printed out. The statistics
-are written every {Nevery} timesteps.
-See the "neb"_neb.html command for a full description of
-the NEB statistics. When invoked from TAD, NEB statistics are
-never printed to the screen.
+The NEB statistics are written to the file specified by the {neb_log}
+keyword. If the keyword value is "none", then no NEB statistics are
+printed out. The statistics are written every {Nevery} timesteps. See
+the "neb"_neb.html command for a full description of the NEB
+statistics. When invoked from TAD, NEB statistics are never printed to
+the screen.
-Because the NEB calculation must run on multiple partitions,
-LAMMPS produces additional screen and log
-files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
-the TAD command, these contain the thermodynamic output of each
-NEB replica. In addition, the log file for the first partition,
-log.lammps.0, will contain thermodynamic output from short runs and
-minimizations corresponding to the dynamics and quench operations, as
-well as a line for each new detected event, as described above.
+Because the NEB calculation must run on multiple partitions, LAMMPS
+produces additional screen and log files for each partition,
+e.g. log.lammps.0, log.lammps.1, etc. For the TAD command, these
+contain the thermodynamic output of each NEB replica. In addition, the
+log file for the first partition, log.lammps.0, will contain
+thermodynamic output from short runs and minimizations corresponding
+to the dynamics and quench operations, as well as a line for each new
+detected event, as described above.
After the TAD command completes, timing statistics for the TAD run are
printed in each replica's log file, giving a breakdown of how much CPU
time was spent in each stage (NEB, dynamics, quenching, etc).
-Any "dump files"_dump.html defined in the input script will be
-written to during a TAD run at timesteps when an event
-is performed. 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 the
-performed 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 TAD
-run.
+Any "dump files"_dump.html defined in the input script will be written
+to during a TAD run at timesteps when an event is performed. 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 the performed 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 TAD run.
If the "restart"_restart.html command is used, a single restart file
for all the partitions is generated, which allows a TAD run to be
-continued by a new input script in the usual manner.
-The restart file is generated after an event is performed. The restart
-file contains a snapshot of the system in the new quenched state,
-including the event number and the low-temperature time.
-The restart frequency specified in the "restart"_restart.html command
-is interpreted differently when performing a TAD run. It does not
-mean the timestep interval between restart files. Instead it means an
-event interval for performed events. Thus a frequency of 1 means
-write a restart file every time an event is performed. A
-frequency of 10 means write a restart file every 10th performed
-event.
-When an input script reads a restart file from a previous TAD run, the
-new script can be run on a different number of replicas or processors.
+continued by a new input script in the usual manner. The restart file
+is generated after an event is performed. The restart file contains a
+snapshot of the system in the new quenched state, including the event
+number and the low-temperature time. The restart frequency specified
+in the "restart"_restart.html command is interpreted differently when
+performing a TAD run. It does not mean the timestep interval between
+restart files. Instead it means an event interval for performed
+events. Thus a frequency of 1 means write a restart file every time
+an event is performed. A frequency of 10 means write a restart file
+every 10th performed event. When an input script reads a restart file
+from a previous TAD run, the new script can be run on a different
+number of replicas or processors.
Note that within a single state, the dynamics will typically
temporarily continue beyond the event that is ultimately chosen, until
-the stopping criterionis satisfied.
-When the event is eventually performed,
-the timestep counter is reset to the
-value when the event was detected. Similarly, after each quench
-and NEB minimization,
-the timestep counter is reset to the value at the start of the
+the stopping criterionis satisfied. When the event is eventually
+performed, the timestep counter is reset to the value when the event
+was detected. Similarly, after each quench and NEB minimization, the
+timestep counter is reset to the value at the start of the
minimization. This means that the timesteps listed in the replica log
-files do not always increase monotonically. However,
-the timestep values printed to the master log file, dump files, and
-restart files are always monotonically increasing.
+files do not always increase monotonically. However, the timestep
+values printed to the master log file, dump files, and restart files
+are always monotonically increasing.
+
+:line
[Restrictions:]
@@ -273,13 +255,12 @@ This command can only be used if LAMMPS was built with the "replica"
package. See the "Making LAMMPS"_Section_start.html#2_3 section for
more info on packages.
-{N} setting must be integer multiple of
-{t_event}.
+{N} setting must be integer multiple of {t_event}.
Runs restarted from restart files written during a TAD run will only
-produce identical results if the user-specified integrator
-supports exact restarts. So "fix nvt"_fix_nh.html will produce an exact restart,
-but "fix langevin"_fix_langevin.html will not.
+produce identical results if the user-specified integrator supports
+exact restarts. So "fix nvt"_fix_nh.html will produce an exact
+restart, but "fix langevin"_fix_langevin.html will not.
This command cannot be used when any fixes are defined that keep track
of elapsed time to perform time-dependent operations. Examples
@@ -297,9 +278,9 @@ dt/reset"_fix_dt_reset.html and "fix deposit"_fix_deposit.html.
[Default:]
-The option defaults are {min} = 0.1 0.1 40 50, {neb} = 0.01 100 100 10,
-{min_style} = {cg}, {neb_style} = {quickmin},
-and {neb_log} = "none"
+The option defaults are {min} = 0.1 0.1 40 50, {neb} = 0.01 100 100
+10, {min_style} = {cg}, {neb_style} = {quickmin}, and {neb_log} =
+"none"
:line