Re: [ccp4bb] Puzzling Structure
And as a footnote* - * I notice that, following discussion on this bulletin board, the space group of the 2wlv coordinate file has been updated. But at this point did it not occur to the PDB to change the space group in the structure factor file as well? So the coordinates indicate P21 21 2 but the structure factor file still says P21 21 21... Hmm consistency is highly over-rated... Also the author's SF data listing starts with c axis reflections including 0, 0, l odd as well as even, which is sort of a hint here From: MARTYN SYMMONS martainn_oshioma...@btinternet.com To: CCP4BB@JISCMAIL.AC.UK Sent: Tuesday, 16 April 2013, 14:30 Subject: Re: [ccp4bb] Puzzling Structure Just as a postscript. It has been pointed out to me that the space group was correct in the uploaded PDB and in the mtz reflection file. And there was no editing of this data pre-deposition. I am sort of surprised how quickly people are to beat up on the authors in such cases since we do not have access to the full data and facts. Having the uploaded data available would allow better checking. I'm mainly ignorant of the details, but isn't this the way sequence data is dealt with? - there are the unannotated sequence files which are gradually checked and assimilated (but not over-written). Cheers Martyn From: Michel Fodje michel.fo...@lightsource.ca To: CCP4BB@JISCMAIL.AC.UK Sent: Monday, 15 April 2013, 17:19 Subject: Re: [ccp4bb] Puzzling Structure Just to round up this topic, a bug report was submitted to PDBe concerning entry 2wlv and the PDB has how responded acknowledging the problem. An updated entry will be available in one week. As pointed out by Savvas, it is very likely the CRYST1 record was manually edited prior to deposition resulting in the wrong spacegroup being parsed in by AutoDep and subsequent processing moving the waters around in the wrong space group. Since there is no logical reason for the authors to do this, it was probably inadvertent. I imagine somebody accidentally deleted a space between P 21 21 2 and 18 and tried to fix it by adding it back, between 1 and 8. /Michel -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Edward A. Berry Sent: April-14-13 9:59 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure Robbie Joosten wrote: Hi Martyn, I think the question is where the error was made - seeing the uploaded file would clear this up. But it seems unlikely to me that the depositor saw a huge R factor discrepancy at the end of refinement and just blithely uploaded it. So scenario 3 :- PDB : we cannot reproduce your R factor with our programs Depositor : that's your problem mate - it was fine when it left me...up to you to sort it... Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group (example depositions: https://www.ebi.ac.uk/pdbe- xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFN AVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me why, because it is clearly a source of error. In my experience with RCSB autodep2, assuming the information was in the uploaded pdb file, this information is already pre-filled and the depositor just glances over to see it is correct. A missing or extra (1) might not be noticed. So perhaps it is a parsing error, perhaps related to the different ways the space group is represented on the CRYST1 card, and the different stringency of different programs in interpreting the CRYST1 card. But the validation report is included with the approval request letter, and major discrepancies are noted in the text of the validation letter in case the depositor is too busy to actually read the validation report. So if the depositor read more than the first line or two of the letter he should have known there was a problem. Then there is the 2-week default release policy: No major issues were raised during data processing. A summary of some of the key annotations in your entry is shown below. Please verify that these are correct. If we do not hear from you within two weeks, we will consider this entry to have been approved by you. The entry will then be released according to the release/hold instructions you have provided. If this 2-week default release is the rule even when there are issues, the depositor may have put it aside to find the problem when time was available, and waited too long and let the default release kick in. eab
Re: [ccp4bb] Puzzling Structure
Just as a postscript. It has been pointed out to me that the space group was correct in the uploaded PDB and in the mtz reflection file. And there was no editing of this data pre-deposition. I am sort of surprised how quickly people are to beat up on the authors in such cases since we do not have access to the full data and facts. Having the uploaded data available would allow better checking. I'm mainly ignorant of the details, but isn't this the way sequence data is dealt with? - there are the unannotated sequence files which are gradually checked and assimilated (but not over-written). Cheers Martyn From: Michel Fodje michel.fo...@lightsource.ca To: CCP4BB@JISCMAIL.AC.UK Sent: Monday, 15 April 2013, 17:19 Subject: Re: [ccp4bb] Puzzling Structure Just to round up this topic, a bug report was submitted to PDBe concerning entry 2wlv and the PDB has how responded acknowledging the problem. An updated entry will be available in one week. As pointed out by Savvas, it is very likely the CRYST1 record was manually edited prior to deposition resulting in the wrong spacegroup being parsed in by AutoDep and subsequent processing moving the waters around in the wrong space group. Since there is no logical reason for the authors to do this, it was probably inadvertent. I imagine somebody accidentally deleted a space between P 21 21 2 and 18 and tried to fix it by adding it back, between 1 and 8. /Michel -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Edward A. Berry Sent: April-14-13 9:59 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure Robbie Joosten wrote: Hi Martyn, I think the question is where the error was made - seeing the uploaded file would clear this up. But it seems unlikely to me that the depositor saw a huge R factor discrepancy at the end of refinement and just blithely uploaded it. So scenario 3 :- PDB : we cannot reproduce your R factor with our programs Depositor : that's your problem mate - it was fine when it left me...up to you to sort it... Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group (example depositions: https://www.ebi.ac.uk/pdbe- xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFN AVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me why, because it is clearly a source of error. In my experience with RCSB autodep2, assuming the information was in the uploaded pdb file, this information is already pre-filled and the depositor just glances over to see it is correct. A missing or extra (1) might not be noticed. So perhaps it is a parsing error, perhaps related to the different ways the space group is represented on the CRYST1 card, and the different stringency of different programs in interpreting the CRYST1 card. But the validation report is included with the approval request letter, and major discrepancies are noted in the text of the validation letter in case the depositor is too busy to actually read the validation report. So if the depositor read more than the first line or two of the letter he should have known there was a problem. Then there is the 2-week default release policy: No major issues were raised during data processing. A summary of some of the key annotations in your entry is shown below. Please verify that these are correct. If we do not hear from you within two weeks, we will consider this entry to have been approved by you. The entry will then be released according to the release/hold instructions you have provided. If this 2-week default release is the rule even when there are issues, the depositor may have put it aside to find the problem when time was available, and waited too long and let the default release kick in. eab
Re: [ccp4bb] Puzzling Structure
Just to round up this topic, a bug report was submitted to PDBe concerning entry 2wlv and the PDB has how responded acknowledging the problem. An updated entry will be available in one week. As pointed out by Savvas, it is very likely the CRYST1 record was manually edited prior to deposition resulting in the wrong spacegroup being parsed in by AutoDep and subsequent processing moving the waters around in the wrong space group. Since there is no logical reason for the authors to do this, it was probably inadvertent. I imagine somebody accidentally deleted a space between P 21 21 2 and 18 and tried to fix it by adding it back, between 1 and 8. /Michel -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Edward A. Berry Sent: April-14-13 9:59 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure Robbie Joosten wrote: Hi Martyn, I think the question is where the error was made - seeing the uploaded file would clear this up. But it seems unlikely to me that the depositor saw a huge R factor discrepancy at the end of refinement and just blithely uploaded it. So scenario 3 :- PDB : we cannot reproduce your R factor with our programs Depositor : that's your problem mate - it was fine when it left me...up to you to sort it... Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group (example depositions: https://www.ebi.ac.uk/pdbe- xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFN AVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me why, because it is clearly a source of error. In my experience with RCSB autodep2, assuming the information was in the uploaded pdb file, this information is already pre-filled and the depositor just glances over to see it is correct. A missing or extra (1) might not be noticed. So perhaps it is a parsing error, perhaps related to the different ways the space group is represented on the CRYST1 card, and the different stringency of different programs in interpreting the CRYST1 card. But the validation report is included with the approval request letter, and major discrepancies are noted in the text of the validation letter in case the depositor is too busy to actually read the validation report. So if the depositor read more than the first line or two of the letter he should have known there was a problem. Then there is the 2-week default release policy: No major issues were raised during data processing. A summary of some of the key annotations in your entry is shown below. Please verify that these are correct. If we do not hear from you within two weeks, we will consider this entry to have been approved by you. The entry will then be released according to the release/hold instructions you have provided. If this 2-week default release is the rule even when there are issues, the depositor may have put it aside to find the problem when time was available, and waited too long and let the default release kick in. eab
Re: [ccp4bb] Puzzling Structure
On 15 Apr 2013, at 17:19, Michel Fodje michel.fo...@lightsource.ca wrote: I imagine somebody accidentally deleted a space between P 21 21 2 and 18 and tried to fix it by adding it back, between 1 and 8. As this has now been mentioned twice in this discussion it should probably be noted for the archives that the last number in the CRYST1 record is not the space group number... See http://deposit.rcsb.org/adit/docs/pdb_atom_format.html#CRYST1 for details Huw
Re: [ccp4bb] Puzzling Structure
Hi Martyn, I think the question is where the error was made - seeing the uploaded file would clear this up. But it seems unlikely to me that the depositor saw a huge R factor discrepancy at the end of refinement and just blithely uploaded it. So scenario 3 :- PDB : we cannot reproduce your R factor with our programs Depositor : that's your problem mate - it was fine when it left me...up to you to sort it... Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group (example depositions: https://www.ebi.ac.uk/pdbe-xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFNAVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me why, because it is clearly a source of error. Checking back to see the space group misparsed and re-running the water moving-rem500 - and validation scripts would have cleared this problem with no action needed from the depositor. I totally agree that the annotator could have intercepted the problem. But the responsibility lies with the depositor. Hooray for bureaucracy! Cheers, Robbie Cheers Martyn -- On Sat, Apr 13, 2013 23:03 BST Robbie Joosten wrote: Hi Martyn, A shame then that these 'helpful' annotators did not make use of Pavel's basic sanity on the space group (*mentioned below) and check back to the one listed in the uploaded PDB file. As far as I know, EDS is run on all new depositions at PDBe. I don't know whether they already did that when this model was deposited. Even if they did, this may not solve the problem because the PDB does not refuse models. Possible scenarios (there may be more): 1) Pretty bad case - Annotator: We cannot reproduce your R-factors in EDS. Could you check the annotated coordinate and reflection files? - Depositor: Not interested (the paper is almost accepted anyway). Approve model as-is. 2) Worst case - Annotator: ... (doesn't notice the problem) - Depositor: ... (doesn't notice the problem) I often wonder why the PDB does not make the deposited coordinate file publicly available so that these sorts of issues can be checked and tracked. Good point, I wonder about that as well. Also about whether depositors would like that? The whole PDB data (excluding the EMDB that was recently merged into it) amounts to about a laptop hard drive's worth of data - so surely space can be made for the deposited coordinates? (and restraint files which will be very useful for other workers including pdb-redo). Yes, having access to certain restraint files (particularly for LINKs) would be very nice. That said, a proper repository of consensus-restraints for hetero compounds and LINKs would be more reliable than potentially different restraints for each PDB entry. Having the depositors' uploaded data would help me understand other puzzling features of structures such as the current 4GRV.pdb which seems to have a list of TLS groups but contains not a single ANISOU line!... I'm not a big fan of using ANISOU records for TLS contributions anyway ;-) But, more seriously, PDB entries should adhere to the PDB standard. Cheers, Robbie Cheers Martyn *In this particular case attempting to calculate R-factor using data and model files and making sure that the R you get is not twice as large as published one would entirely suffice -:) Pavel From: Robbie Joosten robbie_joos...@hotmail.com To: CCP4BB@JISCMAIL.AC.UK Sent: Friday, 12 April 2013, 22:57 Subject: Re: [ccp4bb] Puzzling Structure Waters are moved during annotation using the perceived space group's symmetry operation. So if the authors give the wrong space group, then the annotation pipeline understandably messes things up. If the originally uploaded PDB file was kept by PDBe, then the problem can be recovered quite easily by the annotators. Perhaps the topic starter, Michel Fodje, can send a bug report to PDBe. In my experience, the annotators are very helpful resolving these matters. potential flame Hoping that the depositors solve the problem by themselves, is probably in vain: There are many crystallographers who do not read the CCP4BB (which is a shame, really); they didn't notice the enormous amount of water related bumps in their final model (which is in the validation report you get after deposition and in REMARK 500 of the PDB file you have to approve); they also didn't notice the huge number of symmetry-related bumps; the R-factors in the PDB file are different from (and better than) the ones in Table 1. Also notice that the paper was submitted on April 21st 2009 and the model was deposited on June 29th 2009. Paper accepted on July 8th 2009. But I'm sure the referees had a chance to properly assess the quality of the structure model ;-) / potential flame Cheers
Re: [ccp4bb] Puzzling Structure
Hi Robbie, Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group what I don't get is why one needs to type in this information if it is already present in both, model and data files? Any human typing is typo prone. Ideally depositor would need to provide only information that is not genuinely available in data and model files that are being deposited. Checking back to see the space group misparsed and re-running the water moving-rem500 - and validation scripts would have cleared this problem with no action needed from the depositor. If original data and/or model files were not hand edited then there would not be such a problem in the first place, eliminating the need to create extra work overhead running all these great remediation tools. Pavel
Re: [ccp4bb] Puzzling Structure
Robbie Joosten wrote: Hi Martyn, I think the question is where the error was made - seeing the uploaded file would clear this up. But it seems unlikely to me that the depositor saw a huge R factor discrepancy at the end of refinement and just blithely uploaded it. So scenario 3 :- PDB : we cannot reproduce your R factor with our programs Depositor : that's your problem mate - it was fine when it left me...up to you to sort it... Which seems a sort of reasonable attitude to me. Not quite, the depositor has to give, i.e. type, the space group (example depositions: https://www.ebi.ac.uk/pdbe-xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFNAVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me why, because it is clearly a source of error. In my experience with RCSB autodep2, assuming the information was in the uploaded pdb file, this information is already pre-filled and the depositor just glances over to see it is correct. A missing or extra (1) might not be noticed. So perhaps it is a parsing error, perhaps related to the different ways the space group is represented on the CRYST1 card, and the different stringency of different programs in interpreting the CRYST1 card. But the validation report is included with the approval request letter, and major discrepancies are noted in the text of the validation letter in case the depositor is too busy to actually read the validation report. So if the depositor read more than the first line or two of the letter he should have known there was a problem. Then there is the 2-week default release policy: No major issues were raised during data processing. A summary of some of the key annotations in your entry is shown below. Please verify that these are correct. If we do not hear from you within two weeks, we will consider this entry to have been approved by you. The entry will then be released according to the release/hold instructions you have provided. If this 2-week default release is the rule even when there are issues, the depositor may have put it aside to find the problem when time was available, and waited too long and let the default release kick in. eab
Re: [ccp4bb] Puzzling Structure
Dear Robbie A shame then that these 'helpful' annotators did not make use of Pavel's basic sanity on the space group (*mentioned below) and check back to the one listed in the uploaded PDB file. I often wonder why the PDB does not make the deposited coordinate file publicly available so that these sorts of issues can be checked and tracked. Depositors' coordinate files nowadays are the output of reputable, documented programs. The whole PDB data (excluding the EMDB that was recently merged into it) amounts to about a laptop hard drive's worth of data - so surely space can be made for the deposited coordinates? (and restraint files which will be very useful for other workers including pdb-redo). Structural genomic groups could also take a lead here by making their final refined coordinates and restraint files available alongside the PDB data. Having the depositors' uploaded data would help me understand other puzzling features of structures such as the current 4GRV.pdb which seems to have a list of TLS groups but contains not a single ANISOU line!... Cheers Martyn *In this particular case attempting to calculate R-factor using data and model files and making sure that the R you get is not twice as large as published one would entirely suffice -:) Pavel From: Robbie Joosten robbie_joos...@hotmail.com To: CCP4BB@JISCMAIL.AC.UK Sent: Friday, 12 April 2013, 22:57 Subject: Re: [ccp4bb] Puzzling Structure Waters are moved during annotation using the perceived space group's symmetry operation. So if the authors give the wrong space group, then the annotation pipeline understandably messes things up. If the originally uploaded PDB file was kept by PDBe, then the problem can be recovered quite easily by the annotators. Perhaps the topic starter, Michel Fodje, can send a bug report to PDBe. In my experience, the annotators are very helpful resolving these matters. potential flame Hoping that the depositors solve the problem by themselves, is probably in vain: There are many crystallographers who do not read the CCP4BB (which is a shame, really); they didn't notice the enormous amount of water related bumps in their final model (which is in the validation report you get after deposition and in REMARK 500 of the PDB file you have to approve); they also didn't notice the huge number of symmetry-related bumps; the R-factors in the PDB file are different from (and better than) the ones in Table 1. Also notice that the paper was submitted on April 21st 2009 and the model was deposited on June 29th 2009. Paper accepted on July 8th 2009. But I'm sure the referees had a chance to properly assess the quality of the structure model ;-) / potential flame Cheers, Robbie P.S. It's pretty awesome that the problem was solved in less than 20 minutes by the CCP4BB (that is, by Phoebe Rice) -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Garib N Murshudov Sent: Friday, April 12, 2013 21:39 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure It is typo: R factor for p212121 - 0.4 for p21212 - around 0.18 Although water seem to have been moved around using p212121 On 12 Apr 2013, at 16:33, Phoebe A. Rice wrote: Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel. Dr Garib N Murshudov Group Leader, MRC Laboratory of Molecular Biology Francis Crick Avenue Cambridge Biomedical Campus Cambridge CB2 0QH UK Email: ga...@mrc-lmb.cam.ac.uk Web http://www.mrc-lmb.cam.ac.uk http://www.mrc-lmb.cam.ac.uk/
Re: [ccp4bb] Puzzling Structure
Hi Martyn, A shame then that these 'helpful' annotators did not make use of Pavel's basic sanity on the space group (*mentioned below) and check back to the one listed in the uploaded PDB file. As far as I know, EDS is run on all new depositions at PDBe. I don't know whether they already did that when this model was deposited. Even if they did, this may not solve the problem because the PDB does not refuse models. Possible scenarios (there may be more): 1) Pretty bad case - Annotator: We cannot reproduce your R-factors in EDS. Could you check the annotated coordinate and reflection files? - Depositor: Not interested (the paper is almost accepted anyway). Approve model as-is. 2) Worst case - Annotator: ... (doesn't notice the problem) - Depositor: ... (doesn't notice the problem) I often wonder why the PDB does not make the deposited coordinate file publicly available so that these sorts of issues can be checked and tracked. Good point, I wonder about that as well. Also about whether depositors would like that? The whole PDB data (excluding the EMDB that was recently merged into it) amounts to about a laptop hard drive's worth of data - so surely space can be made for the deposited coordinates? (and restraint files which will be very useful for other workers including pdb-redo). Yes, having access to certain restraint files (particularly for LINKs) would be very nice. That said, a proper repository of consensus-restraints for hetero compounds and LINKs would be more reliable than potentially different restraints for each PDB entry. Having the depositors' uploaded data would help me understand other puzzling features of structures such as the current 4GRV.pdb which seems to have a list of TLS groups but contains not a single ANISOU line!... I'm not a big fan of using ANISOU records for TLS contributions anyway ;-) But, more seriously, PDB entries should adhere to the PDB standard. Cheers, Robbie Cheers Martyn *In this particular case attempting to calculate R-factor using data and model files and making sure that the R you get is not twice as large as published one would entirely suffice -:) Pavel From: Robbie Joosten robbie_joos...@hotmail.com To: CCP4BB@JISCMAIL.AC.UK Sent: Friday, 12 April 2013, 22:57 Subject: Re: [ccp4bb] Puzzling Structure Waters are moved during annotation using the perceived space group's symmetry operation. So if the authors give the wrong space group, then the annotation pipeline understandably messes things up. If the originally uploaded PDB file was kept by PDBe, then the problem can be recovered quite easily by the annotators. Perhaps the topic starter, Michel Fodje, can send a bug report to PDBe. In my experience, the annotators are very helpful resolving these matters. potential flame Hoping that the depositors solve the problem by themselves, is probably in vain: There are many crystallographers who do not read the CCP4BB (which is a shame, really); they didn't notice the enormous amount of water related bumps in their final model (which is in the validation report you get after deposition and in REMARK 500 of the PDB file you have to approve); they also didn't notice the huge number of symmetry-related bumps; the R-factors in the PDB file are different from (and better than) the ones in Table 1. Also notice that the paper was submitted on April 21st 2009 and the model was deposited on June 29th 2009. Paper accepted on July 8th 2009. But I'm sure the referees had a chance to properly assess the quality of the structure model ;-) / potential flame Cheers, Robbie P.S. It's pretty awesome that the problem was solved in less than 20 minutes by the CCP4BB (that is, by Phoebe Rice) -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Garib N Murshudov Sent: Friday, April 12, 2013 21:39 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure It is typo: R factor for p212121 - 0.4 for p21212- around 0.18 Although water seem to have been moved around using p212121 On 12 Apr 2013, at 16:33, Phoebe A. Rice wrote: Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure
[ccp4bb] Puzzling Structure
Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
Not only 118, look at 119 . It seems also that residues 82-88 incorrectly placed . I think that authors (if they are reading this board ) must fix errors. To be honest this is not first time I see such models. 12.04.2013 23:17 пользователь Michel Fodje michel.fo...@lightsource.ca написал: By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
This explains why I cannot reproduce published R-factors (with files from PDB I get ~40%). If I force my favorite refinement program to use P21212 then I get R close to reported in PDB file header. This makes it worth reminding that it's rarely a good idea to edit PDB file out of refinement. Pavel On Fri, Apr 12, 2013 at 12:33 PM, Phoebe A. Rice pr...@uchicago.edu wrote: Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
In my opinion pdb must perform more strict checks of structures. I can remember at least 2 structures without OXT entry for C terminal tail . Of course rcsb won't accept my fixes. As graduate student I am not sure that I can point out mistakes to unknown author 12.04.2013 23:34 пользователь Eugene Osipov e.m.osi...@gmail.com написал: Not only 118, look at 119 . It seems also that residues 82-88 incorrectly placed . I think that authors (if they are reading this board ) must fix errors. To be honest this is not first time I see such models. 12.04.2013 23:17 пользователь Michel Fodje michel.fo...@lightsource.ca написал: By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
The CRYST1 in the pdb header is problematic. CRYST1 95.520 47.815 88.570 90.00 90.00 90.00 P 21 21 218 it looks like the number '1' was paired to the space group rather than the space grop number (i.e. nr. 18 for P21212) Table 1 in the paper specifies P212121 as the space group. On 12 Apr 2013, at 21:14, Michel Fodje michel.fo...@lightsource.ca wrote: Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
i meant to say P21212 On 12 Apr 2013, at 21:47, Savvas Savvides savvas.savvi...@ugent.be wrote: The CRYST1 in the pdb header is problematic. CRYST1 95.520 47.815 88.570 90.00 90.00 90.00 P 21 21 218 it looks like the number '1' was paired to the space group rather than the space grop number (i.e. nr. 18 for P21212) Table 1 in the paper specifies P212121 as the space group. On 12 Apr 2013, at 21:14, Michel Fodje michel.fo...@lightsource.ca wrote: Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
It is typo: R factor for p212121 - 0.4 for p21212- around 0.18 Although water seem to have been moved around using p212121 On 12 Apr 2013, at 16:33, Phoebe A. Rice wrote: Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel. Dr Garib N Murshudov Group Leader, MRC Laboratory of Molecular Biology Francis Crick Avenue Cambridge Biomedical Campus Cambridge CB2 0QH UK Email: ga...@mrc-lmb.cam.ac.uk Web http://www.mrc-lmb.cam.ac.uk
Re: [ccp4bb] Puzzling Structure
In this particular case attempting to calculate R-factor using data and model files and making sure that the R you get is not twice as large as published one would entirely suffice -:) Pavel On Fri, Apr 12, 2013 at 12:42 PM, Eugene Osipov e.m.osi...@gmail.comwrote: In my opinion pdb must perform more strict checks of structures. I can remember at least 2 structures without OXT entry for C terminal tail . Of course rcsb won't accept my fixes. As graduate student I am not sure that I can point out mistakes to unknown author 12.04.2013 23:34 пользователь Eugene Osipov e.m.osi...@gmail.com написал: Not only 118, look at 119 . It seems also that residues 82-88 incorrectly placed . I think that authors (if they are reading this board ) must fix errors. To be honest this is not first time I see such models. 12.04.2013 23:17 пользователь Michel Fodje michel.fo...@lightsource.ca написал: By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel.
Re: [ccp4bb] Puzzling Structure
Waters are moved during annotation using the perceived space group's symmetry operation. So if the authors give the wrong space group, then the annotation pipeline understandably messes things up. If the originally uploaded PDB file was kept by PDBe, then the problem can be recovered quite easily by the annotators. Perhaps the topic starter, Michel Fodje, can send a bug report to PDBe. In my experience, the annotators are very helpful resolving these matters. potential flame Hoping that the depositors solve the problem by themselves, is probably in vain: There are many crystallographers who do not read the CCP4BB (which is a shame, really); they didn't notice the enormous amount of water related bumps in their final model (which is in the validation report you get after deposition and in REMARK 500 of the PDB file you have to approve); they also didn't notice the huge number of symmetry-related bumps; the R-factors in the PDB file are different from (and better than) the ones in Table 1. Also notice that the paper was submitted on April 21st 2009 and the model was deposited on June 29th 2009. Paper accepted on July 8th 2009. But I'm sure the referees had a chance to properly assess the quality of the structure model ;-) / potential flame Cheers, Robbie P.S. It's pretty awesome that the problem was solved in less than 20 minutes by the CCP4BB (that is, by Phoebe Rice) -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Garib N Murshudov Sent: Friday, April 12, 2013 21:39 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure It is typo: R factor for p212121 - 0.4 for p21212- around 0.18 Although water seem to have been moved around using p212121 On 12 Apr 2013, at 16:33, Phoebe A. Rice wrote: Looks like a typo to me: if you change the CRYST space group record from P212121 to P21212, as the paper says it is, the packing problem goes away. ++ Phoebe A. Rice Dept. of Biochemistry Molecular Biology The University of Chicago 773 834 1723; pr...@uchicago.edu http://bmb.bsd.uchicago.edu/Faculty_and_Research/ http://www.rsc.org/shop/books/2008/9780854042722.asp From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Michel Fodje [michel.fo...@lightsource.ca] Sent: Friday, April 12, 2013 2:17 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling Structure By the way, you will need to show symmetry atoms to see the problem. -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Michel Fodje Sent: April-12-13 1:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Puzzling Structure Has anyone else noticed a problem with the structure of the N-terminal capsid domain of HIV-2 PDB 2wlv. Load it up to in coot and navigate to residue B118. /Michel. Dr Garib N Murshudov Group Leader, MRC Laboratory of Molecular Biology Francis Crick Avenue Cambridge Biomedical Campus Cambridge CB2 0QH UK Email: ga...@mrc-lmb.cam.ac.uk Web http://www.mrc-lmb.cam.ac.uk http://www.mrc-lmb.cam.ac.uk/
