Hi,
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
run
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.
:WAT.O
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
this...
Thanks a lot,
Th.
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
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 19 2015 - 05:00:04 PST
