Re: [phenixbb] zero B-factors

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

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

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