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
