Missing sanity check of duplicate resids within one chain?
Hi, this is a bit of an esoteric issue I just stumbled over, but I'd like to flag this up anyhow. For some reason (most likely boneheaded error on my side) I wound up with duplicate resids for two ion-atoms: TER HETATM 9325 CL CL S 1 10.578 23.153 35.662 1.00 75.71 Cl1- HETATM 9326 CL CL S 2 -6.546 32.210 31.507 1.00 80.31 Cl1- HETATM 9327 CL CL S 3 21.899 28.037 25.883 1.00 86.22 Cl1- HETATM 9328 K K S 3 7.259 -0.149 19.530 1.00 91.09 K1+ TER Phenix (1.9-1692) seemingly happily accepted the input and proceeded with refinement and validation. After upgrading my coot installation to the latest build the error was flagged. I think this sort of mistake should have at least been flagged in the validation stage or is this out of scope for phenix? Cheers, Carsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The PDB file format does not require unique residue names within a chain (and this "feature" has caused me great problems over the years since my software does). As an example, at one point the powers that be at the PDB decided that inhibitors should be in the same chain as the protein they bind to (which I have no problem with) but renamed them all to residue "1". Most proteins already have a residue "1" so this caused problems for people like me. It did not, however, violate the format. Coot is flagging this as a problem when it is not a violation of the file format. Coot has other problems with valid PDB files. It seems to operate correctly for only a subset of the world of valid PDB files. Dale Tronrud On 8/26/2014 2:51 PM, Schubert, Carsten [JRDUS] wrote:
Hi,
this is a bit of an esoteric issue I just stumbled over, but I’d like to flag this up anyhow.
For some reason (most likely boneheaded error on my side) I wound up with duplicate resids for two ion-atoms:
TER
HETATM 9325 CL CL S 1 10.578 23.153 35.662 1.00 75.71 Cl1-
HETATM 9326 CL CL S 2 -6.546 32.210 31.507 1.00 80.31 Cl1-
HETATM 9327 CL CL S 3 21.899 28.037 25.883 1.00 86.22 Cl1-
HETATM 9328 K K S 3 7.259 -0.149 19.530 1.00 91.09 K1+
TER
Phenix (1.9-1692) seemingly happily accepted the input and proceeded with refinement and validation. After upgrading my coot installation to the latest build the error was flagged. I think this sort of mistake should have at least been flagged in the validation stage or is this out of scope for phenix?
Cheers,
Carsten
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlP9B1kACgkQU5C0gGfAG10FNgCfReIMS8KI28wAG5wrN5EoK/yN BE8AoLujtd9d8AbNh+qr60iksy1XsFFX =zPnj -----END PGP SIGNATURE-----
On Tue, Aug 26, 2014 at 2:51 PM, Schubert, Carsten [JRDUS] < [email protected]> wrote:
Phenix (1.9-1692) seemingly happily accepted the input and proceeded with refinement and validation. After upgrading my coot installation to the latest build the error was flagged. I think this sort of mistake should have at least been flagged in the validation stage or is this out of scope for phenix?
As Dale notes, this is technically allowed by the PDB format - however, we do already look out for it: nat@laptop> phenix.pdb.hierarchy carsten.pdb . . . ### WARNING: consecutive residue_groups with same resid ### number of consecutive residue groups with same resid: 1 residue group: "HETATM 9327 CL CL S 3 .*. Cl1-" next residue group: "HETATM 9328 K K S 3 .*. K1+" We could certainly present this warning elsewhere - the question is where would it be most likely to be noticed? -Nat
Dale, Nat:
thanks for the helpful comments. I was not aware that this is a “feature” of the PDB standard.
Since Phenix recognizes the issue and issues a warning I assume this situation is handled correctly from the refinement side and does not cause any problems.
However, at least from my end, I would like to avoid this sort of issue from the get-go. The default setting in Phenix seems to be that the program continues despite the warnings. If one operates like me and does not go through the quite lengthy log files to look for these potential issues, then the likelihood of them being missed is quite high. As a suggestion: one could either think of implementing a “strict” mode in Phenix where the program aborts on encountering a warning or print out a warning at the end of the refinement that issues/warnings were encountered warranting a follow-up.
Cheers,
Carsten
From: Nathaniel Echols [mailto:[email protected]]
Sent: Tuesday, August 26, 2014 8:44 PM
To: Schubert, Carsten [JRDUS]
Cc: [email protected]
Subject: Re: [phenixbb] Missing sanity check of duplicate resids within one chain?
On Tue, Aug 26, 2014 at 2:51 PM, Schubert, Carsten [JRDUS]
participants (3)
-
Dale Tronrud -
Nathaniel Echols -
Schubert, Carsten [JRDUS]