Re: [AMBER] cpptraj grid command

From: Thomas Fox <thomas_fox.gmx.net>
Date: Thu, 19 Nov 2015 18:09:56 +0100

   Hi Dan,

   thanks for taking care of this...its probably not just the truncating of the
   output, but also the shifting from the midpoint of the voxel to one of its
   vertices. Ideally the positions of the grid contours and the coordinates of
   the pdb file should be the same - if this is possible...after all with teh
   1A grid the shift from vertex to center means a displacement of 0.87A...

   Looking forward to any news,
   Th.

   Gesendet: Donnerstag, 19. November 2015 um 17:44 Uhr
   Von: "Daniel Roe" <daniel.r.roe.gmail.com>
   An: "AMBER Mailing List" <amber.ambermd.org>
   Betreff: Re: [AMBER] cpptraj grid command
   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
> [1]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
   [2]http://home.chpc.utah.edu/~cheatham/
   (801) 587-9652
   (801) 585-6208 (Fax)
   _______________________________________________
   AMBER mailing list
   AMBER.ambermd.org
   [3]http://lists.ambermd.org/mailman/listinfo/amber

References

   1. http://lists.ambermd.org/mailman/listinfo/amber
   2. http://home.chpc.utah.edu/~cheatham/
   3. http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 19 2015 - 09:30:04 PST
Custom Search