[phenixbb] Clarification on ADPs in PDB files for TLS refinement ?
Frank von Delft
frank.vondelft at sgc.ox.ac.uk
Fri Jan 8 07:26:57 PST 2010
I think Phil was suggesting the docs get updated, because that *is*
where people will look first rather than the BB or a 2002 paper. (He
Pavel Afonine wrote:
> 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 this:
> 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
> 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:
>> 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
>> U(TOTAL)= U(ATOM) + U(TLS) + U(CRYST)
>> 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
>> 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
>> phenixbb mailing list
>> phenixbb at phenix-online.org
> phenixbb mailing list
> phenixbb at phenix-online.org
More information about the phenixbb