From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Mon May 04 2015 - 07:04:22 CDT
On Mon, May 4, 2015 at 7:47 AM, Maxim Igaev
> Hi Jerome,
> thanks for your reply! This is a good point. The other software can
> process different PDB conventions. I don't know which one accepts atom
please note that there is only one PDB standard, which doesn't accept
atom ids beyond 99999.
to confirm to the standard, you have to split your system into
> IDs in hexadecimal format though. But I will try. A hardcore way would
> anyway be to maually convert the second column in the PDB file into DEC
> with a Python script =)
that cannot work, since you'll be overflowing the format. VMD switches
to hex numbering exactly to avoid that. since the output would be
bogus (i.e. not conforming to the PDB standard) in any case, this way
still the format is preserved (until hex numbers will overflow) and at
least software that ignores the atom id can still read the file.
>> Hi Maxim,
>> There is no standard way to handle indices beyond 99999, so I don't
>> think VMD implements anything else. The whole format is based on
>> constant field widths though, so increasing one of them seems likely
>> to break everything. You probably need to either use a different file
>> format, or find out the convention that your other software uses for
>> large PDB files, and manually convert PDB files to follow that
>> On 4 May 2015 at 10:16, Maxim Igaev
>> <maxim.igaev_at_biologie.uni-osnabrueck.de> wrote: Hi,
>> I have a question concerning atom IDs (the second column in a PDB
>> file). After generating the pdb/psf pair for a big molecular structure
>> in VMD and visually inspecting the PDB file, I noticed that starting
>> with atom ID 99999 the numbering switches from DEC to HEX, i.e. after
>> 99999 comes 186a0. So this part of PDB looks like this:
>> ATOM 99997 CD1 LEU A 428 ...
>> ATOM 99998 HD11 LEU A 428 ...
>> ATOM 99999 HD12 LEU A 428 ...
>> ATOM 186a0 HD13 LEU A 428 ...
>> ATOM 186a1 CD2 LEU A 428 ...
>> ATOM 186a2 HD21 LEU A 428 ...
>> I know, this is probably meant to keep colums in PDB properly aligned.
>> The problem is that I need to use the same PDB for simulations with
>> another package, and this package cannot read such a PDB in, giving a
>> runtime error like
>> line 4750 in readpdb.f90:
>> Bad value during integer read
>> Does anyone know whether there is a way to tell VMD to not switch to
>> HEX after 99999?
>> Thanks in advance!
>> Maxim Igaev, MSc.
>> Department of Neurobiology
>> University of Osnabrueck
>> Barbarastr. 11
>> 49076 Osnabrueck
>> Phone: +49 (0)541-969 2863
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.
This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:21:06 CST