ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@11566 f3b2605a-c512-4ea7-a41b-209d697bcdaa

Browse Source
This commit is contained in:
sjplimp
2014-02-14 16:31:32 +00:00
parent 4833f14be8
commit 109b5601d0
2 changed files with 97 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
doc/prd.html
View File

@ -42,7 +42,10 @@
Tdephase = target temperature for velocity randomization, used in dephasing
<I>vel</I> values = loop dist
loop = <I>all</I> or <I>local</I> or <I>geom</I>, used in dephasing
dist = <I>uniform</I> or <I>gaussian</I>, used in dephasing
dist = <I>uniform</I> or <I>gaussian</I>, used in dephasing
<I>time</I> value = <I>step</I> or <I>clock</I>
<I>step</I> = simulation runs for N timesteps on each replica (default)
<I>clock</I> = simulation runs for N timesteps across all replicas
</PRE>
</UL>
@ -54,7 +57,9 @@ prd 5000 100 10 10 100 1 54982 min 0.1 0.1 100 200
<P><B>Description:</B>
</P>
<P>Run a parallel replica dynamics (PRD) simulation using multiple
replicas of a system. One or more replicas can be used.
replicas of a system. One or more replicas can be used. The total
number of steps <I>N</I> to run can be interpreted in one of two ways; see
discussion of the <I>time</I> keyword below.
</P>
<P>PRD is described in <A HREF = "#Voter">this paper</A> by Art Voter. It is a method
for performing accelerated dynamics that is suitable for
@ -111,13 +116,17 @@ storing the resulting coordinates for reference.
independently to eliminate correlations between replicas. This is
done by choosing a random set of velocities, based on the
<I>random_seed</I> that is specified, and running <I>t_dephase</I> timesteps of
dynamics. This is repeated <I>n_dephase</I> times. If the <I>temp</I> keyword
is not specified, the target temperature for velocity randomization
for each replica is the current temperature of that replica.
Otherwise, it is the specified <I>Tdephase</I> temperature. The style of
velocity randomization is controlled using the keyword <I>vel</I> with
arguments that have the same meaning as their counterparts in the
<A HREF = "velocity.html">velocity</A> command.
dynamics. This is repeated <I>n_dephase</I> times. At each of the
<I>n_dephase</I> stages, if an event occurs during the <I>t_dephase</I> steps of
dynamics for a particular replica, the replica repeats the stage until
no event occurs.
</P>
<P>If the <I>temp</I> keyword is not specified, the target temperature for
velocity randomization for each replica is the current temperature of
that replica. Otherwise, it is the specified <I>Tdephase</I> temperature.
The style of velocity randomization is controlled using the keyword
<I>vel</I> with arguments that have the same meaning as their counterparts
in the <A HREF = "velocity.html">velocity</A> command.
</P>
<P>In the second stage, each replica runs dynamics continuously, stopping
every <I>t_event</I> steps to check if a transition event has occurred.
@ -148,7 +157,8 @@ distance. If so, an "event" has occurred.
replica) continues to run dynamics to search for correlated events.
This is done by running dynamics for <I>t_correlate</I> steps, quenching
every <I>t_event</I> steps, and checking if another event has occurred.
The first time no correlated event occurs, the final state of the
</P>
<P>The first time no correlated event occurs, the final state of the
event replica is shared with all replicas, the new basin reference
coordinates are updated with the quenched state, and the outer loop
begins again. While the replica event is searching for correlated
@ -156,6 +166,18 @@ events, all the other replicas also run dynamics and event checking
with the same schedule, but the final states are always overwritten by
the state of the event replica.
</P>
<P>The outer loop of the pseudo-code above continues until <I>N</I> steps of
dynamics have been performed. Note that <I>N</I> only includes the
dynamics of stages 2 and 3, not the steps taken during dephasing or
the minimization iterations of quenching. The specified <I>N</I> is
interpreted in one of two ways, depending on the <I>time</I> keyword. If
the <I>time</I> value is <I>step</I>, which is the default, then each replica
runs for <I>N</I> timesteps. If the <I>time</I> value is <I>clock</I>, then the
simulation runs until <I>N</I> aggregate timesteps across all replicas have
elapsed. This aggregate time is the "clock" time defined below, which
typically advances nearly M times faster than the timestepping on a
single replica.
</P>
<HR>
<P>Four kinds of output can be generated during a PRD run: event
@ -168,28 +190,31 @@ limited to event statistics. Note that if a PRD run is performed on
only a single replica then the event statistics will be intermixed
with the usual thermodynamic output discussed below.
</P>
<P>The quantities printed each time an event occurs are the timestep,
CPU time, clock, event number, a correlation flag,
the number of coincident events, and the replica number of the chosen event.
<P>The quantities printed each time an event occurs are the timestep, CPU
time, clock, event number, a correlation flag, the number of
coincident events, and the replica number of the chosen event.
</P>
<P>The timestep is the usual LAMMPS timestep, except that time does not
advance during dephasing or quenches, but only during dynamics. Note
that are two kinds of dynamics in the PRD loop listed above. The
first is when all replicas are performing independent dynamics. The
second is when correlated events are being searched for and only one
replica is running dynamics.
first is when all replicas are performing independent dynamics,
waiting for an event to occur. The second is when correlated events
are being searched for and only one replica is running dynamics.
</P>
<P>The CPU time is the total processor time since the start of the PRD
run.
</P>
<P>The clock is the same as the timestep except that it advances by M
steps every timestep during the first kind of dynamics when the M
replicas are running independently. The clock represents the real
time that effectively elapses during a PRD simulation of <I>N</I> steps on
M replicas. If most of the PRD run is spent in the second stage of
the loop above, searching for infrequent events, then the clock will
advance nearly N*M steps. Note the clock time between events will be
drawn from p(t).
replicas are running independently. The clock advances by only 1 step
per timestep during the second kind of dynamics, since only a single
replica is checking for a correlated event. Thus "clock" time
represents the aggregate time (in steps) that effectively elapses
during a PRD simulation 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 M times faster than it
would if a single replica was running. Note the clock time between
events will be drawn from p(t).
</P>
<P>The event number is a counter that increments with each event, whether
it is uncorrelated or correlated.
@ -297,8 +322,8 @@ dt/reset</A> and <A HREF = "fix_deposit.html">fix deposit</A>.
</P>
<P><B>Default:</B>
</P>
<P>The option defaults are <I>min</I> = 0.1 0.1 40 50, no <I>temp</I> setting, and
<I>vel</I> = <I>geom</I> <I>gaussian</I>.
<P>The option defaults are min = 0.1 0.1 40 50, no temp setting, vel =
geom gaussian, and time = step.
</P>
<HR>

71
doc/prd.txt
View File

@ -30,7 +30,10 @@ keyword = {min} or {temp} or {vel} :l
Tdephase = target temperature for velocity randomization, used in dephasing
{vel} values = loop dist
loop = {all} or {local} or {geom}, used in dephasing
dist = {uniform} or {gaussian}, used in dephasing :pre
dist = {uniform} or {gaussian}, used in dephasing
{time} value = {step} or {clock}
{step} = simulation runs for N timesteps on each replica (default)
{clock} = simulation runs for N timesteps across all replicas :pre
:ule
[Examples:]
@ -41,7 +44,9 @@ prd 5000 100 10 10 100 1 54982 min 0.1 0.1 100 200 :pre
[Description:]
Run a parallel replica dynamics (PRD) simulation using multiple
replicas of a system. One or more replicas can be used.
replicas of a system. One or more replicas can be used. The total
number of steps {N} to run can be interpreted in one of two ways; see
discussion of the {time} keyword below.
PRD is described in "this paper"_#Voter by Art Voter. It is a method
for performing accelerated dynamics that is suitable for
@ -98,13 +103,17 @@ In the first stage, dephasing is performed by each replica
independently to eliminate correlations between replicas. This is
done by choosing a random set of velocities, based on the
{random_seed} that is specified, and running {t_dephase} timesteps of
dynamics. This is repeated {n_dephase} times. If the {temp} keyword
is not specified, the target temperature for velocity randomization
for each replica is the current temperature of that replica.
Otherwise, it is the specified {Tdephase} temperature. The style of
velocity randomization is controlled using the keyword {vel} with
arguments that have the same meaning as their counterparts in the
"velocity"_velocity.html command.
dynamics. This is repeated {n_dephase} times. At each of the
{n_dephase} stages, if an event occurs during the {t_dephase} steps of
dynamics for a particular replica, the replica repeats the stage until
no event occurs.
If the {temp} keyword is not specified, the target temperature for
velocity randomization for each replica is the current temperature of
that replica. Otherwise, it is the specified {Tdephase} temperature.
The style of velocity randomization is controlled using the keyword
{vel} with arguments that have the same meaning as their counterparts
in the "velocity"_velocity.html command.
In the second stage, each replica runs dynamics continuously, stopping
every {t_event} steps to check if a transition event has occurred.
@ -135,6 +144,7 @@ In the third stage, the replica on which the event occurred (event
replica) continues to run dynamics to search for correlated events.
This is done by running dynamics for {t_correlate} steps, quenching
every {t_event} steps, and checking if another event has occurred.
The first time no correlated event occurs, the final state of the
event replica is shared with all replicas, the new basin reference
coordinates are updated with the quenched state, and the outer loop
@ -143,6 +153,18 @@ events, all the other replicas also run dynamics and event checking
with the same schedule, but the final states are always overwritten by
the state of the event replica.
The outer loop of the pseudo-code above continues until {N} steps of
dynamics have been performed. Note that {N} only includes the
dynamics of stages 2 and 3, not the steps taken during dephasing or
the minimization iterations of quenching. The specified {N} is
interpreted in one of two ways, depending on the {time} keyword. If
the {time} value is {step}, which is the default, then each replica
runs for {N} timesteps. If the {time} value is {clock}, then the
simulation runs until {N} aggregate timesteps across all replicas have
elapsed. This aggregate time is the "clock" time defined below, which
typically advances nearly M times faster than the timestepping on a
single replica.
:line
Four kinds of output can be generated during a PRD run: event
@ -155,28 +177,31 @@ limited to event statistics. Note that if a PRD run is performed on
only a single replica then the event statistics will be intermixed
with the usual thermodynamic output discussed below.
The quantities printed each time an event occurs are the timestep,
CPU time, clock, event number, a correlation flag,
the number of coincident events, and the replica number of the chosen event.
The quantities printed each time an event occurs are the timestep, CPU
time, clock, event number, a correlation flag, the number of
coincident events, and the replica number of the chosen event.
The timestep is the usual LAMMPS timestep, except that time does not
advance during dephasing or quenches, but only during dynamics. Note
that are two kinds of dynamics in the PRD loop listed above. The
first is when all replicas are performing independent dynamics. The
second is when correlated events are being searched for and only one
replica is running dynamics.
first is when all replicas are performing independent dynamics,
waiting for an event to occur. The second is when correlated events
are being searched for and only one replica is running dynamics.
The CPU time is the total processor time since the start of the PRD
run.
The clock is the same as the timestep except that it advances by M
steps every timestep during the first kind of dynamics when the M
replicas are running independently. The clock represents the real
time that effectively elapses during a PRD simulation of {N} steps on
M replicas. If most of the PRD run is spent in the second stage of
the loop above, searching for infrequent events, then the clock will
advance nearly N*M steps. Note the clock time between events will be
drawn from p(t).
replicas are running independently. The clock advances by only 1 step
per timestep during the second kind of dynamics, since only a single
replica is checking for a correlated event. Thus "clock" time
represents the aggregate time (in steps) that effectively elapses
during a PRD simulation 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 M times faster than it
would if a single replica was running. 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.
@ -284,8 +309,8 @@ dt/reset"_fix_dt_reset.html and "fix deposit"_fix_deposit.html.
[Default:]
The option defaults are {min} = 0.1 0.1 40 50, no {temp} setting, and
{vel} = {geom} {gaussian}.
The option defaults are min = 0.1 0.1 40 50, no temp setting, vel =
geom gaussian, and time = step.
:line