[phenixbb] Unusual CCP4 to Phenix data conversion result

Nathaniel Echols nechols at lbl.gov
Thu Oct 20 12:30:10 PDT 2011

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

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


More information about the phenixbb mailing list