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