[phenixbb] phenix.refine 1.3 vs. 1.4 map quality ?

Pavel Afonine PAfonine at lbl.gov
Thu Aug 6 08:11:57 PDT 2009


Hi Bill,

> About a year ago I refined a 1.6 Å RNA structure with phenix.refine  
> 1.3b-rc6 and then got distracted.  

I'm not sure I got the message... Was anything wrong about the maps? If 
so, did you let us know (sorry, I don't remember).

> I picked it up today and  
> essentially repeated the last round of refinement with 1.4-57 (and  
> also 1.4-159).  The maps are subtly different, but consistently  
> slightly worse with 1.4.
>   

Which maps we are looking at? I presume 2mFo-DFc (not 2Fo-Fc): regular? 
filled? kicked? (see copies of previous emails to the BB explaining 
these maps at the bottom of this email).

> Here are two examples:  http://sage.ucsc.edu/~wgscott/mystuff/old_vs_new.pdf
>   

May be because I'm looking at static pictures, but apart from the water  
#5, the differences seem subtle indeed.

> In the second example, this would lead to deletion of one of the  
> octahedrally coordinated waters on a known Mg++ ion.
>   

Do you mean you would delete this water manually because you don't see 
it in the map, or phenix.refine deletes it?

> Has the weighting for the bulk solvent mask or something like that  
> been increased?
>   

I can name two major things:

- phenix.refine outputs "filled" maps by default since December 2008 (or 
may be January 2009?);
- a few weeks (a month?) ago we switched to using a faster and more 
memory efficient bulk solvent mask calculation code. Plus this new code 
has a minor bug fixed that existed many years in the old one.

If you send me 1.6A resolution data and your best model, I will be happy 
to have a closer look.

Pavel.


PS> Copies of replies to BB about kicked and filled maps:

Kick maps:
"""
there will be a paper about it in next coming Acta D. This method was 
introduced about 10-15 years ago by Dusan Turk in his program MAIN is 
used since that. Here is the copy-paste from the manuscript:

"(...) An average kick map (AK map) is computed as following (Gunc(ar et 
al., 2000; Turk, 2007; Praz(nikar et al., 2009): a large ensemble of 
structures (several hundreds) is created where the coordinates of each 
structure from the ensemble are all randomly shaken. The shake amount 
(rmsd distortion introduced to coordinates) varies from 0 to 1.0 Å. Then 
for each structure a map is computed ((mFobs-DFmodel)exp(i?model)  or 
(2mFobs-DFmodel)exp(i?model) or any other map, for example a ligand-omit 
map). Finally, all maps are averaged out to produce one averaged kick 
map. An AK map is expected to have less or no bias, less noise, enhance 
existing signal and potentially can clear up some initially bad 
densities. (...)"
""".

Filled maps:
"""
Hi Everyone,

I think it's time to review this subject since it is one of the most 
frequently asked questions. Ironically, I think this is because we tried 
to make it as clear as possible -:)

So, what kind of maps phenix.refine outputs by default? phenix.refine 
outputs two types of maximum-likelihood weighted maps (or, in other 
words, sigmaa-weighted maps): 2mFo-DFc and mFo-DFc.

Now, as many of you noticed, the MTZ file with map coefficients 
"_map_coeffs.mtz" contains in fact four maps: 2mFo-DFc and mFo-DFc, and 
"filled" 2mFo-DFc and mFo-DFc (in fact fo-fc maps should be nearly 
identical; actually I have to fix it and not write identical fo-fc 
maps).  The first two maps are computed using original Fobs (Fo), and 
the last two maps are computed using "filled Fobs", that is the original 
Fobs where missing reflections are "filled" with DFc. It is well known 
(I can spell a long list or references) that the data incompleteness 
affects the map quality, and sometimes, certain types of data 
incompleteness can *severely* distort maps.

A possible solution (in order to reduce this negative effect) is to 
"model" missing Fobs somehow. One possibility is just to put in DFc in 
place where Fobs is missing, or as suggested by the classics, one can 
use <Fobs> taken in a resolution bin around a missing reflection. I even 
tried to use the random numbers and it was also better than doing 
nothing. Obviously, there is a nearly invisible line between the 
benefits of "filling in" missing Fobs and introducing bias. Where this 
line goes - is the subject of a research that to my knowledge is not 
done yet.

Anyway, this is why phenix.refine writes out "regular" and "filled" 
maps: one is to give you unbiased but eventually lower quality map, and 
the other one is to give you a better-looking map with a risk of being 
biased. This way users have more options in exploring their maps (and 
less reasons for saying that Refmac produces better-appearing maps than 
phenix.refine -- see below).

I have to mention that to my knowledge REFMAC always writes "filled" 
maps (those with missing Fobs substituted by DFc):

- it is mentioned in Maria Turkenburg's thesis:
http://www.ysbl.york.ac.uk/~mgwt/thesis-tth/chapter2.html#tth_sEc2.6.5

- and in Refmac docs:
http://www.ccp4.ac.uk/html/refmac5/keywords/xray-general.html

"Missing Data: For those reflections where the FP are missing, mFo is 
set equal to dFc. (...)".

Correct me if I'm missing something.

Please let me know if I wasn't clear in my attempt to explain this. I 
will update the phenix.refine documentation accordingly.

Pavel.
""".


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20090806/648ac7c6/attachment-0003.htm>


More information about the phenixbb mailing list