From: Daniel Möller (
Date: Thu Mar 31 2016 - 13:31:36 CDT


if you want to change the pdb plugin, what's with the 'new' pdb-format with
xml basis pdbml? ( or
Wouldn't it be better to change to a pdb-format that's developed to overcome
the disadvantage of the old pdb-format?


Daniel Möller

-----Ursprüngliche Nachricht-----
Von: [] Im Auftrag 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

  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
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.

  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 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
> characters to continue the numbers and starts using only sequences of
> for consecutive residues, making the residue number completely useless
> 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           Phone: 217-244-3349