Editconf mead generated pqr file didn't follow pqr spec - Redmine #2511
Archive from user: zhiyi wu
When using editconf to generate pqr files.
gmx editconf -f enmin.tpr -mead system.pqr
The generated pqr file didn’t follow the pqr file format specification
(https://apbs-pdb2pqr.readthedocs.io/en/latest/formats/pqr.html), where:
- The pqr shouldn’t contain atom type at the end of the line
- There should always be a space separating the columns.
Here is a sample of pqr file.
REMARK The B-factors in this file hold atomic radii
REMARK The occupancy in this file hold atomic charges
TITLE system
REMARK THIS IS A SIMULATION BOX
CRYST1 35.060 34.040 38.990 90.00 90.00 90.00 P 1 1
MODEL 1
ATOM 1 N MET A 1 81.952 52.151 32.219 0.16 1.62 N
ATOM 7335 N MET B 1 30.317 32.933 28.543 0.16 1.62 N
ATOM 7855 N POPEE 474 9.856 33.258 32.940 –0.29 1.65 N
ATOM 10605 N POPEa 496 37.380 63.975 30.931 –0.29 1.65 N
ATOM 13855 N POPE0 522 90.878 72.350 68.454 –0.29 1.65 N
ATOM 15105 N POPE 532 16.405 8.140 68.984 –0.29 1.65 N
TER
ENDMDL
As is shown in the snapshot provided, if the residue name has a length of 4 characters (POPE), there will be no space between residue name and chain id (POPE a) instead of (POPEa).
(from redmine: issue id 2511, created on 2018-05-22 by gmxdefault, closed on 2018-06-06)
- Changesets:
- Revision b0f4bf1d by Paul Bauer on 2018-06-06T08:24:41Z:
Fix PQR file output
PQR files from editconf were always written as fixed format PDB files
with just the field information added. As pointed out in the linked
redmine, this can violate the PQR file standard if the field lengths are
too long, even though the file would still be a valid PDB.
This adds a slightly different form of the writeout that has a flexible,
PQR conform format.
Fixes #2511
Change-Id: I626380b642a0214970753da289e9c969ce411ea7
- Uploads: