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

[Frank von Delft]

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 
said hesitantly...)
phx.


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)
>
> where:
>
> 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 
> choose.
>
> 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 
> higher.
>
> 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 
> resolution.
>
> 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.
>
> Pavel.
>
>
>
> 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
>> 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
>> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
>