Phil, absolutely. I have routinely use AIMLESS on XDS and sometimes on
SCALEPACK output.
I should clarify that in the scenario I described earlier, complete XDS or
SCALEPACK output would *not* be available, but only Is and SIGIs. What
would be the best strategy to 'trick' POINTLESS/AIMLESS into accepting
duplicate HKLs, independently observed, beginning with, say, a
(3f5.0,f9.1,f7.1) text file? Increment batch numbers by 2, to negate the
"adjacency" condition? I assume (correctly?) that with the 'onlymerge'
option, batch numbers are not relevant to the merging outcome, as long as
POINTLESS/AIMLESS would accept 'independent duplicates' as 'non-partial'.
W.
On Tue, Jun 10, 2014 at 12:44 PM, Phil Evans <p...@mrc-lmb.cam.ac.uk> wrote:
> XDS_ASCII.HKL or scalepack format ('no merge original index') can be read
> directly by Pointless which should (I hope) do a better job than COMBAT.
>
> Aimless (& Pointless) assume two reflections are part of the same one if
> they have the same "true" hkl (same ISYM) and adjacent batch numbers (and a
> few other conditions, e.g. total fraction). Output from COMBAT may be wrong
> in this respect
>
> Phil
>
> On 10 Jun 2014, at 17:23, wtempel <wtem...@gmail.com> wrote:
>
> > Hello all,
> > suppose I extracted
> > H K L Intensity sigma[Intensity]
> > from a file of unmerged intensities, such XDS_ASCII.HKL or scalepack
> format ('no merge original index'). Batch or rotation angle information
> would have been omitted, due to a limitation of the output file's format.
> > Should I not still be able to merge these intensities without scaling,
> such as in AIMLESS with the 'onlymerge' option?
> > I coerced the ascii-formatted reflections into MTZ format using COMBAT,
> specifying '1' for the mandatory BATCH keyword. Subsequently, POINTLESS
> output the following lines
> >
> > ##
> > Number of reflections = 62739
> > Number of observations = 210959
> > Number of parts = 252273
> > ##
> >
> > The discrepancy between numbers for "observations" and "parts" exactly
> matches double the number of HKLs with two occurrences in my input file.
> How could I force treatment of duplicate HKLs as independent observations,
> given that I have lost the batch information?
> > Would it be sufficient to apply 'artificial' batch numbers 1, 2, ... to
> disambiguate between duplicate HKLs?
> > Thanking you in advance for any advice,
> > Wolfram Tempel
>
