[phenixbb] zero B-factors
pafonine at lbl.gov
Mon Nov 25 08:12:40 PST 2013
you can see it as a histogram. Also phenix.refine log shows histograms
of B-factors that will capture this.
Most of the time the problem is not about not having the information but
not knowing what to look for or not willing to look. Then eventually
overlooked problems get discovered later down the road by someone else.
On 11/25/13 7:59 AM, Engin Özkan wrote:
> I think what was meant is Phenix report not only *residues* with
> "suspiciously high B-factors" as it does in the GUI (thanks!), but also
> those with suspiciously low. As said, one could then detect that one
> water that was actually a big ion. The overall comparisons reported by
> POLYGON are useful for determining refinement parameterization and such,
> but not details like this.
> On 11/25/13, 9:40 AM, Pavel Afonine wrote:
>> Hi Morten,
>> POLYGON is the tool for this. Definition "too low/high" is relative
>> and depends on resolution.
>> On 11/25/13 4:29 AM, Morten Grøftehauge wrote:
>>> It would be nice if the validation procedures looked for B-factor
>>> outliers that were too low as well as too high. A very low B-factor can
>>> be indicative of the wrong atom, e.g. a water molecule that is actually
>>> an ion.
>>> On 18 November 2013 21:38, Pavel Afonine <pafonine at lbl.gov
>>> <mailto:pafonine at lbl.gov>> wrote:
>>> If you see this problem using the latest Phenix version then please
>>> send me files (off-list) necessary to reproduce it and I will
>>> If interested what was the "problem" causing zero B-factors please
>>> see below.
>>> In a nutshell the problem is this. Assuming total model structure
>>> factor is (for simplicity):
>>> F ~ exp(-Boverall_scale * s**2) * exp(-Batoms * s**2)
>>> it's clear that any combination of Boverall_scale and Batoms that
>>> maintains Boverall_scale+Batoms=const will not change total model
>>> structure factors (and therefore R-factors, maps, etc).
>>> The new bulk-solvent and overall scaling algorithm that we
>>> implemented sometime in April 2012 and that went into 1.8_1069
>>> originally did not care about returning isotropic component of
>>> Boverall_scale back to atoms (Batoms):
>>> In fact, it assumed that overall contribution (overall B that is
>>> equal for all atoms) should stay in Boverall_scale (indeed, why keep
>>> common B in all individual atomic B-factors!?), and the rest goes
>>> into Batoms.
>>> This behavior typically generates user concerns about "too small"
>>> An alternative agreement is to postulate that the matrix
>>> Boverall_scale is traceless meaning that overall B-factor goes into
>>> individual atomic B-factors.
>>> This behavior occasionally generates user concerns about "too large"
>>> A few months later (sometime in end summer/fall 2012) we changed
>>> scaling behavior such that overall B-factor stays in individual
>>> atomic B-factors.
>>> All in all, either way is correct and a matter of agreement and
>>> preferences, but definitely not a bug.
>>> phenixbb mailing list
>>> phenixbb at phenix-online.org <mailto:phenixbb at phenix-online.org>
>>> Morten K Grøftehauge, PhD
>>> Pohl Group
>>> Durham University
>>> phenixbb mailing list
>>> phenixbb at phenix-online.org
>> phenixbb mailing list
>> phenixbb at phenix-online.org
> phenixbb mailing list
> phenixbb at phenix-online.org
More information about the phenixbb