<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head></head><body><div style="font-size: 12pt; font-family: Calibri,sans-serif;"><div id="htc_header">----- Reply message -----<br>From: "David van der Spoel" <spoel@xray.bmc.uu.se><br>To: <gromacs.org_gmx-developers@maillist.sys.kth.se><br>Subject: [gmx-developers] Brainstorming ideas for minimally painless incorporation of an MC barostat (later MC moves in general)<br>Date: Thu, Jul 17, 2014 17:52</div></div><br><pre style="word-wrap: break-word; white-space: pre-wrap;">On 2014-07-17 16:41, Berk Hess wrote:
> I understand that the virial is not needed for the pressure scaling
> itself, but it will usually be calculated for reporting at a scaling
> step, so we need to get it right, also with constraints.
Is there any reason not to use molecular (center of mass) scaling to
avoid meddling with constraints?</pre><pre style="word-wrap: break-word; white-space: pre-wrap;">Yes: periodic molecules and COM (pull) constraints.</pre><pre style="word-wrap: break-word; white-space: pre-wrap;">Berk</pre><pre style="word-wrap: break-word; white-space: pre-wrap;">
>
> If we don't want to calculate the force 3x when a MC step is rejected,
> we can directly reuse the storing mechanism implemented in minimize.c.
>
> Cheers,
>
> Berk
>
> On 07/17/2014 04:20 PM, Shirts, Michael R. (mrs5pt) wrote:
>> Hi, all-
>>
>>>> a. For a MC barostat, no communication between nodes is
>>> required, as
>>>> atoms are guaranteed stay on the same node -- everything only
>>>> changes by
>>>> scaling
>>> This is not really true, since when constraints are present, these need
>>> to be applied after scaling, which leads to (minor) coordinate changes
>>> and requires communication. But we can probably do this without changing
>>> the decomposition.
>> Hmm. Maybe this can be avoided. If the centers of coupled constraint
>> system were scaled, rather than all atoms, then no iterative constraining
>> would be required. . . If these constraint data structures already
>> contain
>> these sets of coupled constraints, then it would be easy to do this.
>> Note
>> that this is very close to molecular scaling.
>>
>> If all atoms were scaled, then yes, any coordinate change would be minor
>> and could likely be handled by the same communication algorithm.
>>
>>
>>
>>> I don't think any changes are needed for the forces.
>>> The constraining and calculating virial contributions are probably the
>>> most tricky parts.
>> One great thing about a MC barostat is that no virtual contribution is
>> needed for the accept/reject step. One never calculates the pressure,
>> only the change in (E(T(x,p) + PV(T(x,p))), where T(x,p) is some
>> transformation of the coordinates and the momentum. where V(T(x,p)) is
>> the
>> new volume after the transformation, and E(T(x,p)) is the total energy
>> after the transformation. The pressure is the applied pressure, and is a
>> constant. You also need to include a Jacobian factor calculated from
>> T(x,p) in the accept/reject criteria.
>>
>> There are two main choices I've seen for T(x,p) -- one leaves the
>> momentum
>> in place, and just scales the coordinates. For isotropic, no
>> constraints,
>> then the Jacobian factor (this may be off by a factor of V) is
>> (Vold_/Vnew)^N-1. If the momentum are scaled in the opposite
>> direction of
>> the coordinates, then the Jacobians cancel. Parrinello-Rahman is
>> essentially a infinitesimal version of this second process. For
>> constraints, then the exponent on V changes.
>>
>> The virial would only need to be calculated in the normal place, to
>> report
>> the average pressure, and would not be required to be calculated in the
>> accept-reject step.
>>
>>
>> The OpenMM developers have been playing around with choices for the MC
>> barostat, and I can get their opinions on which of these choices has
>> worked best.
>>
>> There biggest reason I haven't dived into this yet is that I'm still
>> trying to get my mind around how the data structures for the force
>> calculation should be saved and destroyed when accepting and rejecting in
>> a efficient way. That's the biggest roadblock for me. Once I understand
>> how to do that (or someone else makes any changes necessary for that),
>> then I can probably at least get a single node version up and running and
>> validated for correct statistical mechanics in a relatively short time.
>>
>> Best,
>> ~~~~~~~~~~~~
>> Michael Shirts
>> Assistant Professor
>> Department of Chemical Engineering
>> University of Virginia
>> michael.shirts@virginia.edu
>> (434)-243-1821
>>
>>
>>
>
--
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.
spoel@xray.bmc.uu.se <a href="http://folding.bmc.uu.se">http://folding.bmc.uu.se</a>
--
Gromacs Developers mailing list
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists">http://www.gromacs.org/Support/Mailing_Lists</a>
* For (un)subscribe requests visit
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to gmx-developers-request@gromacs.org.
</pre></body></html>