I'm working on the fix if this is indeed a result of FPRE. My belief right
now is that NTP scaling of the restraint data causes it to contract and
expand and this cumulatively shrinks the box it occupies. This then causes
a pressure bleed by pushing the real atom coordinates towards the origin
and this then raises pressure. The real atom coordinates have the PE
function operating to prevent this from happening as a result of
pressure-scaling, but the restraint coordinates do not. I admit it's a
hypothesis, and if it's true, it also means that I would ultimately expect
to see this after hundreds of millions of iterations in full DP, but it's
currently the only thing I can think of that fits the bizarre behavior here
that doesn't manifest itself at all until 200K iterations or so and then
gradually heats things up.
I've seen similar behavior with transformation matrices in the past that
requires frequent renormalization. The solution I'm trying to is always
use the original but pre-centered restraint data, with the centers of mass
pre-transformed into fractional coordinates and then regenerating the
restraint coordinates for each step from the unit cell matrix.
Scott
On Thu, Dec 13, 2012 at 2:27 PM, Scott Le Grand <varelse2005.gmail.com>wrote:
> As noted in the bug report:
>
> 1) Pressure scaling is all done in one place for the GPU:
>
> kCalculateSoluteCOM(gpu);
> kPressureScaleCoordinates(gpu);
> if (gpu->sim.constraints > 0)
> {
> kCalculateSoluteConstraintsCOM(gpu);
> kReduceSoluteConstraintsCOM(gpu);
> kPressureScaleConstraintCoordinates(gpu);
> }
>
> Whatever's going on (and I suspect it's ultimately FPRE) it's not that or
> it would blow up a lot sooner...
>
> 2) While the else looks strange, it appears to be the end case for chain
> starting at line 1214 if (ntp .eq. 1) with an else if (ntp .eq 2) at line
> 1221 finished by the else at line 1257 (not my code though)...
>
>
> On Thu, Dec 13, 2012 at 11:40 AM, Duke, Robert E Jr <rduke.email.unc.edu>wrote:
>
>> Hmmm, all past my tenure on pmemd itself, as I expect you know. I am
>> buried in the amoeba code for right now, but will be interested in going
>> back to see what happened to pmemd in the time period I have not been
>> working on it when I get time. I would think the origin of npt could be
>> tracked down, and I would agree it is not the correct way to fix a typo...
>> It did not exist in Amber 10. Scott?
>> - Bob
>> ________________________________________
>> From: David A Case [case.biomaps.rutgers.edu]
>> Sent: Thursday, December 13, 2012 5:54 AM
>> To: amber-developers.ambermd.org
>> Subject: [AMBER-Developers] Oddities in runmd.F90 in pmemd
>>
>> (1) about the problem that occurs when ntr=1, ntp=1 on GPU:
>>
>> In the CPU code, when ntp>0 and ntr=1, there is a call to
>> pressure_scale_restraint_crds(). But there is no gpu equivalent to
>> this.
>> Assuming that the restraint coordinates acutally used are the ones on
>> the
>> gpu(?), this looks like an error.
>>
>> (2) There are several places where a specific if has been commented out,
>> and replaced with a generic else: e.g. at about line 1257:
>>
>> !else if (npt .gt. 2) then
>> else
>>
>> Is there a reason for this? the effect of the above changes is that
>> the following section is run even when ntp = 0, which looks wrong. Is
>> it
>> just that "npt" above is a typo (should be "ntp"), and was fixed in a
>> funny way? Similar thing happens (but with no typo) for the
>> csurften==3
>> option.
>>
>> ...thx...dac
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Dec 14 2012 - 09:00:02 PST
