Hi Dan,
this is it, now I get - at least for the dx file - exactly what I would
expect. Just a little flaw: cpptraj still writes out the error message that
it doesnt recognize the keyword "bincenter", but runs through without
problem.
And your note that in the xplor file the grid needs to include the origin
also explains my observation that the xplor grid was somewhat (and
non-uniformly) shifted wrt to the dx grid, as in my original tests I used
non-integer coordinates for the box center.
Thanks again for the fast fix!
Th.
Gesendet: Samstag, 21. November 2015 um 00:02 Uhr
Von: "Daniel Roe" <daniel.r.roe.gmail.com>
An: "AMBER Mailing List" <amber.ambermd.org>
Betreff: Re: [AMBER] cpptraj grid command
Hi,
I've tried to address this issue in the GitHub version of cpptraj
([1]
https://github.com/Amber-MD/cpptraj) by adding some new keywords to
OpenDX output:
bincenter: Center grid points on bin centers.
gridwrap: Like 'bincenter', but also wrap grid density. Useful when
grid encompasses unit cell.
gridext: Like 'bincenter', but also print extra layer of empty bins.
You can put any of these keywords on the 'grid' command line (or a
'writedata' command line etc) and they will be picked up. E.g.
crdaction MyCoords grid grid.dx 10 1 10 1 10 1 gridcenter 20. 0.
50. :WAT.O pdb highdens.pdb max 0.8 bincenter
I've also changed the PDB output so that the box points (residues XXX)
occur at bin corners, not bin centers.
If you could give these a try and see if they work for you I'd
appreciate any and all feedback.
-Dan
PS - This was easy to do for OpenDX since you can specify the grid
origin, but not for Xplor since the Xplor grid has to pass through the
coordinate origin (0,0,0) so doing something like shifting the grid by
half the grid spacing is not possible.
On Thu, Nov 19, 2015 at 10:09 AM, Thomas Fox <thomas_fox.gmx.net> wrote:
>
> 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][2]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][3]http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> [3][4]http://lists.ambermd.org/mailman/listinfo/amber
>
> References
>
> 1. [5]http://lists.ambermd.org/mailman/listinfo/amber
> 2. [6]http://home.chpc.utah.edu/~cheatham/
> 3. [7]http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> [8]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
[9]
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
[10]
http://lists.ambermd.org/mailman/listinfo/amber
References
1.
https://github.com/Amber-MD/cpptraj
2.
http://lists.ambermd.org/mailman/listinfo/amber
3.
http://home.chpc.utah.edu/~cheatham/
4.
http://lists.ambermd.org/mailman/listinfo/amber
5.
http://lists.ambermd.org/mailman/listinfo/amber
6.
http://home.chpc.utah.edu/~cheatham/
7.
http://lists.ambermd.org/mailman/listinfo/amber
8.
http://lists.ambermd.org/mailman/listinfo/amber
9.
http://home.chpc.utah.edu/~cheatham/
10.
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Nov 25 2015 - 01:30:03 PST
