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.