The PDB and PQR formats look superficially similar but really are
quite different. The PQR format originated in the MEAD software
package, where the current code for reading an ATOM or HETATM line is:
n = sscanf (linebuf, "%*s %*d %s %s %d %f %f %f %f %f %s",
wbuf1, wbuf2, &at.resnum, &at.coord.x, &at.coord.y, &at.coord.z,
&at.charge, &at.rad, wbuf3);
where wbuf1, wbuf2 and wbuf3 become atom name, resname, and chainid,
respectively. The chainid is optional field that we introduced in
2001. Here I see that we and PDQ2PQR have diverged. Their docs show
a new optional chainID field that has chainID in-between residue name and
residue number, while our chainID is at the end of the line after radius
Note the absence of any field-width specifiers or mandatory non-space
characters in our code. Thus, this is a simple free format (fields
delimited by arbitrary numbers of spaces) of the kind that awk or
perl can easily process. PDB2PQR's version of the PQR format is also
free format.
In contrast, the PDB format is strict about spacing and column
numbers, so at the very least, you'd need to fix that up. This would
include reducing the precision of the charge and radius fields, which
won't be interpreted as such by leap anyway. Leap uses the format:
"%6 %5d %4s%c%3s %c%4d%c %8f%8f%8f%6f%6f %3d"
which is more consistent with the PDB rules, although it has
exceptions for overflows of atom and residue numbers.
You might wonder why MEAD put the chainID at the end rather than in
the PDB-specified order. It's because PDB allows chainID and resSeq
to have no space separating them (the "%c%4d" in the above format, and
this is not compatible with the a free format. Also, it's just easier
to support something optional at the end rather than in the middle.
I'm not sure this was really the best choice, but that's where it
stands now.
Don Bashford
Saint Jude Children's Research Hospital
Memphis
At Thu, 9 Jun 2011 05:03:20 -0500,
Azat Mukhametov wrote:
>
> Yes, it looks that something is wrong with data in PQR file (see below):
>
> We use it to assign protonation stage at given pH value (8.5). But it
> creates PQR output, not PDB.
>
> OK, I'll try to fix problem. Thanks!
>
>
> REMARK 1 PQR file generated by PDB2PQR (Version 1.7)
> REMARK 1
> REMARK 1 Forcefield Used: amber
> REMARK 1 Naming Scheme Used: amber
> REMARK 1
> REMARK 1 pKas calculated by propka and assigned using pH 8.50
> REMARK 1
> REMARK 5 WARNING: Propka determined the following residues to be
> REMARK 5 in a protonation state not supported by the
> REMARK 5 amber forcefield!
> REMARK 5 All were reset to their standard pH 7.0 state.
> REMARK 5
> REMARK 5 N-terminal N+ 43 A (neutral)
> REMARK 5
> REMARK 5
> REMARK 6 Total charge on this protein: -5.0000 e
> REMARK 6
> ATOM 1 N GLY A 43 15.790 10.898 22.016 0.2943 1.8240
> ATOM 2 CA GLY A 43 15.226 9.598 22.436 -0.0100 1.9080
> ATOM 3 C GLY A 43 16.346 8.666 22.835 0.6163 1.9080
> ATOM 4 O GLY A 43 17.442 9.129 23.131 -0.5722 1.6612
> ATOM 5 H2 GLY A 43 15.526 11.601 22.676 0.1642 0.6000
> ATOM 6 H1 GLY A 43 16.787 10.828 21.979 0.1642 0.6000
> ATOM 7 H3 GLY A 43 15.435 11.134 21.112 0.1642 0.6000
> ATOM 8 HA2 GLY A 43 14.611 9.746 23.211 0.0895 1.1000
> ATOM 9 HA3 GLY A 43 14.710 9.207 21.674 0.0895 1.1000
> ATOM 10 N SER A 44 16.086 7.375 22.720 -0.4157 1.8240
> ATOM 11 CA SER A 44 17.013 6.330 23.102 -0.0249 1.9080
> ATOM 12 C SER A 44 17.433 5.547 21.868 0.5973 1.9080
> ATOM 13 O SER A 44 16.611 5.320 20.974 -0.5679 1.6612
> ATOM 14 CB SER A 44 16.337 5.382 24.057 0.2117 1.9080
> ATOM 15 OG SER A 44 17.122 4.222 24.244 -0.6546 1.7210
>
>
>
> On Thu, Jun 9, 2011 at 4:36 PM, David A. Case <case.biomaps.rutgers.edu>wrote:
>
> > On Thu, Jun 09, 2011, Azat Mukhametov wrote:
> >
> > > I use another computer for calculations, just checked:
> > > I used:
> > > prot = loadpdb prot.pqr
> > > It gives huge number of warnings and mistakes
> >
> > Can you look carefully at the first few error messages, and/or post the
> > beginning of your pqr file? A wild guess is that PDB2PQR is putting out an
> > odd format, not really compatible with pdb, or perhaps with the Amber
> > libraries.
> >
> > I'm not sure I understand the original problem: why not use the pdb file
> > that
> > you used for input to PDB2PQR? Or is there some other reason you have a
> > pqr
> > format file, but not a pdb format file?
> >
> > ....dac
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
Email Disclaimer: www.stjude.org/emaildisclaimer
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jun 09 2011 - 11:00:03 PDT
