[phenixbb] zero B-factors
Pavel Afonine
pafonine at lbl.gov
Mon Nov 25 20:02:02 PST 2013
Yes, your are right, it would be good to have it..
Pavel
On 11/25/13 8:21 AM, Engin Özkan wrote:
> I was looking at this histogram when I wrote that email :) but that
> histogram is not clickable and does not report residue names (unlike the
> list just below it). I always look at the histogram (and its usually
> Poisson-like shape is intriguing). It was just a suggestion to add the
> other end of the distribution to the list of outlier residues reported
> by Phenix.
>
> Engin
>
> On 11/25/13, 10:12 AM, Pavel Afonine wrote:
>> Engin,
>>
>> 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.
>>
>> Pavel
>>
>> 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.
>>>
>>> Engin
>>>
>>> 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.
>>>>
>>>> Pavel
>>>>
>>>> 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.
>>>>>
>>>>> Morten
>>>>>
>>>>>
>>>>> 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
>>>>> investigate.
>>>>>
>>>>> If interested what was the "problem" causing zero B-factors please
>>>>> see below.
>>>>>
>>>>> Thanks,
>>>>> Pavel
>>>>>
>>>>>
>>>>> 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):
>>>>>
>>>>> http://journals.iucr.org/d/__issues/2013/04/00/dz5273/__dz5273.pdf
>>>>> <http://journals.iucr.org/d/issues/2013/04/00/dz5273/dz5273.pdf>
>>>>>
>>>>> 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"
>>>>> B-factors.
>>>>>
>>>>> 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"
>>>>> B-factors.
>>>>>
>>>>> 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>
>>>>> http://phenix-online.org/__mailman/listinfo/phenixbb
>>>>> <http://phenix-online.org/mailman/listinfo/phenixbb>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Morten K Grøftehauge, PhD
>>>>> Pohl Group
>>>>> Durham University
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
More information about the phenixbb
mailing list