CASINO manual - Theory of Condensed Matter

DMC REWEIGHT CONF (Logical) Update walker weights read in from config.in. Weights of
walkers are recomputed after reading config.in to correct for a modified wave function. This
allows continuous QMC-MD computations as described in PhysRevLett.94.056403.
DMC SPACEWARPING (Logical) Electronic positions are adjusted to follow the ionic positions
when adapting an existing population to a new wave function. The method follows the description
in PhysRevB.61.R16291 and is typically combined with dmc reweight conf.
DMC STATS NBLOCK (Integer) Number of blocks into which the DMC statistics accumulation
phase is divided (if dmc stats nstep is not divisible by dmc stats nblock, then the number
of steps will be increased to the nearest multiple of the number of blocks). Note that having
multiple blocks does not increase the amount of data collected, merely the frequency with which
data is written to files; the final answer should be the same, irrespective of the number of
blocks. Specifically, at the end of each accumulation block, the following significant actions are
performed:
(1) Write processor- and config-averaged data to dmc.hist (one line for each step in the current
block).
(2) Write processor- and config-averaged data to the expval.data file (if accumulating expectation
values other than the energy).
(3) Print monitoring data to the out file (block-averaged quantities).
(4) Make a backup copy of the config.out file (if catastrophe protection is turned on with the
dmc trip weight keyword).
(5) Make a backup copy of the expval.data file (if it exists, and if catastrophe protection is
turned on with the dmc trip weight keyword).
(6) Write the dmc.status file.
(7) Write the current state of the system, and all configurations in the current population to the
config.out file (note that by setting the checkpoint keyword to 0, this step can be skipped
until the end of the final block, or skipped completely if checkpoint=-1, but this is not the
default).
Note that having too many blocks will make the code slower, and if the run is not massively
long it is perfectly in order to have only one DMC stats block (which is the default).
DMC STATS NSTEP (Integer) Number of DMC steps performed on each processor in the statistics
accumulation phase, and consequently, the total number of local energy samples (averaged
over configurations and processors) written to the dmc.hist file. The accumulation phase may
be partitioned into dmc stats nblock blocks, but this does not affect the total number of steps
(just how frequently stuff is written out). However, if dmc stats nstep is not divisible by the
number of blocks, then it will be rounded up to the nearest multiple of dmc stats nblock. Furthermore,
dmc ave period consecutive local energies may be averaged together in DMC before
writing them to the dmc.hist file (hence reducing its size), but again, if dmc stats nstep is
not divisible by dmc ave period, it will be rounded up to the nearest multiple of it. Note the
difference in parallel behaviour compared to vmc nstep, which is not a per processor quantity;
this is because the DMC phase is parallelized over configurations.
DMC TARGET WEIGHT (Real) Total target weight in DMC, summed over all processors.
This is synonymous with the ‘target population’ of configurations, except that
dmc target weight is allowed to be non-integer. Typically dmc target weight will be the
same as vmc nconfig write when runtype= vmc dmc, though it does not have to be. 11
DMC TRIP WEIGHT (Real) In the course of a DMC simulation, it is possible for a configuration
‘population explosion’ to occur. If dmc trip weight is set to 0.0 then nothing will be done
about this. If dmc trip weight> 0 then the algorithm will attempt to restart the block (with a
different random number sequence) if the iteration weight exceeds dmc trip weight. A general
suggestion for its value would be three times dmc target weight (but see the discussion later
in the manual in Sec. 13.9 about this).
11 It may seem bizarre to allow non-integer total target weights, but a possible use for this is in increasing the parallel
efficiency when you have a very small population per core. Suppose your target weight is 1 configuration per core and
you are running on 100000 cores. Half the time your total population will be a bit higher than 100000, and when this
happens nearly all of your cores will spend half their time twiddling their thumbs waiting for the small number of cores
that have two configurations to finish the iteration. So around 25% of the computer time is wasted. If instead you set
your target weight to 0.98 configurations per core then it is very unlikely that any cores will have two configurations.
Instead you have on average 2% of your cores sitting idle, which is sad, but still more efficient than having large numbers
of cores wait for a small number of over-burdened cores.
40