Re: [AMBER-Developers] NMR restraints and re-imaging

From: David Cerutti <>
Date: Wed, 8 Nov 2017 17:38:30 -0500

* possibility of adding this feature at a later date.

On Nov 8, 2017 5:37 PM, "David Cerutti" <> wrote:

> Yes, I misinterpreted what I was reading. I haven't messed anything up
> but I was seeing pImage arrays and forgetting that those are merely the
> infinitely diffusing coordinates, not reimaged in any way. I knew there
> were pitfalls either way and had actually written the email from the
> perspective Dan pointed out before thinking I needed to correct it.
> But with the infinitely diffusing array there is what Ross pointed
> out--particles can overrun their own images with a long distance restraint
> in umbrella sampling. I can leave it as is with the availability of this
> feature.
> Dave
> On Nov 8, 2017 3:50 PM, "Ross Walker" <> wrote:
>> Hi Dan,
>> Yes this was my understanding as well. The coordinate array is never
>> imaged. A molecule moving out of a box just continues to get larger and
>> larger coordinates. Fractional coordinates are then used in the direct
>> space sum etc to make sure the nearest 'image' molecule is used in the
>> calculation. So I think the question would be if an internal coordinate -
>> say length between the center of mass of two molecules was not strong
>> enough to counter those two molecules moving apart what would happen once
>> they moved more than a box length apart? It depends on if the NMR restraint
>> code is using the absolute coordinates or fractional coordinates. That said
>> in this example would the two molecules not eventually run into their own
>> images?
>> Note spanning the box with bonds is something we thought about many years
>> ago when simulating cellulose sheets. If one just uses the fractional
>> coordinates in the bond calculation it works although any visualization etc
>> in VMD for example is messed up. I hacked something together in Sander at
>> the time to do this but the problem was it made results highly dependent on
>> box size. The Cellulose sheet would act like a drum skin and vibrate at a
>> frequency that was a function of the box size. So it didn't act as an
>> infinite sheet in the way I naively imagined it would. I also didn't take
>> the time to go through the calculation by hand and figure out if angles and
>> dihedrals were being handled properly at the boundary - or indeed even
>> figuring how they should work in theory. Thus while it would be nice to
>> have this functionality I am not sure how useful it is in practice, it
>> needs thinking about carefully to make sure valence terms aren't being
>> double counted or missed and even if done formally correctly it might mean
>> people build what they think are infinite systems but really aren't.
>> All the best
>> Ross
>> > On Nov 8, 2017, at 3:37 PM, Daniel Roe <> wrote:
>> >
>> > On Wed, Nov 8, 2017 at 2:46 PM, David Cerutti <>
>> wrote:
>> >> The current setup re-images all coordinates, molecule by molecule,
>> relative
>> >> to a single reference frame, then applies the NMR restraints (and any
>> >> bonded interactions) to those coordinates. Bonds are safe, but if an
>> NMR
>> >> restraint applies between two separate molecules, there is a slim
>> chance
>> >> that they will have been re-imaged in a way that suddenly puts an
>> >> additional box length between them. So the proposed change, which
>> would
>> >
>> > I'm in the middle of an office move today so I don't have time to look
>> > at this in-depth right now, but I was under the impression that
>> > sander/pmemd only ever image coordinates for output (not internally).
>> > This is why a simulation with restraints will work for an initial run
>> > but sometimes not for the restart. I've got several DNA-stretching
>> > runs where this was in fact the case, unless the code has been
>> > significantly modified since then.
>> >
>> > -Dan
>> >
>> > --
>> > -------------------------
>> > Daniel R. Roe
>> > Laboratory of Computational Biology
>> > National Institutes of Health, NHLBI
>> > 5635 Fishers Ln, Rm T900
>> > Rockville MD, 20852
>> >
>> >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> >
>> >
>> _______________________________________________
>> AMBER-Developers mailing list
AMBER-Developers mailing list
Received on Wed Nov 08 2017 - 15:00:03 PST
Custom Search