[phenixbb] Clarification on ADPs in PDB files for TLS refinement ?

Pavel Afonine PAfonine at lbl.gov
Thu Jan 7 10:43:29 PST 2010

Hi Phil,

The total atomic B-factor (ADP) in phenix.refine is defined as:

Utotal = Ucryst + Ugroup + Ulocal,

(of course, you can re-write it in terms of B, which is a trivial 
application of proper scales: J. Appl. Cryst. (2002). 35, 477-480)
(let's stick to U in what follows below)


Ucryst is determined as part of overall anisotropic scaling at bulk 
solvent correction and scaling step, and it goes into total model 
structure factor as following:
Fmodel = scale * exp(-h*Ucryst*ht) * (Fcalc_atoms + k_sol * 
exp(-B_sol*s2) * Fmask) ,
and this is always the case, regardless which refinement strategy you 

The rest, Ugroup and Ulocal and their combinations, depend on refinement 
strategy. Here are a few typical refinement strategies that illustrate 

1) If no TLS is used, but we just refine individual B-factors, then 
Ugroup=0, and the total B-factor is:
Utotal = Ucryst + Ulocal, where Ulocal can be isotropic, anisotropic or 
any mixture, and the ADP restraints are applied to Ulocal, and 
phenix.refine has a large array of various restraints applied to Ulocal, 
depending on whether Ulocal are isotropic or anisotropic.
This is the most basic ADP refinement strategy that is typically used at 
2.5-3.5A resolution and higher.

2) If we use TLS and do structure refinement at say 3.0A resolution or 
higher, then
Utotal = Ucryst + Utls + Ulocal
In this case Utls = function_of(T,L,S), Ulocal are always isotropic 
individual atomic B-factors. The standard restraints (including NCS, if 
any) are always applied to Ulocal only. Moreover, the positive 
definiteness of Utls and Ulocal is not enforced. We only enforce that 
Utotal are positively definite and comply with the symmetry. Ulocal can 
even be refined to a negative value, which is of course nonsensical, but 
potentially can be used as an indicator of bad TLS group separation; 
also, this compensate for a non-optimal choice of TLS groups so the 
Utotal are still correct, even though Utls and Ulocal taken individually 
may not be correct.
This is the most typical ADP refinement strategy at resolutions 3A and 

3) If (for whatever reason) you ask phenix.refine to do TLS refinement 
only, then:
Utotal = Ucryst + Utls.
In this case no restraints are applied. We only enforce that Utotal are 
positively definite and comply with the symmetry.
I've never seen any practical use of it, unless probably at very low 

4) You can also choose simple traditional group isotropic B-factor 
refinement, where you refine one isotropic B-factor per selected set of 
atoms (for example one or two B-factors per residue), in this case:
Utotal = Ucryst + Ugroup.
This is what people typically do at resolutions from 3-3.5 A and lower 
(if they don't want to use TLS).

5) There is also a bit weird refinement option, but I found it the most 
powerful at low resolution. This is when you combine TLS refinement with 
simple traditional group isotropic B-factor refinement. In this case:
Utotal = Ucryst + Utls + Ugroup,
where Utls = function_of(T,L,S) as usual, and Ugroup is one or two 
refinable isotropic B-factors per residue. You can view the Ugroup as a 
work-around to compensate for coarseness or imperfectness of TLS model.
This is the best refinement strategy at resolutions from 3-3.5 A and lower.

I guess I covered most of typical cases that people usually use, 
although in phenix.refine you can mix any strategy with any.

Now, what goes into PDB ATOM and ANISOU records?
The ANISOU record receives Utotal (in Cartesian basis, see reference 
above) = trace(Ucryst) + Ugroup + Ulocal, and the anisotropic part of 
Ucryst (Ucryst - trace(Ucryst)) is stored in PDB file header.
The ATOM record receives Biso, which is isotropic equivalent of Utotal.

Thus defined, all you need to reproduce the R-factors is ATOM and ANISOU 
records, and you do not need anything from PDB file header (except 
CRYST1 record). This is why phenix.refine does it this way.


On 1/7/10 10:19 AM, Phil Jeffrey wrote:
> Hi,
> Having a discussion with a colleague yesterday on differences in 
> Phenix and Refmac representations of TLS B-factors in the PDB file I 
> came across two different definitions for what the PDB ANISOU U's 
> correspond to as written by Phenix:
> 1. From necat.chem.cornell.edu/workshops/.../WK04_PavelAfonine.pdf on 
> p.20
> and only U(atom) + U(tls) is stored in the PDB ANISOU card.
> 2. From http://proteincrystallography.org/ccp4bb/message8948.html
> "Utotal = Utls + Ulocal + Ucryst. So, the ANISOU records
> always contain Utotal and ATOM records contain isotropic equivalent of
> Utotal"
> Which is not the same thing.  I suspect it's #1.  Am I right ?
> I would think that U(cryst) is potentially a non-zero contribution to 
> atomic ANISOU values but is actually applied before the 
> TLS/Anisotropic B-factors are refined.
> As a tie-breaker between #1 and #2 the program documentation suggest 
> that it is just U(tls)+U(atom) but the paragraph that nominally 
> explains it is not short of of inconsistencies, referring to the 
> ANISOU record as having the "the total B-factor (B_tls + 
> B_individual)" whereas they're not only not B's (they are U's) but 
> it's also not the *total* U or B by its own definitions.  IMHO it 
> would warrant a rewrite for clarity since   B and U are used 
> interchangeably and "total" has variable usage.
> Phil Jeffrey
> Princeton
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20100107/3f6beda3/attachment-0002.htm>

More information about the phenixbb mailing list