From 953a7bc7eb04b4e4829c861bf554ef5a59f94081 Mon Sep 17 00:00:00 2001 From: sjplimp Date: Wed, 5 Jan 2011 15:43:09 +0000 Subject: [PATCH] git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@5480 f3b2605a-c512-4ea7-a41b-209d697bcdaa --- doc/tad.html | 311 ++++++++++++++++++++++++--------------------------- doc/tad.txt | 311 ++++++++++++++++++++++++--------------------------- 2 files changed, 292 insertions(+), 330 deletions(-) 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