Sorry - the stats DO indicate perfect twinning - I misread the first Email..
Please ignore that comment! Eleanor On 4 July 2014 13:16, Philip Kiser <p...@case.edu> wrote: > Hi Eleanor, > > If I'm not mistaken, the mean I stats​ are indicating perfect twinning. > > Philip > > > On Fri, Jul 4, 2014 at 4:49 AM, Eleanor Dodson <eleanor.dod...@york.ac.uk> > wrote: > >> To answer the original question. >> The indicators are that it is not twinned, >> If the Mean s are close to the untwinned values - you can probably >> believe it. >> >> Why are you worried? >> Eleanor >> >> >> Determining possible twin laws. >> >> 0 merohedral twin operators found >> 0 pseudo-merohedral twin operators found >> In total, 0 twin operator were found >> >> >> Mean |L| :0.378 (untwinned: 0.500; perfect twin: 0.375) >> Mean L^2 :0.205 (untwinned: 0.333; perfect twin: 0.200) >> >> >> >> >> >> On 3 July 2014 15:50, Nat Echols <nathaniel.ech...@gmail.com> wrote: >> >>> On Thu, Jul 3, 2014 at 6:53 AM, Dirk Kostrewa < >>> kostr...@genzentrum.lmu.de> wrote: >>> >>>> yes - unfortunately, in my hands, phenix.xtriage reads the >>>> XDS_ASCII.HKL intensities as amplitudes, producing very different output >>>> statistics, compared both to the XDS statistics and to an mtz file with >>>> amplitudes created from that XDS file. >>>> >>> >>> This is incorrect. It does read it correctly as intensities - the >>> confusion probably arises from the fact that Xtriage internally converts >>> everything to amplitudes immediately, so that when it reports the summary >>> of file information, it will say "xray.amplitude" no matter what the input >>> type was (the same will also be true for Scalepack and MTZ formats). >>> However, the data will be converted back to intensities as needed for the >>> individual analyses. Obviously this isn't quite ideal either since the >>> original intensities are preferable but for the purpose of detecting >>> twinning I hope it will be okay. In any case the incorrect feedback >>> confused several other users so it's gone as of a few weeks ago, and the >>> current nightly builds will report the true input data type. (The actual >>> results are unchanged.) >>> >>> Tim: I have no reason to think we handle unmerged data poorly; I'm not >>> sure who would have told you that. In most cases they will be merged as >>> needed upon reading the file. I'm a little concerned that you're getting >>> such different results from Xtriage and pointless/aimless, however. Could >>> you please send me the input and log files off-list? Dirk, same thing: if >>> you have an example where XDS and Xtriage are significantly in >>> disagreement, the inputs (and logs) would be very helpful. In both cases, >>> I suspect the difference is in the use of resolution cutoffs and >>> absolute-scaled intensities in Xtriage versus other programs, but I'd like >>> to be certain that there's not something broken. >>> >>> thanks, >>> Nat >>> >> >> >
