From M.D.Winn@dl.ac.uk Thu Jun 1 14:16:13 2006 Date: Thu, 1 Jun 2006 10:35:13 +0100 From: Martyn Winn To: P.J.Briggs Cc: Martyn Winn , Garib Murshudov Subject: Re: Refmac TLS, residual Bs and deposition What "PDB standard" ?? If you go to the RCSB site, and follow the links for PDB format, you get to: http://www.rcsb.org/pdb/file_formats/pdb/pdbguide2.2/guide2.2_frame.html Version 2.2 from 1996, i.e. pre-dating TLS, so certainly no explicit decision on what should be deposited. There is some discussion on the "temperature factor". Note that this terminology is deprecated - see recommendation 6 of the IUCr Commission on Crystallographic Nomenclature, Trueblood et al, 1996. Anyway, there are some statements: > If the depositor provides the data, then the isotropic B value is given > for the temperature factor. Fine, but what is the "isotropic B value" in the TLS context? > If there is no isotropic B value from the depositor, but there is an > ANISOU record with anisotropic temperature factors, then the B > equivalent is stored in the tempFactor field, as calculated by: Statement of equivalence between ATOM and ANISOU lines, but note only applies if no isotropic B value given. > In some entries, the occupancy and temperature factor fields are used > for other quantities. In these cases, an explanation is provided in the > remarks. Which is what we've done. If this is the "PDB standard" then she is wrong. If there is some other standard, why is this on the web site? Well, I've had a browse of the exchange dictionary as well mmcif_pdbx.dic and I don't see anything different. There is for example atom_site.adp_type which sounds relevant, but only specifies if it is B or U and isotropic or anisotropic. That doesn't address the issue of multiple contributions. The exchange dictionary does have TLS definitions, which seem unchanged from when I wrote them. More generally, you'll have seen the recent discussion on the BB. There are three ways to go: 1. Deposit the true refinement parameters - the TLS parameters and the residual Bs. This is a true statement of the protein model used, but confuses the many programs that don't understand TLS. Nevertheless, this is what I've always recommended. 2. Deposit the output of TLSANL with ISOOUT FULL option, as you say. This gives the "full" B factor, but has confusions of its own as it looks like a anisotropic refinement. The constraints on the ADPs arising from the TLS model are lost. Also, there is currently no software to do the back-transformation if you want to re-refine such a file from the PDB. 3. Run TLSANL with ISOOUT FULL, and then "grep -v" out the ANISOU lines. You have TLS in the header, and full B in the ATOM lines, but no ANISOU line. Again, this is not a true statement of the model used, but would be easier to process with current software. There is certainly a problem here, but its not so simple as Helen makes out. I'd welcome some standard here, but it needs to be thought out properly. I really believe most people are still confused by the non-atomic nature of TLS. I've been trying to think of analogous situations. There is rigid-body refinement of coordinates, but I don't think that is the same. The rigid-body model describes the refinement protocol used, not the coordinate values themselves. I.e. if x_1 changes by 0.1A then x_2 must change by 0.1A (pretend we're in 1D) - it doesn't say anything about the values of x_1 and x_2, whereas the TLS model does gives the values of U_1 and U_2. What other non-atom parameters are there? Scaling parameters, but they are easy because they apply to the whole cell. In future, there might be normal mode models for displacements. And you could imagine wanting to specify a delocalised charge, i.e. there is a charge of -1 associated with this group of 3 atoms. But at the moment, it seems TLS is unique, and I don't think people really understand it. m On Wed, 31 May 2006, P.J.Briggs wrote: > > Hi Martyn & Garib > > Apologies for the lengthy message. I'm currently at the RCSB PDB and I > seem to have walked into something of a controversy over the deposition > of REFMAC TLS output PDBs files containing residual B factors. > > Essentially I have been told that submitting files with residual B > factors in ATOM records is not acceptable, and is not migitated by the > inclusion of the line: > > REMARK 3 ATOM RECORD CONTAINS RESIDUAL B FACTORS ONLY > > in the PDB header. According to Helen Berman, in the PDB standard the > B-factor column of the ATOM records can only contain the full B factors. > > My understanding is that: > 1. REFMAC using TLS refinement outputs residual Bs only, and > 2. we have been advising users that it is ok to deposit the > PDB file with residual B-factors, without any further > processing on their part. > > If the above is correct, then I know that running TLSANL can restore the > total B's as well as producing ANISOU records (which presumably contain > the information on the anisotropy modelled by TLS, in a different form). > My naive recommendation would be that depositors are therefore advised > to run TLSANL with BRESID and ISOOUT FULL keywords prior to deposition, > to make a file suitable for deposition. > > This would seem to be a very simple solution, however: the PDB file > output by TLSANL is not the same as the TLS refined file, and I don't > know if there are issues which make this inadvisable in practice. > > So my questions are: > > 1. Can you clarify if my understanding of the output of residual > Bs only from REFMAC with TLS is correct? > 2. Can you clarify what users are currently advised to deposit from > TLS refinement? > 3. Can you tell me if there was there any agreement with the EBI over > what TLS data is acceptable for deposition? > 4. Can you tell me what the issues might be with advising users to use > TLSANL to convert residual Bs to full Bs plus ANISOUs for deposition? > > I appreciate that this may not be straightforward, and I apologise for > cold-calling you on this. Nevertheless, any information that you can > provide would be useful to me to clarify the situation. Tomorrow > (Thursday) at 11am (4pm UK time) there will be a videoconference > between annotators at the RCSB and the EBI, and this issue will be > discussed (among others). > > Thanks for your help, best wishes > > Pete > > -- > ___________________________________________________ > Peter J Briggs, pjx@dl.ac.uk Tel: +44 1925 603826 > CCP4, ccp4@dl.ac.uk Fax: +44 1925 603825 > http://www.ccp4.ac.uk/ > Daresbury Laboratory, Daresbury, Warrington WA4 4AD > > ************************************************************************** * * * Dr. Martyn Winn * * * * Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, ENGLAND * * Tel: +44 1925 603455 E-mail: m.d.winn@ccp4.ac.uk (personal) * * Fax: +44 1925 603825 E-mail: ccp4@ccp4.ac.uk (CCP4 problems) * * URL: http://www.ccp4.ac.uk/martyn/martyn.html * **************************************************************************