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:[log in to unmask]] On Behalf Of Winn, MD (Martyn)
Sent: Tuesday, March 18, 2008 7:04 AM
To: [log in to unmask]
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: [log in to unmask]
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.