[phenixbb] Filtering ordered solvent molecules based on secondary map

Pavel Afonine pafonine at lbl.gov
Wed Jan 5 15:08:25 PST 2011


  Hi Andrew,

>                 Thanks for the helpful comments.  Do both 
> phenix.model_vs_data and phenix.real_space_correlation produce the 
> same values for CC that phenix.refine uses to keep/remove waters when 
> the ordered solvent routine is used?
>

yes, they should. They use the same code - that's the joy of having 
libraries: multiple applications can re-use the same core routines.
>
>                 Also, are the default 2mFo-DFc and mFo-DFc map 
> coefficients output by phenix.refine (in the "_maps_coeffs.mtz" file) 
> the same coefficients used by phenix.refine during the ordered solvent 
> checking?
>

This I would need to check since I don't remember. As I hope all 
phenix.refine users know, by default phenix.refine writes out two 
2mFo-DFc maps (one is using original Fobs set, and one using Fobs set 
where missing Fobs are filled with DFc), and one mFo-DFc map. Most 
likely, for water picking phenix.refine uses the one 2mFo-DFc map that 
uses original set of Fobs.

>   Specifically, does phenix.refine use "filled" maps for ordered 
> solvent checking?
>

Unlikely.
>
>                 If you haven't guessed, I am thinking of a way to 
> intelligently pick values for the ordered solvent parameters such as 
> primary_map_cutoff, poor_cc_threshold and poor_map_threshold.
>

Yes, I kind of figured this out... -:) Although I'm wondering why you 
are not happy with the default settings which are supposed to be good 
enough most of the time?

> My idea is to first run a quick round of refinement with generous 
> ordered solvent parameters  so that I get a model that is somewhat 
> overpopulated with automatically-picked waters.  Then I can manually 
> inspect the mFobs-DFmodel and 2mFobs-DFmodel maps (i.e. primary and 
> secondary maps) and the CC values in order to decide where to select 
> appropriate cutoffs to limit addition of spurious waters for a given 
> model/dataset, which will differ based on map quality, resolution, 
> etc.  So obviously I want to calculate CC values and maps in the same 
> way phenix.refine would to judge waters so that I can "see what phenix 
> sees" in this regard.
>

I see. I think you are on the right track to achieve this. Depending how 
generous you are setting the water selection criteria you can get as 
many waters as you want. This is not always bad (as many typically 
think) but just emulates some earlier versions of ARP idea which is in 
the end is pretty successful. That is: modeling some density peaks that 
you cant interpret in terms o your model right now with "dummy waters" 
may improve the overall map quality which might be helpful.

Pavel.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20110105/38a11fc2/attachment-0003.htm>


More information about the phenixbb mailing list