Surely Refmac or any other program should honour the symmetry operators in the MTZ file - that's why they are there!
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 > > >
