[log in to unmask]" type="cite">

    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.

[log in to unmask]" type="cite">

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.