## Diffusion Monte Carlo

Keyword: DMC

*Description:* In this implementation of DMC, we use something similar to the Umrigar Nightingale, Runge paper, with some modifications. Electrons are moved one-by-one, and there is an effective timestep for the branching part of the green's function.

We use a modification of the branching algorithm that ensures a constant number of walkers. Every few DMC steps, search for high weights. If one with greater than some threshold(1.8) do the following. Search for the walker with the lowest weight(w2) that hasn't already branched Branch the first walker and kill the second walker with probability . Otherwise branch the second walker and kill the first walker.

This ensures a constant number of walkers, which improves the parallel efficiency--it is easy to scale up to hundreds of thousands of processors with 99% efficiency.

*Required keywords*

Keyword | Type | Description |
---|---|---|

TIMESTEP | float | A measure of how large each move should be. Adjust such that the acceptance ratio is about .99. Acceptance ratio is just a general guide, however, and it's useful to do several time steps if you need highly accurate results. |

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

AVERAGE | section | empty | Section for an Average generator |

SAVE_TRACE | string | none | Every block, save the current configurations and their weights (in binary). Note that since this is a binary file, you may need to use the utility swap_endian (provided in utils) to change architectures. |

TMOVES | flag | False | Use Michele Casula's T-moves, which makes DMC rigorously variational when there are non-local pseudopotentials at the cost of increasing the timestep error slightly |

TARGET_CONFIG | integer | 2048 | The desired number of total walkers across all processes. The actual number will be selected to evenly distribute the walkers. |

NBLOCK | integer | 100 | Number of blocks. |

LABEL | string | dmc | Label in the .log file |

*Advanced keywords*

Keyword | Type | Default | Description |
---|---|---|---|

NSTEP | integer | special | Number of DMC steps to take in a block. The default is set such that NSTEP*TIMESTEP is approximately 1. |

LOW_IO | flag | False | Do not write to the .config file every block; only at the end of the run. |

FEEDBACK | float | 1.0 | The strength of the population control. Set it to roughly 1/n, where n is the number of steps that it should take to return the population to the average value. |

START_FEEDBACK | float | 1.0 | The strength of the population control when reading in from a checkpoint file. This is mostly useful for CDMC, where it should be set to 10. |

FEEDBACK_INTERVAL | integer | 5 | Number of steps to wait before doing population control. |

BRANCH_START_CUTOFF | float | 10 | When a walker's energy is very low, we slow down the accumulation of weights, eventually cutting it off. The cutoff starts at BRANCH_START_CUTOFF*sigma, where sigma is the standard deviation of the local energy. When doing highly accurate calculations, it's sometimes the case that eref is biased. One can increase this value, which should alleviate the problem. |

## Linear energy optimization

Keyword: LINEAR

*Description:* Perform energy optimization using the method very similar to the one described by Umrigar and coworkers in Phys. Rev. Lett. 98, 110201 (2007).

*Required keywords*

None

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

TOTAL_NSTEP | Integer | 16384 | Total number of VMC steps to perform when calculating the Hamiltonian matrix. This is the most important variable to increase when improving the accuracy. |

TOTAL_FIT | Integer | 1024 | Number of configurations to use when calculating the step size using correlated sampling. |

WFOUTPUT | String | runid.wfout | Choose the filename to place an input deck for the final wavefunction and intermediate ones as the optimization continues. |

ITERATIONS | Integer | 30 | Number of optimization iterations. |

EN_CONVERGENCE | Float | 0.001 | Stop run when changes in energy are less than this value (in Hartrees). |

*Advanced keywords*

Keyword | Type | Default | Description |
---|---|---|---|

VMC_NSTEP | Integer | TOTALNSTEP/nprocs | Number of VMC steps to perform per processor to collect statistics on the Hamiltonian matrix. |

MINIMUM_PSI0 | Float | 0.95 | Fraction of the original wave function to keep per step. This is a stabilization parameter. |

MAX_VMC_NSTEP | Integer | 8*VMCNSTEP | The optimization method will increase VMCNSTEP automatically if certain significance requirements are not met in the Hamiltonian matrix. This variable limits how much VMCNSTEP can be increased. |

FIT_NCONFIG | Integer | TOTALFIT/nprocs | The number of configurations per processor used to evaluate the step size. This is adjusted automatically to ensure statistical significance. |

MAX_FIT_NCONFIG | Integer | 8*FITNCONFIG | Maximum number of configurations per processor to use to evaluate the step size. |

## Optimize (Variance)

Keyword: OPTIMIZE

*Description:* On a fixed sample set, optimize one of a number of objective functions with respect to the wave function parameters. Note that energy optimization using this method is typically not efficient or advised. This method is most useful to perform rough variance optimization of a Jastrow factor prior either to performing a DMC calculation or using the LINEAR method to optimize the energy.

*Required keywords*

None

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

READCONFIG | String | Read configurations from a file. By default, QWalk will generate the configurations automatically. | |

ITERATIONS | Integer | 30 | Number of optimization iterations. |

EREF | Float | special | A best guess at the optimized energy. If you don't put this keyword, QWalk will make a good guess at the proper value, which should be good enough unless the system is rather large. |

WFOUTPUT | String | runid.wfout | Choose the filename to place an input deck for the final wavefunction and intermediate ones as the optimization continues. |

## Plot orbitals

Keyword: PLOT

*Description:* The PLOT method simply plots the one-particle orbitals and density of a trial function. These are output in Gaussian CUBE file format. The density, equal to the sum of squares of the orbitals, is also printed. This may or may not correspond to the actual electron density of the Slater determinant, depending on what orbitals were selected.
There are some useful Python functions to manipulate CUBE files in qwalk/utils/readcube.py

*Required keywords*

Keyword | Type | Description |
---|---|---|

ORBITALS | section | A section for molecular orbitals. |

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

RESOLUTION | float | 0.2 | The resolution in Bohrs. Smaller is better resolution. |

PLOTORBITALS | section | all orbitals | Which orbitals to plot. The first orbital starts at 1. |

MINMAX | section | special | { xmin xmax ymin ymax zmin zmax }. By default, this is automatically set to include the entire system with some padding. |

## Plot 1D functions in the wave function

Keyword: PLOT1D

*Description:* Searches given trial wave function and plots its one-dimensional components. These are basically only one- and two-body terms in the Jastrow factor (group resolved). However, since these Jastrow_groups are used also as pair orbitals in the BCS wave function and as backflow transformations, the method is relatively widely applicable.
The method generates output file with suffix .plt1d (can be overridden with optional keyword SUFFIX). Discretized independent variable is the first column and then follow as many columns as plottable components found in the wave function. Column description is also included in the header of the output file. It looks something like

```
column description
distance
group 0, one-body, center LI
group 1, one-body, center LI
```

*Required keywords*

None

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

NGRID | integer | 100 | Number of grid points to use for the plotting |

SUFFIX | string | plt1d | Suffix of the output file |

## Postprocess trace files

Keyword: POSTPROCESS

*Description:* This method can evaluate operators on a trace file saved by DMC (or some other method). The trace file is expected to be a binary file laid out simply as the positions of each electron in (x,y,z) or der, followed by a single double that represents the weight of that walker. The file should be in C binary format (that is, no headers as in Fortran).

*Required keywords*

Keyword | Type | Description |
---|---|---|

READCONFIG | string | The name of the trace file from SAVE_TRACE (DMC) to read from. |

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

AVERAGE | section | empty | Section for an Average generator |

NOENERGY | flag | False | Do not calculate the energy of the walkers. This can improve the speed significantly. |

NSKIP | integer | 0 | Skip the first NSKIP configurations. This should be set to the number of warmup blocks times the number of configurations in the DMC run. The number of warmup blocks can be gotten by running gosling on the log file and counting how many blocks are thrown out. |

## Reptation Monte Carlo

Keyword: REPTATION

*Description:* This is an implementation of the Reptation Monte Carlo method (Baroni and Moroni, Phys. Rev. Lett. **82**, 4745 (1999)). There are quite a few modifications to the algorithm as presented in the above paper. Some are outlined in Pierleoni and Ceperley, ChemPhysChem 6 1872 (2005), most importantly the bounce algorithm. RMC is conceptually similar to DMC, in that we sample the distribution , with the projection operator interpreted as a random walk. At each end of the walk, we have sampled , the mixed distribution. In the center, we have , since on either side there are projection operators. DMC only moves forward, so the center distribution is unavailable, except by forward walking, which simulates the effect of projection operators. In RMC, the random variable is the path, which, for finite length, can be a probability density. Therefore, there's no branching and no population control bias. The biases (and speed) are controlled by the timestep(just like DMC) and the length of the path. The larger the timestep and shorter the reptile, the more efficient and inaccurate the simulation. For chemical systems, I've found a good starting point is a reptile about 3 au long, and a timestep around .01 au, which corresponds to TIMESTEP .01 and LENGTH 300. Note that you have to scale the length with the timestep to maintain total projection length.

RMC accumulates two estimators. label and label_cen. label contains the mixed estimators, which are useful for the total energy and correlated sampling energy differences. label_cen contains the pure estimator, which are useful for the local potential energy and polarization, as well as other properties that are specified with a DENSITY section(these automatically use the center estimator).

*Required keywords*

Keyword | Type | Description |
---|---|---|

TIMESTEP | float | A measure of how large each move should be. Adjust such that the acceptance ratio is about .99. Acceptance ratio is just a general guide, however, and it's useful to do several time steps if you need highly accurate results. |

NSTEP | Integer | Number of average points to take in a block. |

NBLOCK | Integer | Number of blocks to take |

LENGTH | Integer | Number of points in the reptile. Energy will be converged to LENGTH points, and all other quantities(density, potential, etc) will be converged to LENGTH/2 points. |

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

AVERAGE | section | empty | Section for an Average generator |

SAVE_TRACE | string | none | Every block, save the current configurations and their weights (in binary). Note that since this is a binary file, you may need to use the utility swap_endian (provided in utils) to change architectures. |

LABEL | string | dmc | Label in the .log file |

## Variational Monte Carlo

Keyword: VMC

*Description:* Evaluates the expectation value stochastically.

*Required keywords*

None

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

AVERAGE | section | empty | Section for an Average generator |

NCONFIG | integer | 1 | Number of sample points to use at one time per processor |

NSTEP | integer | 100 | Number of average points to take in a block. |

NBLOCK | integer | 100 | Number of blocks to take |

TIMESTEP | float | 1.0 | A measure of how large each Metropolis move should be. Adjust such that the acceptance ratio is somewhat greater than 0.5. If this is not specified, then the timestep will automatically be adjusted. |

NDECORR | integer | 2 | Number of Metropolis steps to take before evaluating the energy. Since VMC steps don't require an energy evaluation, this serves to decorrelate the averaging points before doing an expensive evaluation of the energy(mostly pseudopotentials). |

STORECONFIG | string | runid.config | Write the configurations to this file every block. |

READCONFIG | string | runid.config | Read from a configuration file previously written by STORECONFIG. If this file is absent, then new configurations will be generated. |

DENSITY | section | empty | Section for the evaluation of a density object |

*Advanced keywords*

Keyword | Type | Default | Description |
---|---|---|---|

GUIDETYPE | string | SUMSQUARES | Possible options include SUMSQUARES, FIRST. This only does anything if multiple wave functions are defined in the TRIALFUNC section. |

DYNAMICS | section | SPLIT | Choose a sampling strategy. Use UNR for all-electron calculations. |

## Generate Wannier functions

Keyword: WANNIER

*Description:* This method attempts to minimize the spread of the orbitals in periodic boundary conditions. It accomplishes this by maximizing the following value where the sum is over all orbitals, and where the k's are the reciprocal lattice vectors.
The orbitals are optimized by rotating the orbitals The matrix elements of M are allowed to be nonzero only between orbitals that are in the same ORB_GROUP.

*Required keywords*

Keyword | Type | Description |
---|---|---|

ORBITALS | section | A Molecular orbital section |

ORB_GROUP | section | The orbitals listed in this orbital group are allowed to mix. Can list multiple sections to define multiple mixing sectors. |

*Optional keywords*

Keyword | Type | Default | Description |
---|---|---|---|

RESOLUTION | float | 0.2 | The pitch (in Bohrs) of the grid used for integration. |

OUT_ORB | string | runid+.orb | Where the rotated orbitals will be stored. |