Hi Ethan,
On 6/30/10 11:43 AM, Ethan Merritt wrote:
On Wednesday 30 June 2010 11:15:51 am Pavel Afonine wrote:
Just a remark/precaution: if you remove ANISOU records then you will
basically invalidate the refinement results (the refined model).
If that is true then I would say there is a deeper problem.
The description of the TLS groups in the header records should be
sufficient to regenerate the ANISOU records when needed. If this
is not already the case, then I suggest that we, as a community,
need to work out how to make it the case and then lobby for that
solution to be mandated by the PDB.
Specifically to phenix.refine: phenix.refine outputs total ADP into
ANISOU records and its isotropic equivalent into ATOM records. If you
just remove ANISOU records you will still have the total B-factors in
ATOM records. Now, what happens if you restore back the TLS contribution
using TLS matrices in PDB file header is that you will get ANISOUs
containing only TLS contribution only (I presume), and B-factors in ATOM
records will still be the full ones. So, total mess, obviously.
Anyway, post-refinement manipulation on a PDB file is bad.
But I think it's not that bad. I have had good results from reproducing
the reported R factors from the TLS header records plus the ATOM records.
Admittedly, the PDB files I used for testing were refmac refinements
rather than phenix refinements.
This is true. Because most likely the PDB files you tried were
containing residual B-factors in ATOM records and the TLS contribution
stored in REMARK 3.
I was getting the same results too:
Afonine et al., J. Appl. Cryst. (2010). 43
phenix.model_vs_data: a high-level tool for the calculation of
crystallographic model and data statistics.
Make
sure you recompute the R-factors after removing ANISOU and be prepared
to see (much) higher values.
Well, that depends on what program[s] you use to recalculate the R values.
If you actually use the TLS information in the header records then it
should come out close to the original values.
See reference above.
Pavel.
