Eleanor Clearly the space group name when given should always override the number, since whereas there is universal agreement on what the names should be (allowing for variants such as P21 and P1211 and +/- redundant spaces), there is no universal agreement on what the numbers should be (in fact the numbers mean completely different things, here one number refers to the standard setting and the other to the actual setting).
Cheers -- Ian On 23 May 2014 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 > > > >
