The ForceBiasMove classes used by both the pscf_pc and pscf_pg programs implements a MC move for which the attempted move is generated by an explicit Euler Brownian dynamics step

Two closely analogous classes named Pscf::Rpc::ForceBiasMove and Pscf::Rpg::ForceBiasMove that are defined in different namespaces are used to implement this move algorithm for different programs. The ForceBiasMove class defined in the Rpc namespace is used in the pscf_pc program (using CPU hardware) and the class defined in the Rpg namespace is used in the pscf_pg program (using GPU acceleration). These two classes implement the same step algorithm and use the same parameter file format, which are documented below.

See also: ForceBiasMove (class API)

Step Algorithm

A general discussion of MC move algorithms for PS-FTS is given on a separate page. As discussed there, each move consists of an unconstrained change in the fields, followed by application of a compressor to re-impose the incompressibility constraint. The decision about whether to accept or reject the move is based on the value of the Hamiltonian after incompressibility has been restored.

The ForceBiasMove uses an explicit Euler Brownian dynamics (BD) step as an unconstrained move. The explicit Euler BD move is identical to the one implemented by the ExplicitBdStep class defined in either the Rpc or Rpg namespace. The only parameter required to generate such an attempted move is the mobility parameter used in this underlying BD step. This parameter is denoted by the label "mobility" in the parameter file and in the source code, and by the symbol \( \gamma \) in mathematical formulas.

The change in \( W_{-}({\bf r}) \) generated by an explicit BD step is given by the sum

\[ \Delta W_{-}({\bf r}) = - \gamma \delta H/\delta W_{-}({\bf r}) + g({\bf r}) \]

of a Gaussian distributed random component \( g({\bf r}) \) plus a "force bias" \( -\gamma \delta H/\delta W_{-}({\bf r}) \).

The acceptance criterion for a ForceBiasMove is designed to satisfy detailed balance by taking into account the effect of the force bias on both the probability of generating a specific change \( \Delta W_{-}({\bf r}) \) and the probability of generating the hypothetical reverse move starting from the final state obtained at the end of the attempted move, after adjustment of \( W_{+} \) so as to satisfy the partial saddle-point constraint. Evaluation of the acceptance probability thus requires evalatuation of the force bias (i.e., the functional derivative) as well as the Hamiltonian value in the final state that is obtained after applying the compressor algorithm.

The use of a force bias allows for much higher acceptance rates than those obtained from the RealMove, for choices of parameters that yield similar magnitude changes in the fields.

Parameter File

The only parameters needed by this algorithm are the "probability" parameter, which determines the probability that a move of this type will be attempted, and a required parameter named "mobility", which is the mobility parameter of the explicit BD step. A typical example of an associated parameter file block is shown below.

ForceBiasMove{
  probability   0.5
  mobility      0.005
}

The format for this block is thus:

ForceBiasMove{
  probability  float (in range [0,1])
  mobility     float
}

The meanings of both parameter are summarized briefly below:

Label	Description
probability	probability of attempting a step of this type
mobility	Mobility parameter of underlying attempted BD step