a) the main program ("xds", or "xds_par") writes only one type of file, called XDS_ASCII.HKL. This has _unmerged_ observations, and this is therefore currently _unsuitable_ for reading by Phenix programs (since the Phenix routine expects merged, unique reflections). If this is nevertheless tried, I see the danger that Phenix might "eat" all observations of a unique reflections except one, possibly without telling about this problem (? - I didn't try!!) - this is definitely not what you want!
We have a simple way of merging symmetry-equivalent observations, which is used (for example) when we read unmerged scalepack files.
b) the program "xscale" can write an output file with unmerged observations. This is the default, and corresponds to MERGE=FALSE in XSCALE.INP . As for a), this is also not what you want!
I've never been sure about the tradeoff between convenience and correctness. We could read this file type and merge the observations ourselves, which is convenient, but is the result as good as letting XDS (or scalepack or scala) do the merging?
c) the program "xscale" can write an output file with merged observations. This is not the default, but can be obtained by using MERGE=TRUE in XSCALE.INP . This is what you want to read with Phenix programs.
Thus only possibility c) will give you a "native XDS" file that is ready to be read by Phenix programs.
A reader for this file type has been part of Phenix for many years:
Does this still look right?
In addition to this possibility, one can use of course use "xdsconv" to go from XDS_ASCII.HKL (or any file written by "xscale") to a (non-native XDS) filetype that Phenix programs can read. The most general should be to write a MTZ file, but CNS/X-PLOR type files can also be produced.
Great to know that you can export to MTZ files; I wasn't aware of this before. This looks like the best option in most cases, since the symmetry information is preserved in MTZ files (but not CNS files).
Ralf