Using the symmetry operators as the definitive source of space group information, rather than the name or number of the space group, is the only completely safe approach, and I am pleased to see that CCP4 now does this. SHELX has worked this way since 1970, though in a moment of weakness I allowed the space group name to be input to shelxc.
George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Thu, 11 Jun 2009, Kevin Cowtan wrote: > Not sure if this is relevant, but all clipper programs (and I think all > programs wince 6.0) take the symmetry operators as the source for the > spacegroup rather than the spacegroup symbol. > > So I would expect changing the spacegroup number or symbol would not affect > most programs in any way. > > It is possible of course that there is a way to access the file symbol or > number, in which case there may be a few programs which might be able to get > the wrong spacegroup from an inconsistent file. > > > Ethan Merritt wrote: > > On Thursday 11 June 2009, Ian Tickle wrote: > > > > -----Original Message----- > > > > From: Ethan Merritt [mailto:merr...@u.washington.edu] > > > > Sent: 11 June 2009 00:35 > > > > To: Ian Tickle > > > > Cc: CCP4BB@jiscmail.ac.uk; Phil Evans > > > > Subject: Re: mtz2various is broken [ was: Another pointless question ] > > > > > > > > On Tuesday 09 June 2009 02:45:41 Ian Tickle wrote: > > > > > Ethan - that's odd it works for me (CCP4 6.1.0) unless of course it > > > got > > > > > broken recently in 6.1.1: > > > > I see the same problem in both 6.0.2 and 6.1.1. > > > > I don't have a copy of 6.1.0 around to test. > > > I just compiled 6.1.1 mtz2various.f with 6.1.1 CCP4 libs & I get > > > identical results (i.e. log & CIF files) with 6.1.0. Differences > > > between the source versions are minor (related only to CIF line length). > > > Also there are minor formatting differences betweeen 6.0.2 & 6.1.x, but > > > symmetry info is identical. So it's not a version issue, but must be > > > what's in the MTZ file header. Have you looked at the file header, does > > > it contain the right symmetry operators? Most programs including > > > mtzdump don't bother to print these out but blithely assume that they > > > are consistent: the mtztona4 program writes out the complete file header > > > in ascii, or you can just open the MTZ file in a text editor (as long as > > > it doesn't mind the non-ascii characters and the long lines!). Here's > > > the relevant bit of mine: > > > > > > CELL 70.3025 68.7834 93.7125 90.0000 94.1913 90.0000 > > > SORT 1 2 3 0 0 > > > SYMINF 4 2 I 4005 'I2 ' PG2 > > > SYMM X, Y, Z > > > SYMM -X, Y, -Z > > > SYMM X+1/2, Y+1/2, Z+1/2 > > > SYMM -X+1/2, Y+1/2, -Z+1/2 > > > END > > > > > > If I change 'I2' to 'I121' to look like yours I still get the same > > > results, so that's not the problem. > > > > My mtz file contains > > CELL 148.6099 98.3798 251.9687 90.0000 90.3258 90.0000 > > SORT 1 2 3 0 0 > > SYMINF 4 2 I 5 'I121' PG2 > > SYMM X, Y, Z > > SYMM -X, Y, -Z > > SYMM X+1/2, Y+1/2, Z+1/2 > > SYMM -X+1/2, Y+1/2, -Z+1/2 > > RESO 0.0000607290094194 0.1371708661317825 > > > > So there is a difference, but not the expected one. My mtz file has exactly > > the info that should go into the cif headers, > > including the space group number of the standard setting: 5. > > But mtzdmp and refmac, etc, do manage to find and report the spacegroup > > as 4005 from this same file. Could there be two conflicting spacegroup > > numbers stored in the header? > > > > For what it's worth. I see the same behavior on files created by > > pointless (re-indexed from C2), files created directly by > > mosflm/scala/truncate, and files merged by CAD. > > > > Ethan > >
