On Thu, Oct 20, 2011 at 12:14 PM, R.M. Garavito <[email protected]> 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
_______________________________________________
phenixbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/phenixbb