On 9 June 2014 09:29, Carles Palanca i Garcia <[email protected]> wrote:
> Hi again and thanks for your answers. > > I have been considering your comments and as I see it I have three options > A) Leave the pdb with no TLS refinement, as I already have good R values > without them. > B) Perform the TLS refinement and not worry about the high B-factors since > it is normal that they increase in this step. > C) Use TLSanl with BRESID=TRUE. This mantains the B-factors as before the > TLS while still adding the ANISOU component to the file. > > Obviously, option C is the one that gives the best results (B and > Rfactors) but I have some doubts about it: Why is the default in TLSanl set > to BRESID=FALSE? Since the default in REFMAC is not to specify TLSOUT ADDU, > should I run TLSanl defining BRESID=TRUE for every pdb from now on? > Hi Carles To understand this it's necessary to explain some history. TLSANL was originally developed by myself & others to work with the RESTRAIN refinement program which output the total isotropic Beq in the B column of a PDB file. We did this for the simple reason that this was what was required by the PDB specification! The intention was that this output from RESTRAIN could be deposited directly in the PDB. TLSANL was then developed separately to add the ANISOU records which were required for visualisation purposes (at that time only the ORTEP & Raster3D programs were available, but since then of course several more have been developed). It was never intended that the output from TLSANL would be suitable for deposition since in terms of information content the ANISOU records are completely redundant (all the information required to compute them is in the residue range specifications and the TLS tensors). In fact the presence of ANISOU records in a PDB file signalled to RESTRAIN that individual U tensors had been refined (obviously feasible only for near-atomic resolution data). The problem really stems from the fact that there's no proper specification of TLS data in the PDB file specification. They are specified in REMARK records and are therefore not technically part of the deposited data (i.e. you can never be sure that programs will be able to read them), yet they are from an information content point of view an integral part of the atomic model of the macromolecule, as important as the co-ordinates. Hence we have this crazy work-around where totally redundant U tensors have to be included in the deposited data. Anyway, somewhat later, the TLS refinement option was added to Refmac, but it output the residual Beq instead, in contravention it seems to me of the PDB specification (in any case it's clearly not a good idea to use the same column for different purposes - it can only generate confusion!). TLSANL then had to be adapted to read these files and so the BRESID option was added (not by myself I hasten to add!). However for backwards compatibility with RESTRAIN the default was set to BRESID=false. Returning to your original question: (1) you say you want to reset your B factors back to 50-60 when your Wilson B is 87? As others have said your original B factors are not your goal. (2) It's not clear to me why you want to use TLSANL for this at all since it has been made redundant by the 'TLSOUT ADDU' option in REFMAC. The recommended procedure is to use REFMAC _without_ 'TLSOUT ADDU' for all runs except the very last one. These will give PDB files with Bresid but not ANISOUs. Then for the very last run where you prepare the PDB file for deposition you specify 'TLSOUT ADDU' and that will give the total Beq and ANISOUs which is what is required for deposition. You don't need TLSANL at any stage, unless of course you want to analyse the tensors and understand what they mean, which is really what it's intended for, though this understanding can also be gained from the ellipsoid diagrams. It seems to me that if you stick to the recommended procedure you can't go wrong. Cheers -- Ian
