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 [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

---

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

Hi David, it's hard to say without looking at concrete example. phenix.refine creates maps as good as it can - I mean you don't need to "toggle something on" to get even better map. phenix.refine can output maps either as Fourier map coefficients that you can see then as actual map in Coot (for example) or it can output X-plor formatted maps (which you can see in PyMol, for example). I'm not sure if an additional conversion step (into dsn6) may alter something. Do you have an example in which: - you take a model and data and compute X-plor formatted map in CNS, - then you take the exact same data and model and compute the same map in phenix.refine, - you look at both maps in PyMol and see the "weak features" in CNS map and do not see these "weak features" in phenix.refine map ? If you have such an example and can send it to me then I would have something to investigate. Otherwise I can only shake the air with my guesses/speculations. Also, you may consider looking at both maps: missing-Fobs-filled and regular ones. phenix.refine create both types: http://www.phenix-online.org/pipermail/phenixbb/2009-August/002315.html Pavel. On 2/26/10 2:29 PM, David Garboczi wrote:

We sometimes build model into density at ~0.8 sigma, refine, and the Rfree becomes lower. So we believe that we put model where it should be.

Running the same data and same model in phenix under default conditions at the command line, we obtain maps that do not show the weaker features in which we believe in CNS.

We are wondering if we can believe the weaker density or is it that we are not toggling something on in phenix.

We routinely view the phenix-generated maps after transforming them to dsn6 files in mapman.

thanks, Dave