VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Mar 31 2016 - 11:03:04 CDT

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/