Re: [ccp4bb] merging of reflection with identical indices
Hi Wolfram,
just want to point out that the mathematics of what you want to do is
conceptually really simple - see
http://en.wikipedia.org/wiki/Weighted_arithmetic_mean#Dealing_with_variance .
Programs like aimless or others (e.g. xdsconv could also be used) just
implement the two formulas (that you see in Wikipedia) to get the weighted mean
intensity, and its standard deviation.
I'm saying this to try and avoid the impression to readers of CCP4BB that what
you want to do requires some highly sophisticated program. The trickery you
mention (having to do with adjacency of reflections, and such) only has to do
with the fact that e.g. aimless is not usually used in the way that you want.
So you could just write a short program in the programming language of your
choice, and be done with it.
best,
Kay
On Tue, 10 Jun 2014 13:18:53 -0400, wtempel wtem...@gmail.com wrote:
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
Re: [ccp4bb] merging of reflection with identical indices
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Wolfram,
does it work if you feed the hkl-file as SHELX file into pointless and
then use aimless ONLYMERGE? An hkl-file is just plain ascii, and as
far as I know there is no restriction on duplicate hkl-entries. You
may need to reprint the list in FORMAT(3I4,2F8.2).
Best,
Tim
On 06/10/2014 07:18 PM, wtempel wrote:
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
- --
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
GPG Key ID = A46BEE1A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iD8DBQFTmCIuUxlJ7aRr7hoRAiZnAKD3jZ5jWo2WWSj6s9RoF2BX/8F/xQCguqaL
dr1dXSAB4yrE1W+DP60+2oU=
=T/Vk
-END PGP SIGNATURE-
[ccp4bb] merging of reflection with identical indices
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
Re: [ccp4bb] merging of reflection with identical indices
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
Re: [ccp4bb] merging of reflection with identical indices
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
