forked from lijiext/lammps
git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@3266 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
parent
53000e9966
commit
efd2c26122
36
doc/prd.html
36
doc/prd.html
|
@ -92,9 +92,10 @@ run is as follows:
|
||||||
event replica shares state with all replicas
|
event replica shares state with all replicas
|
||||||
</PRE>
|
</PRE>
|
||||||
<P>Before this loop begins, the state of the system on replica 0 is
|
<P>Before this loop begins, the state of the system on replica 0 is
|
||||||
quenched (an energy minimization, see below) and the resulting
|
shared with all replicas, so that all replicas begin from the same
|
||||||
coordinates are shared with all replicas, so that all replicas begin
|
initial state. The first basin is identified by quenching (an energy
|
||||||
from the same initial state.
|
minimization, see below) the initial state and storing the resulting
|
||||||
|
coordinates for reference.
|
||||||
</P>
|
</P>
|
||||||
<P>In the first stage, dephasing is performed by each replica
|
<P>In the first stage, dephasing is performed by each replica
|
||||||
independently to eliminate correlations between replicas. This is
|
independently to eliminate correlations between replicas. This is
|
||||||
|
@ -111,16 +112,16 @@ with arguments that have the same meaning as their counterparts in the
|
||||||
<P>In the second stage, each replica runs dynamics continuously, stopping
|
<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.
|
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
|
This check is performed by quenching the system and comparing the
|
||||||
resulting atom coordinates to the coordinates of the previous event.
|
resulting atom coordinates to the coordinates from the previous basin.
|
||||||
The first time through the PRD loop, the "previous event" is the
|
The first time through the PRD loop, the "previous basin" is the set
|
||||||
initial state of the system.
|
of quenched coordinates from the initial state of the system.
|
||||||
</P>
|
</P>
|
||||||
<P>A quench is an energy minimization and is performed by whichever
|
<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.
|
algorithm has been defined by the <A HREF = "min_style.html">min_style</A> command.
|
||||||
Minimization parameters may be set via the
|
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
|
<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
|
PRD command. The latter are the settings that would be used with the
|
||||||
<A HREF = "minimize.html">minimize</A> command. Note that yypically, you do not
|
<A HREF = "minimize.html">minimize</A> command. Note that typically, you do not
|
||||||
need to perform a highly-converged minimization to detect a transition
|
need to perform a highly-converged minimization to detect a transition
|
||||||
event.
|
event.
|
||||||
</P>
|
</P>
|
||||||
|
@ -135,10 +136,11 @@ If so, an "event" has occurred.
|
||||||
</P>
|
</P>
|
||||||
<P>In the third stage, the replica on which the event occurred continues
|
<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
|
to run dynamics to search for correlated events. This is done by
|
||||||
running dynamics for <I>t_correlate</I> steps, quenching, and checking if
|
running dynamics for <I>t_correlate</I> steps, quenching every <I>t_event</I>
|
||||||
another event has occurred. The first time no correlated event
|
steps, and checking if another event has occurred. The first time no
|
||||||
occurs, the final state of the system is shared with all replicas, and
|
correlated event occurs, the final state of the system is shared with
|
||||||
the outer loop begins again.
|
all replicas, the new basin reference coordinates are updated with the
|
||||||
|
quenched state, and the outer loop begins again.
|
||||||
</P>
|
</P>
|
||||||
<HR>
|
<HR>
|
||||||
|
|
||||||
|
@ -168,8 +170,8 @@ replicas are running independently. The clock represents the real
|
||||||
time that effectively elapses during a PRD simulation of <I>N</I> steps on
|
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
|
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
|
the loop above, searching for infrequent events, then the clock will
|
||||||
advance nearly N*M steps. Note The
|
advance nearly N*M steps. Note the clock time between events will be
|
||||||
clock time between events will be drawn from p(t).
|
drawn from p(t).
|
||||||
</P>
|
</P>
|
||||||
<P>The event number is a counter that increments with each event, whether
|
<P>The event number is a counter that increments with each event, whether
|
||||||
it is uncorrelated or correlated.
|
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 + <I>t_correlate</I>, where T is the time at which the
|
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
|
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
|
contains a snapshot of the system at time T + <I>t_correlate</I>, where T
|
||||||
is the time of the last correlated event. Note that the state of the
|
is the time of the last correlated event.
|
||||||
system is not quenched when written to the restart file.
|
|
||||||
</P>
|
</P>
|
||||||
<P>The restart frequency specified in the <A HREF = "restart.html">restart</A> command
|
<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
|
is interpreted differently when performing a PRD run. It does not
|
||||||
mean the timestep interval between restart files. Instead it means an
|
mean the timestep interval between restart files. Instead it means an
|
||||||
event interval for uncorrelated events. Thus a frequency of 1 means
|
event interval for uncorrelated events. Thus a frequency of 1 means
|
||||||
write a restart file every time an uncorrelated event occurs. A frequency
|
write a restart file every time an uncorrelated event occurs. A
|
||||||
of 10 means write a restart file every 10th uncorrelated event.
|
frequency of 10 means write a restart file every 10th uncorrelated
|
||||||
|
event.
|
||||||
</P>
|
</P>
|
||||||
<P>When an input script reads a restart file from a previous PRD run, the
|
<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.
|
new script can be run on a different number of replicas or processors.
|
||||||
|
|
36
doc/prd.txt
36
doc/prd.txt
|
@ -79,9 +79,10 @@ while (time remains):
|
||||||
event replica shares state with all replicas :pre
|
event replica shares state with all replicas :pre
|
||||||
|
|
||||||
Before this loop begins, the state of the system on replica 0 is
|
Before this loop begins, the state of the system on replica 0 is
|
||||||
quenched (an energy minimization, see below) and the resulting
|
shared with all replicas, so that all replicas begin from the same
|
||||||
coordinates are shared with all replicas, so that all replicas begin
|
initial state. The first basin is identified by quenching (an energy
|
||||||
from the same initial state.
|
minimization, see below) the initial state and storing the resulting
|
||||||
|
coordinates for reference.
|
||||||
|
|
||||||
In the first stage, dephasing is performed by each replica
|
In the first stage, dephasing is performed by each replica
|
||||||
independently to eliminate correlations between replicas. This is
|
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
|
In the second stage, each replica runs dynamics continuously, stopping
|
||||||
every {t_event} steps to check if a transition event has occurred.
|
every {t_event} steps to check if a transition event has occurred.
|
||||||
This check is performed by quenching the system and comparing the
|
This check is performed by quenching the system and comparing the
|
||||||
resulting atom coordinates to the coordinates of the previous event.
|
resulting atom coordinates to the coordinates from the previous basin.
|
||||||
The first time through the PRD loop, the "previous event" is the
|
The first time through the PRD loop, the "previous basin" is the set
|
||||||
initial state of the system.
|
of quenched coordinates from the initial state of the system.
|
||||||
|
|
||||||
A quench is an energy minimization and is performed by whichever
|
A quench is an energy minimization and is performed by whichever
|
||||||
algorithm has been defined by the "min_style"_min_style.html command.
|
algorithm has been defined by the "min_style"_min_style.html command.
|
||||||
Minimization parameters may be set via the
|
Minimization parameters may be set via the
|
||||||
"min_modify"_min_modify.html command and by the {min} keyword of 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
|
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
|
need to perform a highly-converged minimization to detect a transition
|
||||||
event.
|
event.
|
||||||
|
|
||||||
|
@ -122,10 +123,11 @@ If so, an "event" has occurred.
|
||||||
|
|
||||||
In the third stage, the replica on which the event occurred continues
|
In the third stage, the replica on which the event occurred continues
|
||||||
to run dynamics to search for correlated events. This is done by
|
to run dynamics to search for correlated events. This is done by
|
||||||
running dynamics for {t_correlate} steps, quenching, and checking if
|
running dynamics for {t_correlate} steps, quenching every {t_event}
|
||||||
another event has occurred. The first time no correlated event
|
steps, and checking if another event has occurred. The first time no
|
||||||
occurs, the final state of the system is shared with all replicas, and
|
correlated event occurs, the final state of the system is shared with
|
||||||
the outer loop begins again.
|
all replicas, the new basin reference coordinates are updated with the
|
||||||
|
quenched state, and the outer loop begins again.
|
||||||
|
|
||||||
:line
|
: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
|
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
|
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
|
the loop above, searching for infrequent events, then the clock will
|
||||||
advance nearly N*M steps. Note The
|
advance nearly N*M steps. Note the clock time between events will be
|
||||||
clock time between events will be drawn from p(t).
|
drawn from p(t).
|
||||||
|
|
||||||
The event number is a counter that increments with each event, whether
|
The event number is a counter that increments with each event, whether
|
||||||
it is uncorrelated or correlated.
|
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
|
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
|
uncorrelated event occurred. If correlated events were found, then it
|
||||||
contains a snapshot of the system at time T + {t_correlate}, where T
|
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
|
is the time of the last correlated event.
|
||||||
system is not quenched when written to the restart file.
|
|
||||||
|
|
||||||
The restart frequency specified in the "restart"_restart.html command
|
The restart frequency specified in the "restart"_restart.html command
|
||||||
is interpreted differently when performing a PRD run. It does not
|
is interpreted differently when performing a PRD run. It does not
|
||||||
mean the timestep interval between restart files. Instead it means an
|
mean the timestep interval between restart files. Instead it means an
|
||||||
event interval for uncorrelated events. Thus a frequency of 1 means
|
event interval for uncorrelated events. Thus a frequency of 1 means
|
||||||
write a restart file every time an uncorrelated event occurs. A frequency
|
write a restart file every time an uncorrelated event occurs. A
|
||||||
of 10 means write a restart file every 10th uncorrelated event.
|
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
|
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.
|
new script can be run on a different number of replicas or processors.
|
||||||
|
|
Loading…
Reference in New Issue