#121 support for PQR

closed
5
2007-05-02
2007-05-01
No

It would be interesting to add support for opening files in the PQR format. This is a derivative of PDB that adds charge and radius. PDB is converted to PQR by PDB2PQR and derivatives, programs that estimate charge distribution (and also add hydrogens). PQR is then used as input by APBS, a program that calculates molecular electrostatic map and exports it in DX format, which can be used by Jmol to color a molecular surface.
PQR keeps most of the PDB format except that it puts charge more or less in the occupancy location, and radius shifted but close to the B factor location.

The addition of hydrogens and the calculation of charges make this format interesting to be read by Jmol.

Description of the PQR format is at http://apbs.sourceforge.net/doc/user-guide/index.html#pqr-format
There are plain text and XML variants.

(Note> I have detected some problems with added hydrogen atoms labelled e.g. HG22, which are interpreted as mercury by Jmol due to column shift, but for the rest the files are read OK, except that color temperature is incorrectly interpreted, due to wrong columns.)

Discussion

  • Angel Herraez

    Angel Herraez - 2007-05-01

    created from 1fas.pdb using PDB2PQR included in Gemstone

     
  • Angel Herraez

    Angel Herraez - 2007-05-01

    Logged In: YES
    user_id=1065324
    Originator: YES

    Example PQR file
    File Added: 1FAS.pqr

     
  • Angel Herraez

    Angel Herraez - 2007-05-01

    Logged In: YES
    user_id=1065324
    Originator: YES

    I am puzzled: the official PDB2PQR page
    http://pdb2pqr.sourceforge.net/userguide.html
    says
    "A PQR file is a PDB file with the temperature and occupancy columns replaced by columns containing the per-atom charge (Q) and radius (R)."
    However, when I run a PDB file (1fas) through the PDB2PQR server, I get a file that in the occupancy columns has positive and negative values, -1.0 to +1.0, which must be charges, and the temperature (B factor) columns are partially covered by thos and partially (one position to the right of decimal point) filled with values that look like the radii.

    I will try to find out more with the PDB2PQR people.

     
  • Bob Hanson

    Bob Hanson - 2007-05-01

    Logged In: YES
    user_id=1082841
    Originator: NO

    What you mean, I think, is that Jmol is almost reading the PQR format, but not quite.

    From that reference site I see:

    A.1.1. PQR flat-file format

    This format is a modification of the PDB format which allows users to add charge and radius parameters to existing PDB data while keeping it in a format amenable to visualization with standard molecular graphics programs. The origins of the PQR format are somewhat uncretain, but has been used by several computational biology software programs, including MEAD and AutoDock. UHBD uses a very similar format called QCD.

    But no actual specification of the format. I'm quite concerned about this comment:

    APBS reads very loosely-formatted PQR files: all fields are whitespace-delimited, thereby allowing coordinates which are larger/smaller than ± 999 Å.

    APBS reads data on a per-line basis from PQR files using the following format:

    But if that is the case, then it's hard to see how this is compatible with PDB format, where fields are column-designated for a good reason - they often have no intervening space. For example, the files are limited to fewer than 10000 atoms.

    Ah, but at least in relation to APBS I read at http://cholla.wustl.edu/baker/classes/nbcr/user-guide/a2578.html :

    The "cost" of this looser formatting is the inability of APBS to parse PQR files with chain IDs. These fields need to be removed from PQR files before they are used with APBS.

    From
    I read:

    What is a PQR file?
    A PQR file is a PDB file with the temperature and occupancy columns replaced by columns containing the per-atom charge (Q) and radius (R).

    But we have from Angel's example:

    ATOM 1 N THR 1 46.148 16.581 2.104 0.1812 1.8240

    and from PDB:

    ATOM 2707 CG2 ILE A 339 13.681 44.682 -10.781 1.00 48.45 C
    0 1 2 3 4 5 6 7
    1234567890123456789012345678901234567890123456789012345678901234567890123456789

    Not obvious because SourceForge puts this in Helvetica, but I think they don't do as advertised. They have not just "used the temperature and occupancy columns" They have moved the columns and deleted the (crutial) element symbol column.

    If Jmol is to read this we need:

    1) The actual file specification. Where is that specified?
    2) Whether or not the XML version is specified. All I see at APBS is a vague reference to the data they need.
    3) Some way to distinguish these from PDB files. This would either require a new "format" keyword for the load command, which I've thought we should have anyway, or some parameter such as "loadFormat" that would bypass the current method Jmol uses to discover a file format.

    Not saying it isn't possible. Just not trivial.

    Bob

     
  • Angel Herraez

    Angel Herraez - 2007-05-01

    Logged In: YES
    user_id=1065324
    Originator: YES

    > What you mean, I think, is that Jmol is almost reading the PQR format,
    > but not quite.

    Yes.

    At first, I thought this was a straightforward extension of the PDB format, but clearly there are deeper implications; let's wait a bit until I get more info from the PQR people.

    > The "cost" of this looser formatting is the inability of APBS to
    > parse PQR files with chain IDs. These fields need to be removed
    > from PQR files before they are used with APBS.

    As I understand, this limitation has been removed in the latest versions.

    > Not obvious because SourceForge puts this in Helvetica, but I think
    > they don't do as advertised. They have not just "used the temperature
    > and occupancy columns" They have moved the columns and deleted the
    > (crutial) element symbol column.

    I agree on this view. The PQR does not just replace some data in the location of other data.

    > Not saying it isn't possible. Just not trivial.

    Agreed. I thought it would be, but it's not. Let's wait for more info.

     
  • Bob Hanson

    Bob Hanson - 2007-05-02

    Logged In: YES
    user_id=1082841
    Originator: NO

    I've added the

    load xxx::filename

    capability into 11.1.30, so we actually could read the PQR format. The user would have to designate

    load PQR::filename

    so as to distinguish it from a PDB file, but that's just the way it will have to be, since the PQR folks apparently didn't think to add a defining characteristic to the file.

    Actually... I think I can finesse this. The key is column 67. PDB specification says that's blank; PQR it's in the
    middle of the digits. Let me try that....

     
  • Bob Hanson

    Bob Hanson - 2007-05-02

    Logged In: YES
    user_id=1082841
    Originator: NO

    PQR reader is added to 11.1.30
    radius is property vanderwaals
    charge is property partialcharge

     
  • Bob Hanson

    Bob Hanson - 2007-05-02
    • assigned_to: nobody --> hansonr
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks