From garib@ysbl.york.ac.uk Thu Jun 1 14:16:42 2006 Date: Thu, 1 Jun 2006 11:31:44 +0100 From: Garib Murshudov To: Martyn Winn Cc: P.J.Briggs Subject: Re: Refmac TLS, residual Bs and deposition I think Martyn answered sufficiently. I will just confirm that: There are some confusions and we need to work out and remove them. But it needs to be done very, very carefully regards Garib On 1 Jun 2006, at 10:35, Martyn Winn wrote: > > 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 > * > *********************************************************************** > *** > >