 |
 |
>> 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.