OK I guess Pointless is accepting the number as given in the reference file, 
rather than changing it.

If Pointless is just determining the space group it does give the "correct" 
(i.e. weird CCP4 convention) number

* Space group = 'P 2 21 21' (number     3018)

I'm not sure how to test this as I don't know how to make an mtz file with P 2 
21 21 /sgn 18, but I will look into it

Phil

On 23 May 2014, at 12:34, Eleanor Dodson <eleanor.dod...@york.ac.uk> wrote:

> 
>  Someone here has seen his Rfactors leap from 18% to 42% and was naturally 
> distressed! 
> We have tracked down the problem to this:
> 
> Steps he took were:
> 
> 1)  Integrate with XDS and feed output through pointless/aimless etc.
> He used a phenix refined mtz to "Match Laue and indexing" 
> 
> The space group there is given by PHENIX 
> as "P 2 21 21 " but the spacegroup NUMBER is given as 18 (ie P21 21 2 in CCP4 
> symmetry library) .
> 
> pointless then output an mtz file with SPACEGROUP number as 18 and SG name as 
> P 2 21 21.
> The symmetry operators are correctly listed for P 2 21 21
>  This is the version number: CCP4 6.4: POINTLESS              version 1.9.8 : 
> 02/05/14
> 
> 2) When the refinement was repeated with REFMAC  the spacegroup was taken as 
> P21 21 2 - ie the SG number 18 overrode the listed symmetry operators in the 
> mtz file, and the SG name P 2 21 21 given on the CRYST1 card was ignored.
> 
> The refmac version used is  CCP4 6.4: Refmac_5.8.0071     version 5.8.0071 : 
> 04/04/14
> 
> 
> The user thinks that in REFMAC 5.8.0033 this problem did not occur, but I 
> havent checked that..
> 
> 
> Anyway - it does emphasise the importance of checking symmetry operators for 
> consistency with both the SG name and number (Yes, George, I know you have 
> always said this is the only correct policy!) Maybe an extra subroutine could 
> be added to the symmetry library and called from other programs..
> 
> And ideally checking all sources of symmetry information for consistency and 
> stopping if there is a serious disagreement. 
> 
> 
> In the short term we simply took the processed mtz file and ran
> mtzutils hklin1 corrupted.mtz hklout fixed.mtz
> SYMM 3018   (or symm "P2 21 21" ) 
> and the fixed file was OK
> 
> Eleanor Dodson
> 
> 
> 

Reply via email to