Hi,
On Wed, Nov 25, 2015 at 1:27 AM, Thomas Fox <thomas_fox.gmx.net> wrote:
> this is it, now I get - at least for the dx file - exactly what I would
> expect.
Glad it's working for you.
> Just a little flaw: cpptraj still writes out the error message that
> it doesnt recognize the keyword "bincenter", but runs through without
> problem.
Weird - I haven't seen this behavior. Can you send me your exact
cpptraj input so I can try to reproduce? Thanks!
-Dan
>
> 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
--
-------------------------
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 26 2015 - 06:00:03 PST
