This release of BUSTER implements TLS, a technique for modelling disorder associated with random rigid-body motions within molecular crystal structures. These can give rise to significantly anisotropic motions of each atom involved, but the variation across each rigid domain (or "TLS group") of the parameters (anisotropic Us) describing those motions is very smooth, so that the 6N variables contained in the anisoUs for N atoms can be characterised through only 20 TLS parameters.
For an example of using TLS, consider the structure 3ee3. This is a nucleoside diphosphate kinase, crystallised with six-fold NCS and with reflections measured to 2.4 angstrom; the PDB file and MTZ file are attached.
Using TLS in the most basic sense is completely straightforward, although either refinement in the example below takes some hours to run:
refine -p 3ee3.pdb -m 3ee3.mtz -autoncs -d no_TLS > no_TLS.lis refine -M TLSbasic -p 3ee3.pdb -m 3ee3.mtz -autoncs -d with_TLS > with_TLS.lis
Protocol | Final R | Final Rfree |
No TLS | 20.9% | 23.2% |
TLSbasic | 19.6% | 21.4% |
The TLSbasic macro is designed to be the easiest way to run TLS with 'sensible' parameters. It uses any TLS decomposition which is recorded in the input PDB file, and constructs a straightforward one (each chain modelled as a single rigid body) if there isn't one in the PDB file to start with. It optimises the TLS parameters twice.
If you have already performed a TLS-based refinement on a structure, and want to carry on from where you've left off with the TLS parameters (that is, not only the decomposition but the initial refined values for the twenty parameters decribing each segment) used before, simply add -TLS to the command line.
refine -p lastrun/refined.pdb -m data.mtz -TLS ...
If you want to keep a set of refined TLS parameters fixed for the whole refinement (this is useful if, for example, you are using quantum methods which make the geometry calculation slow), add -TLS TLSfixcycALL=1 to the command line.
If you want to give a new explicit TLS decomposition for a structure (and incidentally re-refine the parameters starting from zero), you use -TLS tlsparam.dat, where an example tlsparam.dat is in the 'An example of a complicated decomposition' section below.
You don't need to use -TLS when using the macros:
UNNECESSARY to put refine -TLS -M TLSbasic
With TLSbasic:
We've done some quite extensive tests at Global Phasing, and it seems that, at least if you're using TLS on a well-refined structure, a domain decomposition doesn't necessarily gain very much over using one TLS group per chain.
To keep you from having to carry around a separate parameter file, BUSTER outputs the TLS decomposition and parameters in the REMARK 3 section of the output PDB file; and if you have a PDB file with a TLS decomposition stored in its headers, and use the macro TLSbasic, that TLS decomposition will be used. So you can finish with BUSTER a job started using another refinement package, and the same TLS decomposition will be used.
We do not yet have an automatic TLS decomposition functionality; the TLSMD server seems to produce reasonable results.
Here we use structure 3c57, which is part of a small signalling protein from the tuberculosis bacillus; it's a high-resolution structure with two copies in the ASU, and it consists of three helices so can be expected to have a pattern of disorder well-modelled with TLS.
A refinement without TLS (using individual B factors per atom, restrained by B-correlation terms, as is BUSTER's default):
refine -p 3c57.pdb -m 3c57.mtz -d without-tls
quite quickly gives a result with Rfree 23.4%, Rfact 20.6%.
Uploading without-tls/refine.pdb to the TLSMD server and, after it has calculated for a while, asking for a phenix-format TLS file with four segments in each chain gives
refinement.refine { adp { tls="(chain A and resid 149:165)" tls="(chain A and resid 166:178)" tls="(chain A and resid 179:193)" tls="(chain A and resid 194:199)" tls="(chain B and resid 151:162)" tls="(chain B and resid 163:178)" tls="(chain B and resid 179:193)" tls="(chain B and resid 194:199)" } }
which translates into BUSTER's notation as (be careful with the spacing around the hyphen in the middle)
NOTE BUSTER_TLS_SET tlsA1 {A|149 - 165} NOTE BUSTER_TLS_SET tlsA2 {A|166 - 178} NOTE BUSTER_TLS_SET tlsA3 {A|179 - 193} NOTE BUSTER_TLS_SET tlsA4 {A|194 - 199} NOTE BUSTER_TLS_SET tlsB1 {B|151 - 162} NOTE BUSTER_TLS_SET tlsB2 {B|163 - 178} NOTE BUSTER_TLS_SET tlsB3 {B|179 - 193} NOTE BUSTER_TLS_SET tlsB4 {B|194 - 199}
Put that into a file called 3c57.TLSMD and do
refine -M TLSalternate -TLS 3c57.TLSMD -p 3c57.pdb -m 3c57.mtz \ -d with-complicated-tls | tee with-complicated-tls.lis
where the TLSalternate macro runs alternate cycles of TLS-model refinement and geometry refinement, starting with a TLS cycle.
The TLSbasic macro would pick up the TLS information which is in the headers of 3c57 (which is quite similar to the TLSMD decomposition, though with five groups per chain rather than four); so for a control run you need to provide a file 3c57.simpleTLS
NOTE BUSTER_TLS_SET tlsA {A|*} NOTE BUSTER_TLS_SET tlsB {B|*}
and run
refine -M TLSalternate -TLS 3c57.simpleTLS -p 3c57.pdb -m 3c57.mtz \ -d with-simple-tls | tee with-simple-tls.lis
To see what happens using the decomposition in the PDB headers,
refine -M TLSalternate -M TLSbasic -p 3c57.pdb -m 3c57.mtz \ -d with-deposited-tls | tee with-deposited-tls.lis
The scores are
Protocol | Rfact | Rfree |
No TLS | 20.6% | 23.4% |
Simple | 19.8% | 22.5% |
Decomposition from PDB headers | 19.0% | 20.7% |
Decomposition from TLSMD | 19.0% | 20.8% |
So in this sort of situation there can be a significant advantage gained from using a domain decomposition.