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" <ross.rosswalker.co.uk> 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 <daniel.r.roe.gmail.com> wrote:
> >
> > On Wed, Nov 8, 2017 at 2:46 PM, David Cerutti <dscerutti.gmail.com>
> wrote:
> >> I THINK IT'S A BUG FIX:
> >> 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
> > https://www.lobos.nih.gov/lcb
> >
> > _______________________________________________
> > 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 Wed Nov 08 2017 - 15:00:02 PST
