Residue number error after autoMR or PhaserMR
Hi, When I run MR in Phenix, I found that there is a numbering error in the solution PDB file The error is that Phenix numbers residues from 0 again when the residue numbers are over 999, though they belong to the same chain. For example "ATOM 11504 N HIS C 999 -37.389 50.436 57.144 1.00 56.62 N ATOM 11505 CA HIS C 999 -36.908 51.569 57.924 1.00 60.55 C ATOM 11506 C HIS C 999 -37.438 51.479 59.337 1.00 61.73 C ATOM 11507 O HIS C 999 -38.648 51.484 59.549 1.00 60.99 O ATOM 11508 CB HIS C 999 -37.382 52.895 57.326 1.00 63.09 C ATOM 11509 CG HIS C 999 -36.353 53.577 56.478 1.00 66.67 C ATOM 11510 ND1 HIS C 999 -35.280 52.912 55.925 1.00 68.12 N ATOM 11511 CD2 HIS C 999 -36.247 54.865 56.070 1.00 68.95 C ATOM 11512 CE1 HIS C 999 -34.559 53.762 55.214 1.00 69.21 C ATOM 11513 NE2 HIS C 999 -35.122 54.953 55.285 1.00 69.80 N ATOM 11514 N MET C 0 -36.544 51.378 60.309 1.00 64.17 N ATOM 11515 CA MET C 0 -36.992 51.355 61.688 1.00 66.45 C ATOM 11516 C MET C 0 -37.290 52.797 62.083 1.00 68.10 C ATOM 11517 O MET C 0 -37.018 53.716 61.302 1.00 68.58 O ATOM 11518 CB MET C 0 -35.903 50.763 62.605 1.00 67.35 C ATOM 11519 CG MET C 0 -36.051 49.272 62.997 1.00 67.14 C ATOM 11520 SD MET C 0 -36.534 48.947 64.735 1.00 65.84 S ATOM 11521 CE MET C 0 -35.169 49.744 65.675 1.00 66.20 C ATOM 11522 N VAL C 1 -37.840 53.015 63.272 1.00 69.46 N ATOM 11523 CA VAL C 1 -38.160 54.373 63.711 1.00 69.99 C ATOM 11524 C VAL C 1 -36.911 55.251 63.875 1.00 70.28 C ATOM 11525 O VAL C 1 -37.029 56.452 64.122 1.00 70.20 O ATOM 11526 CB VAL C 1 -38.908 54.379 65.057 1.00 70.57 C ATOM 11527 CG1 VAL C 1 -40.322 53.847 64.873 1.00 71.16 C ATOM 11528 CG2 VAL C 1 -38.148 53.537 66.061 1.00 70.54 C" Does anyone has idea about it? Thanks Yu Zhang
On Wed, Apr 20, 2011 at 9:33 AM, Zhang yu
When I run MR in Phenix, I found that there is a numbering error in the solution PDB file
The error is that Phenix numbers residues from 0 again when the residue numbers are over 999, though they belong to the same chain.
For example
ATOM 11513 NE2 HIS C 999 -35.122 54.953 55.285 1.00 69.80 N ATOM 11514 N MET C 0 -36.544 51.378 60.309 1.00 64.17 N ATOM 11522 N VAL C 1 -37.840 53.015 63.272 1.00 69.46 N
Does anyone has idea about it?
Phaser has its own PDB parser, and it looks like it only reads characters 2-4 in the residue number. This sounds like a bug, but there may be some reason for it - we'll check this out. -Nat
Nathaniel Echols wrote:
On Wed, Apr 20, 2011 at 9:33 AM, Zhang yu
wrote: When I run MR in Phenix, I found that there is a numbering error in the solution PDB file
The error is that Phenix numbers residues from 0 again when the residue numbers are over 999, though they belong to the same chain.
For example
ATOM 11513 NE2 HIS C 999 -35.122 54.953 55.285 1.00 69.80 N ATOM 11514 N MET C 0 -36.544 51.378 60.309 1.00 64.17 N ATOM 11522 N VAL C 1 -37.840 53.015 63.272 1.00 69.46 N
Does anyone has idea about it?
Phaser has its own PDB parser, and it looks like it only reads characters 2-4 in the residue number. This sounds like a bug, but there may be some reason for it - we'll check this out.
There was discussion a few years back about an extended pdb format in which the fourth digit would go not just 0-9 but 0123456789ZBCDE...XYZabcdefghijkl....z (and the other digits would also if the fourth digit was greater than 9) So maybe the code that handles that isn't kicking in where it should? The folks who want to deposit structures of whole bacteria will have to wait a little longer. ed
On Wed, Apr 20, 2011 at 11:45 AM, Edward A. Berry
There was discussion a few years back about an extended pdb format in which the fourth digit would go not just 0-9 but 0123456789ZBCDE...XYZabcdefghijkl....z (and the other digits would also if the fourth digit was greater than 9) So maybe the code that handles that isn't kicking in where it should?
This is Ralf's "hybrid36" format. I think Phaser will use that encoding for atom records, but not residues. In any case, using the hybrid36 format is unnecessary in this case, since the residue number field is officially (according to the PDB) four characters long.
The folks who want to deposit structures of whole bacteria will have to wait a little longer.
The PDB won't even handle ribosome structures without splitting them into multiple files, so this has been a problem for at least a decade. (Phenix does not have this limitation, of course, nor do Coot, Refmac, or CNS, as far as I know.) Residue numbers are less likely to overrun the official format, but I think there are structures for fragments of proteins where the actual residue numbering starts above 9999. I'm not sure what the PDB does to these. -Nat
I just realised that I hadn't reported the outcome to the BB. There was a bug in the format used to write PDB files in Phaser. Airlie McCoy fixed it on Thursday, so nightly builds since then will not have this error. Best wishes, Randy Read On Apr 20 2011, Nathaniel Echols wrote:
On Wed, Apr 20, 2011 at 11:45 AM, Edward A. Berry
wrote: There was discussion a few years back about an extended pdb format in which the fourth digit would go not just 0-9 but 0123456789ZBCDE...XYZabcdefghijkl....z (and the other digits would also if the fourth digit was greater than 9) So maybe the code that handles that isn't kicking in where it should?
This is Ralf's "hybrid36" format. I think Phaser will use that encoding for atom records, but not residues. In any case, using the hybrid36 format is unnecessary in this case, since the residue number field is officially (according to the PDB) four characters long.
The folks who want to deposit structures of whole bacteria will have to wait a little longer.
The PDB won't even handle ribosome structures without splitting them into multiple files, so this has been a problem for at least a decade. (Phenix does not have this limitation, of course, nor do Coot, Refmac, or CNS, as far as I know.) Residue numbers are less likely to overrun the official format, but I think there are structures for fragments of proteins where the actual residue numbering starts above 9999. I'm not sure what the PDB does to these.
-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
participants (4)
-
Edward A. Berry
-
Nathaniel Echols
-
Randy J. Read
-
Zhang yu