[phenixbb] phenix refinement question

[Pavel Afonine]

  Hi Martyn,

thanks for your feedback - it is very much appreciated!

> It is not strictly the case that TLS is neglected during pdb deposition.

This is in-sync with my understanding of the current situation. It is 
really great!
(Although, I should re-run my tools through the whole PDB to quickly see 
state-of-the-art.)

> The requirement for deposition now is that full ANISOU values have to be present if TLS has been used.

This is really great, too!

> In which case the TLS definitions are redundant as the full description of the ADP model is provided by the ATOM and ANISOU records.

No, this is not true. The TLS definitions define the model partitions 
into TLS groups that with the current tools cannot be recovered from 
just ANISOU records.

> There is therefore no absolute requirement for the TLS definitions in the header to be correctly read in order for the validation to proceed.

This is true in a sense that you can re-calculate the R-factor (since 
the complete ANISOU records corresponding to Utotal (see reference 
below) are present and therefore you can compute correct Fcalcs), but 
inability to read this information correctly should be a BIG warning 
sign for everyone involved.
Also, leaving out TLS records will result in obvious loss of information 
about TLS groups (atom selection defining TLS groups). I don't see a 
reason why one would want to give up this information.

> This aids accurate validation of the model against the provided SF data using EDS for example.

Absolutely true: the ability to reproduce the reported R-factors is in 
close and direct relation with the ability to accurately validate the 
model and data.
phenix.model_vs_data would do it almost unconditionally:

J. Appl. Cryst. (2010). 43, 669-676
phenix.model_vs_data: a high-level tool for the calculation of 
crystallographic model and data statistics
P. V. Afonine, R. W. Grosse-Kunstleve, V. B. Chen, J. J. Headd, N. W. 
Moriarty, J. S. Richardson, D. C. Richardson, A. Urzhumtsev, P. H. Zwart 
and P. D. Adams

> The output with and without TLS was used historically to check whether the TLS definitions had been read correctly.

I see, but there are more to just having TLS hint in "REMARK 3"...  The 
TLS records contain the information about TLS groups (atom selections, 
at least), that, if removed, cannot be easily guessed.

> Having said that the presence of TLS definitions is still informative for users of the coordinates to check that for example a full anisotropic refinement has not been carried out.

Well, "TLS refinement" = "Constrained anisotropic refinement", so I 
don't really understand what is "full anisotropic refinement".
Also, what about performing TLS refinement on top of treating each atom 
moving anisotropically:

see p. 24-31: http://www.phenix-online.org/newsletter/CCN_2010_07.pdf

for some overview.

> PDB curation involves checking the description of the TLS groups that have been chosen.

Great! Did you see my report that I sent to those who might be 
interested a few months ago? If not, I can re-send you the old one and 
meanwhile I can re-compute the most current.

> So, for example, it is useful that the selection expressions do not refer to ranges of residues that do not exist (for example "RESID -99:9999" for a 1-100 residue protein),

Absolutely true. This is what I pointed out in my report a few months ago.

> or to overlapping ranges, for example: a chain with its TLS group 1 defined as "RESID 45:90" and its TLS group 2 is defined as "RESID 75:150".

True.

> Depending on the wwPDB deposition site, the validation programs may differ.

Sure, the tools may vary under the requirement that the outcome must be 
the same.

> PDBe uses an in-house version of the EDS server which uses REFMAC with TLS taken into account. RCSB and PDBj run the particular program that was used in determining the structure for validation, in addition to a validation check using SFCHECK.

Can you reproduce the reported R-factors of this entry using the above 
described tools: 2WYX or 2R24?
Let me know if not.

> It is worth saying that the PDB sites are not attempting to completely reproduce the authors' Rfactors,

This is very unfortunate, since there is no reason for the R-factors to 
be not 0.01% reproducible. IF you can't reproduce them, then there is 
THE problem either with the structure/data or with the software you use. 
Period.
See:

J. Appl. Cryst. (2010). 43, 669-676
phenix.model_vs_data: a high-level tool for the calculation of 
crystallographic model and data statistics
P. V. Afonine, R. W. Grosse-Kunstleve, V. B. Chen, J. J. Headd, N. W. 
Moriarty, J. S. Richardson, D. C. Richardson, A. Urzhumtsev, P. H. Zwart 
and P. D. Adams

> but instead to check for errors in the deposition process.

Well, reproducing the R-factors is the very first sanity check to do 
BEFORE wasting any time on checking the other lower level details. 
Indeed, if such gross thing as the R-factor doesn't reasonably match 
there is no point to validate fine details.

> You can check the details of the PHENIX header format for TLS at
> http://www.wwpdb.org/documentation/format32/remark3.html#Refinement%20using%20PHENIX

Thanks! This looks great.
Just a minor question:
What if I specify a TLS group as "chain A or chain a and resseq 123:456 
and element N" (that I potentially can do no problem in PHENIX)?

All the best!
Pavel.