Re: [ccp4bb]: F, E and U notation...

[Quan Hao <qh22@cornell.edu>]

***  For details on how to be removed from this list visit the  ***
***          CCP4 home page http://www.ccp4.ac.uk         ***

Kevin,

As far as I know, most direct-methods programs (MULTAN, RANTAN, SAPI,
OASIS) include the correction. If a space group is specified, all |E|
values must be corrected or it will cause serious problems in phasing
(it doesn't make sense to calculate E's if no space group is given
anyway). I am not sure if people want to use 'corrected' F. 

Quan Hao 

Kevin Cowtan wrote:
> 
> ***  For details on how to be removed from this list visit the  ***
> ***          CCP4 home page http://www.ccp4.ac.uk         ***
> 
> Here's a question of notation on which I'd like to canvas opinion.
> 
> Is there a standard for whether |E| and |U| include a reflection multiplicity
> correction (i.e. epsilon)?
> 
> Or is there a good, brief, naming convention to distinguish magnitudes which
> do or do not include this correction? Should there be?
> 
> I guess the confusion arises from the definition of |E| by <|E|>=1. If the
> average is taken over all reflections (absent of not), then to obey the
> relationship the mutliplicity term is not needed. However, if the average is
> taken over non-absent reflections only, the data obeys the relationship only
> if the correction is included.
> 
> Just leafing though the documents I have to hand, Randy's and Garib's papers
> tend to include the correction, maybe to make the equations simpler.
> International tables B:2.1 doesn't.
> 
> The reason this arises is because the some of the generic programming I am
> doing in Clipper to operate on a whole load of data at once will need to
> behave differently for data which either includes or does not include a
> multiplicity correction. In which case, they need to be different types.
> Potentially there are 6 types of data:
> F, E, U, corrected F, corrected E, corrected U
> but how many of these will be used in practice is another question. Currently
> I'm assuming that the same types will hold F's, E's or U's, but that could be
> changed at the cost of multiplying the number of data classes and instances.
> 
> Kevin
> 
> --
> Department of Chemistry, University of York, Heslington, York YO10 5DD