Hi,
A cursory examination of what you say seems to be right (the issue
being grid points versus grid bins) - if so, then cpptraj is
essentially truncating grid output one bin in each direction (not
compressing, right?). I'll look into it further and get back to you.
Thanks for the detailed report!
-Dan
On Thu, Nov 19, 2015 at 5:43 AM, Thomas Fox <thomas_fox.gmx.net> wrote:
>
> 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
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 19 2015 - 09:00:06 PST
