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