Before this loop begins, the state of the system on replica 0 is -quenched (an energy minimization, see below) and the resulting -coordinates are shared with all replicas, so that all replicas begin -from the same initial state. +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.
In the first stage, dephasing is performed by each replica independently to eliminate correlations between replicas. This is @@ -111,16 +112,16 @@ with arguments that have the same meaning as their counterparts in the
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 of the previous event. -The first time through the PRD loop, the "previous event" is the -initial state of the system. +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 command. Minimization parameters may be set via the min_modify command and by the min keyword of the PRD command. The latter are the settings that would be used with the -minimize command. Note that yypically, you do not +minimize command. Note that typically, you do not need to perform a highly-converged minimization to detect a transition event.
@@ -135,10 +136,11 @@ 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, 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, and -the outer loop begins again. +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.
The event number is a counter that increments with each event, whether it is uncorrelated or correlated. @@ -224,15 +226,15 @@ 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. Note that the state of the -system is not quenched when written to the restart file. +is the time of the last correlated event.
The restart frequency specified in the restart 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. +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. diff --git a/doc/prd.txt b/doc/prd.txt index 6a15145398..854bad2d98 100644 --- a/doc/prd.txt +++ b/doc/prd.txt @@ -79,9 +79,10 @@ while (time remains): event replica shares state with all replicas :pre Before this loop begins, the state of the system on replica 0 is -quenched (an energy minimization, see below) and the resulting -coordinates are shared with all replicas, so that all replicas begin -from the same initial state. +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. In the first stage, dephasing is performed by each replica independently to eliminate correlations between replicas. This is @@ -98,16 +99,16 @@ with arguments that have the same meaning as their counterparts in the 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 of the previous event. -The first time through the PRD loop, the "previous event" is the -initial state of the system. +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 yypically, you do not +"minimize"_minimize.html command. Note that typically, you do not need to perform a highly-converged minimization to detect a transition event. @@ -122,10 +123,11 @@ 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, 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, and -the outer loop begins again. +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 @@ -155,8 +157,8 @@ 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). +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. @@ -211,15 +213,15 @@ 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. Note that the state of the -system is not quenched when written to the restart file. +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. +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.