amber-developers: Re: rms

From: Thomas Cheatham III <tec3.utah.edu>
Date: Tue, 12 Jun 2007 13:56:29 -0600 (Mountain Daylight Time)

Re: ptraj, erroneous results (overlapping waters) when using "image" after
an RMS fit. Followup to a user observation e-mailed personally to me.
Basically, if they RMS fit prior to imaging, the trajectory is hosed.

> I have a question about RMSd option of ptraj. I have an enzymatic system of
> 371 residues covalently bound to a sugar ligand(resid no:372) and explicit

[OK, we'll assume this isn't an accuracy issue related to not wrapping
(IWRAP=0) and finite precision of the box information; if waters have
moved multiple box lengths prior to imaging, small errors in the
positions/box multiply and you can have problems... But I think it is
something else more fundamental!]

What you have likely uncovered is an implicit bug or undocumented feature
that I hadn't really thought about (which is amazing since I've been using
the code for over a decade now...).

Specifically, the image command works in the frame of reference of the box
(which doesn't change) but the RMS command rotates this frame of
reference, hence you get a problem... This implies that you cannot do an
RMS fit prior to imaging (unless "nofit" is specified) as this changes the
coordinate frame of reference out of the box frame of reference. I will
definitely need to update the manual to point this out (and/or extend the
code to keep track of any rotation to keep box and coords in the
same frame of reference).

Visually, imagine a free rotor in a tall/thin box and it rotates by 90
deg.

  ----- -----
  | | | |
  | | | |
  | | | ---> |-- |
  | | | |
  | | | |
  ----- -----

if you RMS fit the rotor, it will spin the box by 90 deg.

  ------------
  | | | but the imaging still thinks it is still a tall box
  ------------

...this will lead to overlapping waters.

I've never imaged after the RMS fit (and still used the waters in a
calculation) so never thought about the discrepancy... To fix this, do
not rms fit prior to the image; I can try to implement something that
either rotates the box (which adds further numerical error, but may be
best) or which keeps track of rotations to allow unrotation of the
coordinates prior to imaging and then re-rotation following. I'll try to
think about which is easiest/quickest...

--tom
Received on Wed Jun 13 2007 - 06:07:35 PDT
Custom Search