[phenixbb] Unusual CCP4 to Phenix data conversion result

[Nathaniel Echols]

On Thu, Oct 20, 2011 at 12:14 PM, R.M. Garavito <garavito at msu.edu> wrote:
> However, I just noticed that in testing the upgraded CCP4 and Phenix on OSX
> 7.2 (Lion) that the MTZ file is no longer read correctly.  An example is
> below where after the output from scaling and merging of nonanomalous
> data from the CCP4i GUI gives, at the end of FREERFLAG, some 47,000
> reflections.  Putting this into xtriage or the reflection file editor in the
> Phenix GUI, one finds that the data for the F and the DANO columns are used;
> just selecting Fs alone is impossible.  The end result is a doubling of the
> reflection number and the switching of the anomalous flag on.  Processing
> with earlier versions did not do this except when actually using anomalous
> data.
> Why this has happened is not clear to me, but the column order in the MTZ
> file changed slightly between CCP4 6.1.13 and CCP4 6.2.0.  Any ideas, am I
> missing something, or is this a push to only refine with intensities?

It's actually more an inherent problem with representing data as
merged amplitudes and anomalous differences (and how we handle them) -
PHENIX does not use these data as such, and instead converts them into
what Ralf calls "reconstructed" amplitudes, i.e. F(+) SIGF(+) F(-)
SIGF(-).  There is potential for loss of precision in this conversion,
which is why we recommend against it (the Phaser-EP GUI will actually
complain if you try to run it with those data).  The reason this
changed is probably F SIGF being adjacent to DANO SIGDANO in the MTZ
file - if they were previously separated by other columns, they would
not be automatically combined into a single data array.

I'm not sure if this matters for Xtriage; it will still perform the
analysis of anomalous signal based on the reconstructed Friedel pairs,
but I don't know of use of separate F+/F- will affect the other
analyses.  It definitely makes a difference for the reflection file
editor and any other program which outputs these data, because they
will always end up as F(+) SIGF(+) F(-) SIGF(-).  Unfortunately I
didn't take into account that the reflection file editor was doing
this until a few days ago, so in version 1.7.2 it will probably still
label the columns F SIGF DANO SIGDANO (or the equivalent) by default.
I think the latest nightly build should fix this bug (and several
others).

This is probably not an ideal situation - it might make more sense to
simply ignore DANO SIGDANO, just to avoid confusion, but I'm worried
that users will complain about PHENIX not accepting their anomalous
data.

-Nat