From: Norman Geist (
Date: Fri Apr 01 2016 - 01:54:51 CDT

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 []
> Gesendet: Donnerstag, 31. März 2016 18:03
> An: Norman Geist <>
> Cc: VMD Mailing List <>
> 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
> 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,
> 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
> 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
> 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
> > 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
> 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
> Phone: 217-244-3349