[phenixbb] regarding number of unique reflections

[Phil Jeffrey]

On 1/13/22 5:21 AM, Randy John Read wrote:
> No, I disagree strongly with that suggestion about pruning the data!

The Original Poster's question arises from a manifestation of 
phenix.refine usurping user intent over which data to use during refinement.


Pruning the data - which I do routinely - is a reaction to 
phenix.refine's very ill-advised behavior to pull intensities rather 
than structure factors from a MTZ file that contains both.  It seems to 
then convert the intensities to F's and refine against those F's. 
phenix.refine also has an unhealthy tendency of grabbing the anomalous 
data and using that in refinement, even when there's little present.

This ignores user intent as it is a conscious additional step to convert 
I to F after data processing.  As long as phenix.refine maintains that 
default behavior, I will remove intensities from the reflection file 
prior to refinement.  Often (as, I imagine, today) this will result in 
me not depositing intensities since I invariably deposit the files used 
in refinement.

I can specify the reflection data used, but my command line for that 
program is already long, and the default behavior should not be to 
ignore user intent.  I would expect that this is a significant source of 
discrepancy upon PDB deposition, and frequently at odds with what the 
user had intended to do.  I don't think BUSTER behaves like that.  I 
doubt that's true for REFMAC but I don't often run it from the command line.

Fix the program to avoid second-guessing the experimenter, and you'll 
probably get more intensities deposited in PDB.


Phil Jeffrey
Princeton