Hi Martyn, When the rcsb processes files, that line is stripped form the PDB file. We have taken an effort in the last few years to copy it into the REMARK 3 OTHER REFINEMENT REMARKS: field so that it is retained in the PDB file. Sometimes you can find out if that line was in the original PDB file header that was deposited by checking the mmCIF formatted file in the loop over the _database_PDB_remark.id _database_PDB_remark.text
In the case of 2qua, the text for pdb_remark id 3 contains the line " ATOM RECORD CONTAINS RESIDUAL B FACTORS ONLY" http://www.pdb.org/pdb/files/2qua.cif Since I don't deposit with EBI / pdbJ, I am not sure if they also strip this record from the PDB formatted header or not. Regards, Mitch -----Original Message----- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Winn, MD (Martyn) Sent: Tuesday, March 18, 2008 7:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Summary: Calculating R-factor and maps from a Refmac model containing TLS downloaded from the PDB Refmac (at least 5.2) and TLSANL write a line into the PDB header specifying what is in the B column: REMARK 3 ATOM RECORD CONTAINS RESIDUAL B FACTORS ONLY Looking at 2qua which used Refmac 5.3, that line isn't there. I don't know at what stage it has been lost. Of course, it would be nice if all the TLS stuff was in dedicated header records. Note that you can use TLSANL to recover residual B from combined B (given TLS parameters), see keywords BRESID and ISOOUT. Note also you would need ANISOU records to reproduce R factors - combined B would not be enough. Cheers Martyn -----Original Message----- From: CCP4 bulletin board on behalf of Pavel Afonine Sent: Tue 3/18/2008 1:25 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Summary: Calculating R-factor and maps from a Refmac model containing TLS downloaded from the PDB >> 2) Some files list in the ATOM "B" column the residual B after TLS >> has been accounted for while others list the total B (TLS and >> residual). There is no clear indication in the PDB file which >> interpretation is being used. >> > > That is a fundamental deficiency in the existing PDB standard. It simply > doesn't specify how to present this critical information. A draft change > covering this was circulated at the PDB get-together of last summer's ACA > meeting, and I discussed with Garib and Eleanor that we should as a community > decide how we would like it handled. The consensus as I understand it is > that people would prefer that the B field of individual ATOM records contain > the *net* B rather than the residual B, so that old programs will continue > to work as expected. However, this puts even more importance on the TLS > description in the header being correct, since the information is otherwise > not recoverable. We were going to circulate a letter, but I plead guilty > to letting the matter slide. > This is exactly what phenix.refine does (since 2005, I guess): it always prints out the total B-factor for each atom (Bindividual+Btls+Boverall). The TLS information (TLS matrices, origin coordinates and TLS group selections) are reported as well in PDB file header, so if necessary one can always extract the information about individual contributions. This makes it more straightforward to reproduce the R-factor statistics without any prior manipulations with the model. > Another notable omission is > the lack of scattering factors. If you have refined a SAS data set, > e.g. a Se-edge dataset of a SeMet metallo-protein, then the R factors may > vary by >1% just because of incorrectly reproduced f' terms for the > Se and metal atoms. > > Ethan Merritt > phenix.refine also always reports f' and f'' in output PDB file if they were used in refinement. I hope they don't get stripped off when deposited with PDB. Pavel.
