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.
>>
>