VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Apr 01 2016 - 13:42:27 CDT

Norman,
  Yes, I totally agree that the "***" isn't desirable, so your suggestion of
restarting numbering at that point (or switching to yet another residue
labeling scheme) makes sense to me.

Cheers,
  John

On Fri, Apr 01, 2016 at 08:54:51AM +0200, Norman Geist wrote:
> Hey John,
>
> you are right, there's no "best" way to overcome the PDB format limitations,
> and actually our own codes don't care about hex numbers, duplicates or
> whatsoever. The major problem I tried to point out, was that at some point
> VMD starts writing only "****" instead of numbers, for residues following
> each other, which causes an unrecoverable information loss. The information
> of how to split residues based on the information only gotten from the
> PDB/GRO file. Do you agree that this is unwanted behavior?
>
> So both file format writers, start to fail at some amount of residues,
> causing **** in PDB and totally weird numbers in GRO.
>
> Norman Geist
>
> > -----Ursprüngliche Nachricht-----
> > Von: John Stone [mailto:johns_at_ks.uiuc.edu]
> > Gesendet: Donnerstag, 31. März 2016 18:03
> > An: Norman Geist <norman.geist_at_uni-greifswald.de>
> > Cc: VMD Mailing List <vmd-l_at_ks.uiuc.edu>
> > Betreff: Re: vmd-l: Residue numbers in outfiles PDB/GRO
> >
> > Hi,
> > The PDB file format technically does not allow anything beyond the
> > normal field with using standard decimal notation, so there should be
> > little or no expectation that any software would be able to read a
> > non-standard PDB file.
> >
> > That being said, as Norman point out, if one is willing to "abuse"
> > the PDB format, then schemes like hexadecimal numbering or other
> > approaches
> > become interesting. Also as Norman pointed out, such schemes can create
> > problems for other software.
> >
> > It's not clear to me that restarting the PDB residue numbering
> > from 1 (wrapping around) when the field width would be exceeded would
> > be much better, as I am aware of other programs that don't like this
> either,
> > although I think they can also have problems with duplicate residues and
> > other things that do show up in the PDB.
> >
> > I might be more convinced to make changes to the plugins if more
> > information
> > could be provided about what software programs are affected by the
> > proposed changes. Clearly Norman has such a case. Are there others
> > that people are aware of?
> >
> > I'm personally not terribly interested in making growing numbers of
> > hacks to the VMD PDB plugin to support the large variety of schemes
> > that might be required to make non-standard files readable by certain
> > programs. VMD supports many other file formats, several of which don't
> > have
> > the very restrictive field widths that PDB does.
> > It is pretty easy to add new plugins to VMD to support native file formats
> > used by other software that don't have the restrictions that PDBs (or GRO)
> > do
> > if we can get information on their native file structures.
> >
> > Norman, if you could say more about the software you're using and whether
> > it
> > has support for file formats that are less restrictive than PDB/GRO,
> writing
> > a new VMD plugin might be a much more desirable approach than
> > continuing to
> > use "more duct tape" to make the PDB and GRO plugins write non-standard
> > files
> > that are "less objectionable" to certain software on a case-by-case basis.
> > If it can't be helped and the PDB/GRO plugins are the only option, then at
> > least we could add some environment variables and documentation into the
> > VMD User's Guide so that users could control the behavior of the non-
> > standard
> > PDB formatting at runtime by setting environment variables or other
> > schemes
> > that would let them choose the outcome somehow.
> >
> > Cheers,
> > John Stone
> > vmd_at_ks.uiuc.edu
> >
> >
> >
> >
> > On Wed, Mar 23, 2016 at 12:19:22PM +0100, Norman Geist wrote:
> > > To the developers,
> > >
> > >
> > >
> > > I'd like to report that VMD writes very unuseful values to the
> residue
> > > numbers column in PDB and GRO format, when the system size very
> > large.
> > > Instead of simple restarting the numbering from 1 it uses hexadecimal
> > > values, which is a problem for some PDB reader codes. The main BUG
> > IMHO
> > > is, that after also the hexadecimal values run out, VMD seems to use
> any
> > > characters to continue the numbers and starts using only sequences of
> > ****
> > > for consecutive residues, making the residue number completely
> > useless to
> > > detect different residues.
> > >
> > >
> > >
> > > So basically I think the numbers should just restart from 1 when
> reaching
> > > 9999. So any other PDB/GRO reader can simply count on its own, having
> > the
> > > reliable changing residue identifier.
> > >
> > >
> > >
> > > Best wishes
> > >
> > >
> > >
> > > Norman Geist
> > >
> > >
> >
> > --
> > NIH Center for Macromolecular Modeling and Bioinformatics
> > Beckman Institute for Advanced Science and Technology
> > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> > http://www.ks.uiuc.edu/Research/vmd/
> 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/