On Thu, Oct 20, 2011 at 12:14 PM, R.M. Garavito
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