Dear Nat, I won't need to send the header, the first line looks as you expect. FRIEDEL'S_LAW=TRUE in the XDS_ASCII.HKL does not mean that the Friedel pairs are merged (it would, though in XSCALE output in combination with MERGE=TRUE). The former keyword affects the scaling, and both Wolfgang Kabsch and George Sheldrick are of the opinion the scaling gives better results by using twice the number of data without hampering with the data quality by ignoring the anomalous differences. XDS does not have the keyword 'merge', only xscale does, but there is not reason to scale the data twice, as XDS output data are already scaled. I will see how far I get with xscale output, but scientifically it would be beneficial for phenix to allow said XDS format (I agree that shelx hkl-format is not a joy for GUIs). We are using the latest release, version 1.8.4. Cheers, Tim On 01/14/2014 04:53 PM, Nathaniel Echols wrote:

On Tue, Jan 14, 2014 at 4:42 AM, Tim Gruene wrote:

...

I would like to run Phaser-EP through the phenix GUI. When I first uploaded the XDS_ASCII.HKL file, there was an error message about "No valid observed reflections found in this file".

Can you send me the first three lines of the file? My guess is that it looks like this:

!FORMAT=XDS_ASCII MERGE=FALSE FRIEDEL'S_LAW=TRUE

which would be interpreted by our XDS reader as being non-anomalous, even though since it's unmerged there is probably nothing stopping us from using the anomalous data anyway. (I need to double-check this, because I don't understand why it would claim "FRIEDEL'S_LAW=TRUE" if I+ and I- are actually kept separate.) If you instead produce a file that starts like this:

!FORMAT=XDS_ASCII MERGE=TRUE FRIEDEL'S_LAW=FALSE

then it will be accepted by the Phaser-EP GUI.

Subsequently I

...

uploaded an unmerged hklf4 file. The GUI tells me I need to let phenix know about it being hklf4 by appending '=hklf4'. However, when I do so, there is an error message the file did not exist and the Data file line goes red. Where should I correctly append '=hklf4'?

This may simply be a bug. Which version are you using? I had attempted to make the GUI handle SHELX files more sensibly (to the extent that's even possible), but I can't remember how successful I was, and it may have been after version 1.8.4 was released. In general, SHELX format is the least compatible of the supported inputs; it's just missing too much information.

-Nat

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

-- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A

On Tue, Jan 14, 2014 at 9:09 AM, Ryan wrote:

Have you tried using XDSCONV, it will convert the HKL file to an MTZ without much trouble. Is there are reason you want the unmerged HKL file rather than using XSCALE for scaling and merging? You can choose to leave the data unmerged in XSCALE but converting it to an MTZ file will automatically merge the data.

There is also this (in the latest nightly builds - not yet part of the GUI, but I'll add it today): iotbx.export_scalepack_unmerged xds_ascii.hkl The motivation here being that SOLVE (the only program in Phenix that actually uses unmerged data for anything other than reporting statistics) will read unmerged Scalepack files, but not XDS. -Nat

On Tue, Jan 14, 2014 at 10:24 AM, Tim Gruene wrote:

merged data are an old-fashiond left-over from days when disk space was an issue. It's a shame the PDB only allow merged data, otherwise one could much more easily retrieve data statistics and anomalous data from what has been submitted. I would have thought phenix is more sophisticated by merging internally.

That is exactly what happens - and programs like phenix.merging_statistics and Xtriage will report Rsym, CC1/2, and friends. The problem in this case was that when I modified the XDS reader to handle unmerged data, I forgot to change the way it deals with FRIEDEL'S_LAW=TRUE. This is now fixed, and the next nightly build should handle your file appropriately. PS. It's possible I'm still misunderstanding the meaning of FRIEDEL'S_LAW=TRUE. Under what circumstances does XDS output anomalous vs. non-anomalous data? PS #2: One of the many benefits of the mmCIF switch is that it should make deposition of unmerged data much easier. (We don't have the tools to handle this yet, but we're working on it.) -Nat