[phenixbb] regarding number of unique reflections
Phil Jeffrey
pjeffrey at princeton.edu
Fri Jan 14 06:52:30 PST 2022
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
More information about the phenixbb
mailing list