VMD-L Mailing List
From: Norman Geist (norman.geist_at_uni-greifswald.de)
Date: Fri Apr 01 2016 - 01:54:51 CDT
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.
> -----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
> 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
> 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
> 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
> 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
> 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)
> if we can get information on their native file structures.
> Norman, if you could say more about the software you're using and whether
> has support for file formats that are less restrictive than PDB/GRO,
> 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
> 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-
> PDB formatting at runtime by setting environment variables or other
> that would let them choose the outcome somehow.
> John Stone
> 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
> > numbers column in PDB and GRO format, when the system size very
> > Instead of simple restarting the numbering from 1 it uses hexadecimal
> > values, which is a problem for some PDB reader codes. The main BUG
> > is, that after also the hexadecimal values run out, VMD seems to use
> > 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
> > 9999. So any other PDB/GRO reader can simply count on its own, having
> > 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