From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Mar 31 2016 - 14:49:49 CDT

Hi,
  We have a reader for the PDBx/mmCIF format in the new VMD 1.9.3 builds,
however the writing part is not finished. I would have suggested this,
except that almost no existing tools actually have robust PDBx readers yet,
and the PDBx format has some non-trivial differences from PDB. That being
said, I hope we will have the PDBx writing code done soon, if not in time
for the 1.9.3 release, then sometime soon thereafter.

Cheers,
  John

On Thu, Mar 31, 2016 at 08:31:36PM +0200, Daniel Möller wrote:
> Hi,
>
> if you want to change the pdb plugin, what's with the 'new' pdb-format with
> xml basis pdbml? (http://pdbml.rcsb.org/ or
> http://www.wwpdb.org/documentation/file-format)
> Wouldn't it be better to change to a pdb-format that's developed to overcome
> the disadvantage of the old pdb-format?
>
>
> Sincerely
>
> Daniel Möller
>
>
> -----Ursprüngliche Nachricht-----
> Von: owner-vmd-l_at_ks.uiuc.edu [mailto:owner-vmd-l_at_ks.uiuc.edu] 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
>
> 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/