Feature #1562

introducing a Monte Carlo framework (first application: MC barostat)

Added by Michael Shirts almost 5 years ago. Updated almost 3 years ago.

Target version:


This is being broken off from issue #1137:

Creating a MC framework along the lines of:

do from n=0 to nstep
save the energy (and optionally forces) for next iteration
(accept/reject) (MD is a 100% acceptance, others are and based on new energy and previous energy )
If reject, return to backup state
save trajectory and energy information
copy the state into a state_old
propose a new configuration (in MD, is N steps of MD integrator)

The first practice case would be for an MC barostat. As we eliminate the iterative constraint pressure control method, it will be important to introduce a replacement in-theory-exact barostat for systems with constraints, and as discussed, and MC barostat is the best replacement.

For an MC barostat, this becomes specifically:

Every nstpcouple steps:
  1. Compute the energy (force may not be needed - will have to think about combinations with MD)
  2. Modify the coordinates (optionally the velocities, depending on the flavor of MC barostat)
    1. For a MC barostat, no communication between nodes is required, as atoms are guaranteed stay on the same node -- everything only changes by scaling
    2. For general MC moves (will likely be best to eventually make it general) communication between notes might be required.
  3. Reevaluate the energy
  4. Accept/reject based on energy difference (may require some other Jacobian terms). KEY PART: 'reject' reverts the system to state before the proposal
  5. Continue

What will need to change in the way the forces are calculated for this to be possible? What other changes?


#1 Updated by Michael Shirts over 4 years ago

One question that came up in discussion over email is how much communication there would need to be between node to do an MC barostat. Since moves are global, then at least without constraints, the only communication required for force recalculation and total energy summation.

With constraints, it becomes more complicated. The simplest (and perhaps most physical) way to handle the box move is to move the centers of mass of constraint groups, while keeping intramolecular distances fixed -- the constraints would then be satisfied both before and after the move.

The one communication issue here is that a constraint group split between nodes does not necessarily know its center of mass, so that it can know how much to shift each atom by. The solution would be to compute the center of mass when the constraints are performed, and store it with the copy of the constraint group on each node. That should be extremely cheap to compute, and not take too much storage or communication. It's not entirely clear if that's the best way to handle things, or even 100% possible, but does at least put bounds on the minimum amount of information that must be stored.

With nonisotropic box moves, it might also be important to rotate each constraint group around the COM, but that can likely be handled later, and still should just require knowledge about the COM.

#2 Updated by Rodrigo Antonio Faccioli over 4 years ago

In [1] is described the implementation of Monte Carlo Metropolis in which GROMACS is an external program for computing the physical properties of protein configurations.

New configurations are generated by 4 movements: phi, psi, omega and chi. Residues and type of movements are chosen randomly. In ([[ ]]) is an example of these movements.

[1] [[]]

#3 Updated by Mark Abraham almost 3 years ago

  • Target version deleted (5.x)

Also available in: Atom PDF