scnc
/
qmcpack
mirror of https://github.com/QMCPACK/qmcpack.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

sk, reptation, forward walking, forces, backflow 

git-svn-id: https://subversion.assembla.com/svn/qmcdev/trunk@6568 e5b18d87-469d-4833-9cc0-8cdfa06e9491
This commit is contained in:
Raymond Clay 2015-09-09 18:23:00 +00:00
parent 16912722a2
commit 6ca8f27228
3 changed files with 245 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
manual/backflow.tex
View File

@ -1,2 +1,98 @@
\section{Backflow wavefunctions}
\label{sec:backflow}
One can perturb the nodal surface of a single-slater/multi-slater wavefunction through use of a backflow-transformation. Specifically, if we have an antisymmetric function $D(\mathbf{x}_{0\uparrow},\cdots,\mathbf{x}_{N\uparrow}, \mathbf{x}_{0\downarrow},\cdots,\mathbf{x}_{N\downarrow})$, and if $i_\alpha$ is the $i$-th particle of species type $\alpha$, then the backflow transformation works by making the coordinate transformation $\mathbf{x}_{i_\alpha} \to \mathbf{x}'_{i_\alpha}$, and evaluating $D$ at these new ``quasiparticle" coordinates. QMCPACK currently supports quasiparticle transformations given by:
\begin{equation}\label{backflowdef}
\mathbf{x}'_{i_\alpha}=\mathbf{x}_{i_\alpha}+\sum_{\alpha \leq \beta} \sum_{i_\alpha \neq j_\beta} \eta^{\alpha\beta}(|\mathbf{x}_{i_\alpha}-\mathbf{x}_{j_\beta}|)(\mathbf{x}_{i_\alpha}-\mathbf{x}_{j_\beta})
\end{equation}
Here, $\eta^{\alpha\beta}(|\mathbf{x}_{i_\alpha}-\mathbf{x}_{j_\beta}|)$ is a radially symmetric back flow transformation between species $\alpha$ and $\beta$. In QMCPACK, particle $i_\alpha$ is known as the ``target" particle and $j_\beta$ is known as the ``source". The main types of transformations we'll talk about are so called one-body terms, which are between an electron and an ion $\eta^{eI}(|\mathbf{x}_{i_e}-\mathbf{x}_{j_I}|)$, and two-body terms. Two body terms are distinguished as those between like and opposite spin electrons: $\eta^{e(\uparrow)e(\uparrow)}(|\mathbf{x}_{i_e(\uparrow)}-\mathbf{x}_{j_e(\uparrow)}|)$ and $\eta^{e(\uparrow)e(\downarrow)}(|\mathbf{x}_{i_e(\uparrow)}-\mathbf{x}_{j_e(\downarrow)}|)$. Henceforth, we will assume that $\eta^{e(\uparrow)e(\uparrow)}=\eta^{e(\downarrow)e(\downarrow)}$.
In the following, I will explain how to describe general terms like Eq. \ref{backflowdef} in a QMCPACK XML file. For specificity, I will consider a particle set consisting of H and He (in that order). This ordering will be important when we build the XML file, so you can find this out either through your specific declaration of <particleset>, by looking at the hdf5 file in the case of plane waves, or by looking at the qmcpack output file in the section labelled "Summary of QMC systems".
\subsection{Input Specifications}
All backflow declarations occur within a single \texttt{<backflow> ... </backflow>} block. Backflow transformations occur in \texttt{<transformation>} blocks, and have the following input parameters
\begin{table}[h]
\begin{center}
\begin{tabular}{l c c c l }
\hline
\multicolumn{5}{l}{Transformation element} \\
\hline
\bfseries name & \bfseries datatype & \bfseries values & \bfseries defaults & \bfseries description \\
\hline
name & text & & (required) & Unique name for this Jastrow function \\
type & text & ``e-I" & (required) & Define a one-body backflow transformation. \\
& & ``e-e" & & Define a two-body backflow transformation. \\
function & text & Bspline & (required) & B-spline type transformation. (No other types supported) \\
source & text & & & "e" if two-body, ion particle set if one-body.\\
\hline
\end{tabular}
%\end{tabular*}
\end{center}
\end{table}
Just like one and two-body jastrows, parameterization of the backflow transformations are specified within the \texttt{<transformation> } blocks by \texttt{<correlation>} blocks. Please refer to \ref{sec:onebodyjastrowspline} for more information.
\subsection{Example Use Case}
Having specified the general form, we present a general example of one-body and two-body backflow transformations in a hydrogen-helium mixture. The H and He ions have independent backflow transformations, as do the like and unlike-spin two-body terms. One caveat is in order: ionic backflow transformations must be listed in the order that they appear in the particle set. If in our example, He is listed first, and H is listed second, the following example would be correct. However, switching backflow declaration to H first, then He, will result in an error. Outside of this, declaration of one-body blocks and two-body blocks aren't sensitive to ordering.
\begin{lstlisting}
<backflow>
<!--The One-Body term with independent e-He and e-H terms. IN THAT ORDER -->
<transformation name="eIonB" type="e-I" function="Bspline" source="ion0">
<correlation cusp="0.0" size="8" type="shortrange" init="no" elementType="He" rcut="3.0">
<coefficients id="eHeC" type="Array" optimize="yes">
0 0 0 0 0 0 0 0
</coefficients>
</correlation>
<correlation cusp="0.0" size="8" type="shortrange" init="no" elementType="H" rcut="3.0">
<coefficients id="eHC" type="Array" optimize="yes">
0 0 0 0 0 0 0 0
</coefficients>
</correlation>
</transformation>
<!--The Two-Body Term with Like and Unlike Spins -->
<transformation name="eeB" type="e-e" function="Bspline" >
<correlation cusp="0.0" size="7" type="shortrange" init="no" speciesA="u" speciesB="u" rcut="1.2">
<coefficients id="uuB1" type="Array" optimize="yes">
0 0 0 0 0 0 0
</coefficients>
</correlation>
<correlation cusp="0.0" size="7" type="shortrange" init="no" speciesA="d" speciesB="u" rcut="1.2">
<coefficients id="udB1" type="Array" optimize="yes">
0 0 0 0 0 0 0
</coefficients>
</correlation>
</transformation>
</backflow>
\end{lstlisting}
Currently, backflow only works with single-slater determinant wavefunctions. When a backflow transformation has been declared, it should be placed within the \texttt{<determinantset>} block, but outside of the \texttt{<slaterdeterminant>} blocks, like so:
\begin{lstlisting}
<determinantset ... >
<!--basis set declarations go here, if there are any -->
<backflow>
<transformation ...>
<!--Here's where discussed one and two-body terms are defined -->
</transformation>
</backflow>
<slaterdeterminant>
<!--Usual determinant definitions -->
</slaterdeterminant>
</determinantset>
\end{lstlisting}
\subsection{Additional Information}
\begin{itemize}
\item \textbf{Optimization}: Optimizable backflow transformation parameters are notoriously nonlinear, and so optimizing backflow wavefunctions can sometimes be difficult. We direct the reader to our provided backflow tutorials for more information.
\end{itemize}

131
manual/hamiltonianobservable.tex
View File

@ -700,18 +700,10 @@ Additional information:
\subsection{Static structure factor, $S(k)$}
The functional form of the species resolved radial pair correlation function operator is
\begin{align}
g_{ss'}(r) = \frac{V}{4\pi r^2N_sN_{s'}}\sum_{i_s=1}^{N_s}\sum_{j_{s'}=1}^{N_{s'}}\delta(r-|r_{i_s}-r_{j_{s'}}|).
\end{align}
Here $N_s$ is the number of particles of species $s$ and $V$ is the supercell volume. If $s=s'$, then the sum is restricted so that $i_s\ne j_s$.
In QMCPACK, an estimate of $g_{ss'}(r)$ is obtained as a radial histogram with a set of $N_b$ uniform bins of width $\delta r$. This can be expressed analytically as
\begin{align}
\tilde{g}_{ss'}(r) = \frac{V}{4\pi r^2N_sN_{s'}}\sum_{i=1}^{N_s}\sum_{j=1}^{N_{s'}}\frac{1}{\delta r}\int_{r-\delta r/2}^{r+\delta r/2}dr'\delta(r'-|r_{si}-r_{s'j}|),
\end{align}
where the radial coordinate $r$ is restricted to reside at the bin centers, $\delta r/2, 3 \delta r/2, 5 \delta r/2, \ldots$.
Let $\rho^e_\mathbf{k}=\sum_j e^{i \mathbf{k}\cdot\mathbf{r}_j^e}$ be the Fourier space electron density, with $\mathbf{r}^e_j$ being the coordinate of the j-th electron. $\mathbf{k}$ is a wavevector commensurate with the simulation cell. QMCPACK allows the user to accumulate the static electron structure factor $S(\mathbf{k})$ at all commensurate $\mathbf{k}$ such that $|\mathbf{k}| \leq (LR\_DIM\_CUTOFF) r_c$. $N^e$ is the number of electrons, \texttt{LR\_DIM\_CUTOFF} is the optimized breakup parameter, and $r_c$ is the Wigner-Seitz radius. It is defined as follows:
\begin{equation}
S(\mathbf{k}) = \frac{1}{N^e}\langle \rho^e_{-\mathbf{k}} \rho^e_{\mathbf{k}} \rangle
\end{equation}
% has a CUDA counterpart, may be useful to understand difference between cpu and gpu estimators
% see HamiltonianFactory.cpp
@ -728,7 +720,7 @@ where the radial coordinate $r$ is restricted to reside at the bin centers, $\de
\multicolumn{2}{l}{child elements:} & \multicolumn{4}{l}{\textit{None}}\\
\multicolumn{2}{l}{attributes} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{type}$^r$ & text & \textbf{sk} & & Must be sk \\
& \texttt{type}$^r$ & text & sk & & Must be sk \\
& \texttt{name}$^r$ & text & \textit{anything} & any & Unique name for estimator \\
& \texttt{hdf5}$^o$ & boolean & yes/no & no & Output to \texttt{stat.h5} (yes) or \texttt{scalar.dat} (no) \\
\hline
@ -742,6 +734,7 @@ Additional information:
\item{\textbf{name:} Unique name for estimator instance. A data structure of the same name will appear in \texttt{stat.h5} output files.}
\item{\textbf{hdf5:} If \texttt{hdf5==yes} output data for $S(k)$ is directed to the \texttt{stat.h5} file (recommended usage). If \texttt{hdf5==no}, the data is instead routed to the \texttt{scalar.dat} file resulting in many columns of data with headings prefixed by \texttt{name} and postfixed by the k-point index (\textit{e.g.} \texttt{sk\_0 sk\_1 \ldots sk\_1037 \ldots}).}
\item{This estimator only works in periodic boundary conditions. Its presence in the input file is ignored otherwise.}
\item{This is not a species resolved structure factor. Additionally, for $\mathbf{k}$ vectors commensurate with the unit cell, $S(\mathbf{k})$ will include contributions from the static electronic density, thus meaning it won't accurately measure the electron-electron density response. }
\end{itemize}
\begin{lstlisting}[caption=Static structure factor estimator element.]
@ -872,6 +865,63 @@ Additional information:
% </estimator>
\section{Forward Walking Estimators} \label{sec:forward_walking}
Forward walking is a method by which one can sample the pure fixed-node distribution $\langle \Phi_0 | \Phi_0\rangle$. Specifically, one multiplies each walker's DMC mixed estimate for the observable $\mathcal{O}$, $\frac{\mathcal{O}(\mathbf{R})\Psi_T(\mathbf{R})}{\Psi_T(\mathbf{R})}$, by the weighting factor $\frac{\Phi_0(\mathbf{R})}{\Psi_T(\mathbf{R})}$. As it turns out, this weighting factor for any walker $\mathbf{R}$ is proportional to the total number of descendants the walker will have after a sufficiently long projection time $\beta$.
To forward walk on an observable, one declares a generic forward walking estimator within a \texttt{<hamiltonian>} block, and then specifies the observables to forward walk on and forward walking parameters. Here is a summary.
\begin{table}[h]
\begin{center}
\begin{tabularx}{\textwidth}{l l l l l l }
\hline
\multicolumn{6}{l}{\texttt{estimator type=ForwardWalking} element} \\
\hline
\multicolumn{2}{l}{parent elements:} & \multicolumn{4}{l}{\texttt{hamiltonian, qmc}}\\
\multicolumn{2}{l}{child elements:} & \multicolumn{4}{l}{\textit{Observable}}\\
\multicolumn{2}{l}{attributes} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{type}$^r$ & text & \textbf{ForwardWalking} & & Must be ``ForwardWalking" \\
& \texttt{name}$^r$ & text & \textit{anything} & any & Unique name for estimator \\
\hline
\end{tabularx}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\begin{tabularx}{\textwidth}{l l l l l l }
\hline
\multicolumn{6}{l}{\texttt{Observable} element} \\
\hline
\multicolumn{2}{l}{parent elements:} & \multicolumn{4}{l}{\texttt{estimator, hamiltonian, qmc}}\\
\multicolumn{2}{l}{child elements:} & \multicolumn{4}{l}{\textit{None}}\\
\multicolumn{2}{l}{attributes} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{name}$^r$ & text & \textit{anything} & any & Registered name of existing estimator on which to forward walk. \\
& \texttt{max}$^r$ & integer & $ > 0$ & & The maximum projection time in steps (\texttt{max}$=\beta/\tau$). \\
& \texttt{frequency}$^r$ & text & $\geq 1$ & & Dump data only for every \texttt{frequency}-th \\
& & & & & to \texttt{scalar.dat} file \\
\hline
\end{tabularx}
\end{center}
\end{table}
Additional information:
\begin{itemize}
\item{\textbf{Cost}: Due to having to store histories of observables up to \texttt{max} time-steps, one should multiply the memory cost of storing the non-forward walked observables variables by $\texttt{max}$. Not an issue for things like the potential energy, but can be prohibitive for observables like density, forces, etc. }
\item{\textbf{Naming Convention}: Forward walked observables are automatically named \texttt{FWE\_name\_i}, where \texttt{i} is the forward walked expectation value at time step \texttt{i}, and \texttt{name} is whatever name appears in the \texttt{<Observable>} block. This is also how it will appear in the \texttt{scalar.dat} file. }
\end{itemize}
In the following example case, QMCPACK forward walks on the potential energy for 300 time steps, and dumps the forward walked value at every time step.
\begin{lstlisting}[caption=Forward walking estimator element.]
<estimator name="fw" type="ForwardWalking">
<Observable name="LocalPotential" max="300" frequency="1"/>
<!--- Additional Observable blocks go here -->
</estimator>
\end{lstlisting}
@ -880,32 +930,59 @@ Additional information:
\section{``Force'' estimators} \label{sec:force_est}
% Force estimators added in CoulombPotentialFactory.cpp, HamiltonianFactory::addForceHam
QMCPACK supports force estimation by use of the Chiesa-Ceperly-Zhang (CCZ) estimator. Currently, open and periodic boundary conditions are supported, but for all-electron calculations only.
Without loss of generality, the CCZ estimator for the z-component of the force on an ion centered at the origin is given by the following expression:
\begin{equation}
F_z = -Z \sum_{i=1}^{N_e}\frac{z_i}{r_i^3}[\theta(r_i-\mathcal{R}) + \theta(\mathcal{R}-r_i)\sum_{\ell=1}^{M}c_\ell r_i^\ell]
\end{equation}
Z is the ionic charge, $M$ is the degree of the smoothing polynomial, $\mathcal{R}$ is a real-space cutoff of the sphere within which the bare-force estimator is smoothed, and $c_\ell$ are predetermined coefficients. These coefficients are chosen to minimize the weighted mean square error between the bare force estimate and the s-wave filtered estimator. Specifically,
\begin{equation}
\chi^2 = \int_0^\mathcal{R}dr\,r^m\,[f_z(r) - \tilde{f}_z(r)]^2
\end{equation}
Here, $m$ is the weighting exponent, $f_z(r)$ is the unfiltered radial force density for the z force component, and $\tilde{f}_z(r)$ smoothed polynomial function for the same force density. The reader is invited to refer to the original paper for a more thorough explanation of the methodology, but with the notation in hand, QMCPACK takes the following parameters.
\FloatBarrier
\begin{table}[h]
\begin{center}
\begin{tabularx}{\textwidth}{l l l l l l }
\hline
\multicolumn{6}{l}{\texttt{estimator type=Force} factory element} \\
\multicolumn{6}{l}{\texttt{estimator type=Force} element} \\
\hline
\multicolumn{2}{l}{parent elements:} & \multicolumn{4}{l}{\texttt{hamiltonian, qmc}}\\
\multicolumn{2}{l}{type selector:} & \multicolumn{4}{l}{\texttt{mode} attribute}\\
\multicolumn{2}{l}{type options: } & bare & \multicolumn{3}{l}{Bare force estimator}\\
\multicolumn{2}{l}{ } & cep & \multicolumn{3}{l}{Ceperley force estimator}\\
\multicolumn{2}{l}{ } & pulay & \multicolumn{3}{l}{Pulay force estimator}\\
\multicolumn{2}{l}{ } & zero\_variance & \multicolumn{3}{l}{Zero variance force estimator}\\
\multicolumn{2}{l}{ } & stress & \multicolumn{3}{l}{Stress estimator}\\
\multicolumn{2}{l}{shared attributes:} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
\multicolumn{2}{l}{child elements:} & \multicolumn{4}{l}{\texttt{parameter}}\\
\multicolumn{2}{l}{attributes} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{mode}$^o$ & text & \textit{See above} & bare & Select estimator type\\
& \texttt{type}$^r$ & text & \textbf{Force} & & Must be Force \\
& \texttt{type}$^r$ & text & Force & & Must be ``Force" \\
& \texttt{name}$^o$ & text & \textit{anything} & ForceBase & Unique name for this estimator\\
& \texttt{source}$^o$ & text & \texttt{particleset.name} & ion0 & Identify classical particleset\\
& \texttt{target}$^o$ & text & \texttt{particleset.name} & e & Identify quantum particleset\\
& \texttt{psi}$^o$ & text & \texttt{wavefunction.name}& psi0 & Identify wavefunction\\
% & \texttt{psi}$^o$ & text & \texttt{wavefunction.name}& psi0 & Identify wavefunction\\
& \texttt{pbc}$^o$ & boolean & yes/no & yes & Using periodic BC's or not\\
\hline
& \texttt{addionion}$^o$ & boolean & yes/no & no & Add the ion-ion force contribution to output force estimate. \\
\multicolumn{2}{l}{parameters} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{rcut}$^o$ & real & $> 0$ & 1.0 & Real space cutoff $\mathcal{R}$ in bohr.\\
& \texttt{nbasis}$^o$ & integer & $> 0 $ & 2 & Degree of smoothing polynomial $M$ \\
& \texttt{weightexp}$^o$ & integer &$ > 0$ & 2 & $\chi^2$ weighting exponent $m$.\\
\hline
\end{tabularx}
\end{center}
\end{table}
\FloatBarrier
Additional information:
\begin{itemize}
\item{\textbf{Naming Convention}: The unique identifier \texttt{name} is appended with \texttt{name\_X\_Y} in the \texttt{scalar.dat} file, where \texttt{X} is the ion ID number, and \texttt{Y} is the component ID (an integer with x=0, y=1, z=2). All force components for all ions are computed and dumped to the \texttt{scalar.dat} file.}
\item{\textbf{Miscellaneous}: Usually, the default choice of \texttt{weightexp} is sufficient. Different combinations of \texttt{rcut} and \texttt{nbasis} should be tested though to minimize variance and bias. There is of course a tradeoff, with larger \texttt{nbasis} and smaller \texttt{rcut} leading to smaller biases and larger variances. }
\end{itemize}
The following is an example use case.
\begin{lstlisting}
<estimator name="myforce" type="Force" mode="cep" addionion="yes">
<parameter name="rcut">0.1</parameter>
<parameter name="nbasis">4</parameter>
<parameter name="weightexp">2</parameter>
</estimator>
\end{lstlisting}

45
manual/reptation.tex
View File

@ -1,2 +1,47 @@
\section{Reptation Monte Carlo}
\label{sec:rmc}
Like diffusion monte carlo, reptation monte carlo (RMC) is a projector based method, allowing us the ability to sample the fixed-node wavefunciton. However, by exploiting the path-integral formulation of Schr\"{o}dinger's equation, the RMC algorithm can offer some advantages over traditional DMC, such as sampling both the mixed and pure fixed-node distributions in polynomial time, as well as not having population fluctuations and biases. The current implementation does not work with T-moves.
There are two adjustable parameters that affect the quality of the RMC projection: imaginary projection time $\beta$ of the sampling path (commonly called a ``reptile"), and the Trotter time step $\tau$. $\beta$ must be chosen to be large enough such that $e^{-\beta \hat{H}}|\Psi_T\rangle \approx |\Phi_0\rangle$ for mixed observables, and $e^{-\frac{\beta}{2} \hat{H}}|\Psi_T\rangle \approx |\Phi_0\rangle$ for pure observables. The reptile is discretized into $M=\beta/\tau$ beads at the cost of an $\mathcal{O}(\tau)$ time-step error for observables arising from the Trotter-Suzuki breakup of the short-time propagator.
The following table lists some of the more practical
\begin{table}[h]
\begin{center}
\begin{tabularx}{\textwidth}{l l l l l l }
\hline
\multicolumn{6}{l}{\texttt{vmc} method} \\
\hline
\multicolumn{2}{l}{parameters} & \multicolumn{4}{l}{}\\
& \bfseries name & \bfseries datatype & \bfseries values & \bfseries default & \bfseries description \\
& \texttt{beta } & real & $> 0$ & dep. & reptile projection time $\beta$ \\
& \texttt{timestep } & real & $> 0$ & 0.1 & Trotter time step $\tau$ for each electron move \\
& \texttt{beads } & int & $> 0$ & 1 & Number of reptile beads $M=\beta/\tau$ \\
& \texttt{blocks } & integer & $\ge 0$ & 1 & number of blocks \\
& \texttt{steps } & integer & $\ge 0$ & 1 & number of steps per block \\
& \texttt{vmcpresteps } & integer & $\ge 0$ & 0 & propagates reptile using VMC for given number of steps\\
& \texttt{warmupsteps } & integer & $\ge 0$ & 0 & number of steps for warming up\\
& \texttt{MaxAge } & integer & $\ge 0 $ & 0 & force accept for stuck reptile if age exceeds MaxAge. \\
\hline
\end{tabularx}
\end{center}
\end{table}
Additional information:
Because of the sampling differences between DMC ensembles of walkers and RMC reptiles, the RMC block should contain the following estimator declaration to ensure correct sampling: \texttt{ <estimator name="RMC" hdf5="no">}.
\begin{itemize}
\item \texttt{beta} or \texttt{beads}? One can specify one or the other, and from the Trotter time-step, the code will construct an appropriately sized reptile. If both are given, \texttt{beta} overrides \texttt{beads}.
\item \textbf{Mixed vs. Pure observables?} For all observables appearing in the \texttt{scalar.dat} file in either VMC or DMC, RMC appends the suffix \texttt{\_m} or \texttt{\_p} for mixed and pure estimates respectively.
\item \textbf{Sampling}. For pure estimators, one should check the traces of both pure and mixed estimates. Ergodicity is a known problem in RMC. Because we use the bounce algorithm, it is possible for the reptile to bounce back and forth without changing the electron coordinates of the central beads. This might not easily show up with mixed estimators, since these are accumulated at constantly regrown ends, but pure estimates are accumulated on these central beads, and so can exhibit strong autocorrelations in pure estimate traces.
\item \textbf{Propagator}: Our implementation of RMC uses Moroni's DMC link action (symmetrized), with Umrigar's scaled drift near nodes. In this regard, the propagator is identical to the one QMCPACK uses in DMC.
\item \textbf{Sampling}: We use Ceperley's bounce algorithm. MaxAge is used in case the reptile gets stuck, at which point the code forces move acceptance, stops accumulating statistics, and requilibrates the reptile. Very rarely will this be required. For move proposals, we use particle-by-particle VMC a total of $N_e$ times to generate a new all-electron configuration, at which point the action is computed and the move is either accepted or rejected.
\end{itemize}