 |
 |
I'm not sure I entirely agree with ZO's assessment that a B factor is a measure of uncertainty. Pedantically, all it really is is an instruction to the refinement program to "build" some electron density with a certain width and height at a certain location. The result is then compared to the data, parameters are adjusted, etc. I don't think the B factor is somehow converted into an "error bar" on the calculated electron density, is it? For example, a B-factor of 500 on a carbon atom just means that the "peak" to build is ~0.02 electron/A^3 tall, and ~3 A wide (full width at half maximum). By comparison, a carbon with B=20 is 1.6 electrons/A^3 tall and ~0.7 A wide (FWHM). One of the "bugs" that Dale referred to is the fact that most refinement programs do not "plot" electron density more than 3 A away from each atomic center, so a substantial fraction of the 6 electrons represented by a carbon with B=500 will be sharply "cut off", and missing from the FC calculation. Then again, all 6 electrons will be missing if the atoms are simply not modeled, or if the occupancy is zero. The point I am trying to make here is that there is no B factor that will make an atom "go away", because the way B factors are implemented is to always conserve the total number of electrons in the atom, but just spread them out over more space. Now, a peak height of 0.02 electrons/A^3 may sound like it might as well be zero, especially when sitting next to a B=20 atom, but what if all the atoms have high B factors? For example, if the average (Wilson) B factor is 80 (like it typically is for a ~4A structure), then the average peak height of a carbon atom is 0.3 electrons/A^3, and then 0.02 electrons/A^3 starts to become more significant. If we consider a ~11 A structure, then the average atomic B factor will be around 500. This "B vs resolution" relationship is something I derived empirically from the PDB (Holton JSR 2009). Specifically, the average B factor for PDB files at a given resolution "d" is: B = 4*d^2+12. Admittedly, this is "on average", but the trend does make physical sense: atoms with high B factors don't contribute very much to high-angle spots. More formally, the problem with using a high B-factor as a "flag" is that it is not resolution-general. Dale has already pointed this out. Personally, I prefer to think of B factors as a atom-by-atom "resolution" rather than an "error bar", and this is how I tell students to interpret them (using the B = 4*d^2+12 formula). The problem I have with the "error bar" interpretation is that heterogeneity and uncertainty are not the same thing. That is, just because the atom is "jumping around" does not mean you don't know where the centroid of the distribution is. The "u_x" in B=8*pi^2*<u_x^2> does reflect the standard error of atomic position in a GIVEN unit cell, but since we are averaging over trillions of cells, the "error bar" on the AVERAGE atomic position is actually a great deal smaller than "u". I think this distinction is important because what we are building is a model of the AVERAGE electron density, not a single molecule. Just my 0.02 electrons -James Holton MAD Scientist On Fri, Apr 1, 2011 at 10:57 AM, Zbyszek Otwinowski <[log in to unmask]> wrote: > The meaning of B-factor is the (scaled) sum of all positional > uncertainties, and not just its one contributor, the Atomic Displacement > Parameter that describes the relative displacement of an atom in the > crystal lattice by a Gaussian function. > That meaning (the sum of all contributions) comes from the procedure that > calculates the B-factor in all PDB X-ray deposits, and not from an > arbitrary decision by a committee. All programs that refine B-factors > calculate an estimate of positional uncertainty, where contributors can be > both Gaussian and non-Gaussian. For a non-Gaussian contributor, e.g. > multiple occupancy, the exact numerical contribution is rather a complex > function, but conceptually it is still an uncertainty estimate. Given the > resolution of the typical data, we do not have a procedure to decouple > Gaussian and non-Gaussian contributors, so we have to live with the > B-factor being defined by the refinement procedure. However, we should > still improve the estimates of the B-factor, e.g. by changing the > restraints. In my experience, the Refmac's default restraints on B-factors > in side chains are too tight and I adjust them. Still, my preference would > be to have harmonic restraints on U (square root of B) rather than on Bs > themselves. > It is not we who cram too many meanings on the B-factor, it is the quite > fundamental limitation of crystallographic refinement. > > Zbyszek Otwinowski > >> The fundamental problem remains: we're cramming too many meanings into > one number [B factor]. This the PDB could indeed solve, by giving us > another column. (He said airily, blithely launching a totally new flame > war.) >> phx. >> >