[AMBER] cpptraj grid command

From: Thomas Fox <thomas_fox.gmx.net>
Date: Thu, 19 Nov 2015 13:43:05 +0100


   I believe I spotted an inconsistency how the grid command in cpptraj handles
   the output to grid and pdb files. Sorry for the long and winding post, but I
   havent found a way to describe this more concisely.

   In my example, I used the following cpptraj input (test.parm contains only a
   single structure):

     parm test.pdb
     trajin test.pdb
     createcrd MyCoords
     crdaction MyCoords grid grid.dx 10 1 10 1 10 1 gridcenter 20. 0. 50.
   :WAT.O pdb highdens.pdb max 0.8
     crdaction MyCoords grid grid.xplor 10 1 10 1 10 1 gridcenter 20. 0. 50.

   With cpptraj (version 15.00), I then get a pdbfile with the following grid
   box info:
      HETATM 9 XX XXX 9 15.500 -4.500 45.500 0.00 0.00

      HETATM 10 XX XXX 9 25.500 -4.500 45.500 0.00 0.00

      HETATM 11 XX XXX 9 15.500 5.500 45.500 0.00 0.00

      HETATM 12 XX XXX 9 25.500 5.500 45.500 0.00 0.00

      HETATM 13 XX XXX 9 15.500 -4.500 55.500 0.00 0.00

      HETATM 14 XX XXX 9 25.500 -4.500 55.500 0.00 0.00

      HETATM 15 XX XXX 9 15.500 5.500 55.500 0.00 0.00

     HETATM 16 XX XXX 9 25.500 5.500 55.500 0.00 0.00

   (BTW: I would rather use the residue name "GRID" for *these* entries in the
   pdb file, and
   not for the high density positions, but this is a different issue)

   In the dx output file, the grid definition is

     object 1 class gridpositions counts 10 10 10
     origin 15 -5 45
     delta 1 0 0
     delta 0 1 0
     delta 0 0 1

   i.e. the grid starts at the coordinate (15,-5,45) - so that the grid corner
   as defined in highdens.pdb is in the center of this voxel at the corner of
   the dx grid - , and then 10 steps are taken up to a max. x-value of 24.

   In the corresponding xplor file, the grid definition in the 4th line reads
       10 15 24 10 -5 4 10 45 54

   Again, as in the dx grid definition, I interpret this as follows: in the
   x-direction the grid runs from 15 -> 24, and not as written into the pdb
   file from 15.5 -> 25.5 (the difference between integer number or x.5 due to
   whether I use the lower corner of the voxel or the midpoint as reference).
   The corresponding is true for y- and z-direction.
   (From the Xplor-manual: AMIN, AMAX [ ...] indicate the starting and
   stopping grid points along each cell edge...)

   I believe the basic problem is that in the dx and xplor file, the number of
   grid*points* per direction need to be defined, whereas cpptraj uses
   internally (and outputs to the grid files) the number of *steps*or *bins* in
   a given direction, and these two numbers should differ by one, but do not.
   An alternative way to look at this would be the difference if I look at
   voxels or the vertices which define these voxels. (An even easier
   explanation would be sign error when transforming from the midpoint to
   vertex coordinates ?)

   The real problem of this is that this "compression" of the grid compared to
   the real size also shifts the high occupancy contours with respect to where
   they should be. So when I look at the grid information in e.g. pymol, it
   does not reflect what I see in the loaded structure or in the highdens.pdb
   file - this is extremely evident when I do the analysis with a single
   snapshot as above: here the peaks of the grid are up to 1.3 A away from the
   water positions which cause them.
   I agree that this is probably less of a problem when using smaller bin sizes
   than 1 A, but I need to feed the results into another program which assumes
   a 1A grid.

   Maybe someone could also educate me why if I load both grid.dx and
   grid.xplor into pymol, the two grid boxes are shifted by what looks about a
   little less than 1 A...but interestingly only in the x-direction...I know
   this is not an Amber question...

   It would be great if someone could look into this issue, and hopefully
   telling me that I am completely off ... and point out where I do
   something wrong when calculating and displaying/interpreting the results.
   Alternatively I would hope for a fast fix or idea for a way to get around

   Thanks a lot,

   PS: havent attached my in/out files as I believe this behavior should be
   easy enough to reproduce, but can easily send them out if so desired.
AMBER mailing list
Received on Thu Nov 19 2015 - 05:00:04 PST
Custom Search