[phenixbb] XDS files in Phenix

Jianghai Zhu jzhu at idi.harvard.edu
Fri Jun 10 16:23:48 PDT 2011


Hi,

I believe the unmerged data is very important for autosol.  I had one case that phenix.autosol gave me a very good map using unmerged data from XSCALE (converted to CNS format by XDSCONV) while no meaningful results using merged data from XSCALE (converted to mtz format by XDSCONV).  So it would save me the hassle of format converting if phenix.autosol is able to read unmerged XDS file directly.  

-- Jianghai




On Jun 10, 2011, at 6:48 PM, Thomas C. Terwilliger wrote:

> Hi Ralf and Kay,
> 
> One small additional note:  autosol can read unmerged MTZ or .sca files
> (without using the reflection_reader that merges these reflections) and
> takes advantage of the extra information that they offer for local
> scaling.  This could be extended to XDS or other files as well.
> 
> All the best,
> Tom T
> 
>>> Am 10.06.2011 18:27, schrieb Ralf Grosse-Kunstleve:
>>>> Hi Kay,
>>>> 
>>>> Thanks for the explanations!
>>>> 
>>>>    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.
>>> 
>>> this sounds useful - where can I see this? If this could be enabled then
>>> there is no reason not to read files of type a) or b) .
>>> 
>>>> 
>>>>    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?
>>> 
>>> I can only speak for XDS - and that internally does just the obviously
>>> correct thing:
>>> a) reject observations with negative sigma
>>> b) use the standard formulas - see
>>> http://en.wikipedia.org/wiki/Weighted_mean#Dealing_with_variance
>>> 
>>> I'd be surprised if SCALEPACK and SCALA use different formulas.
>>> 
>>>> 
>>>>    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:
>>>> 
>>>> http://cci.lbl.gov/cctbx_sources/iotbx/xds/read_ascii.py
>>>> 
>>>> Does this still look right?
>>> 
>>> yes - except it should reject observations with negative sigma (maybe
>>> I'm overlooking it) but these probably don't occur in MERGE=TRUE files.
>>> 
>>> and yes - it seems to check that "MERGE=TRUE" so I guess it will
>>> complain in case a) and b) .
>>> 
>>>> 
>>>>    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
>>> 
>>> in fact xdsconv writes the necessary files, and prints a few lines of
>>> output to the screen that just have to be cut-and-pasted to get an MTZ
>>> file. Of course this could also easily be scripted.
>>> 
>>>> before. This looks like the best option in most cases, since the
>>>> symmetry information is preserved in MTZ files (but not CNS files).
>>>> 
>>>> Ralf
>>>> 
>>> 
>>> thanks,
>>> 
>>> Kay
>>> _______________________________________________
>>> phenixbb mailing list
>>> phenixbb at phenix-online.org
>>> http://phenix-online.org/mailman/listinfo/phenixbb
>>> 
> 
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
> 



More information about the phenixbb mailing list