I should say more clearly what I meant. The SHELX programs all use
the symmetry operators INTERNALLY as their definitive source for ALL
symmetry-derived information, whether in real space or reciprocal
space (e.g. in deciding which reflections are systematically absent). 
Of course the user very rarely actually puts them into the first .ins 
file by typing them in. In the small molecule field they are put there 
by GUIs such as XPREP (which can determine the space group automatically 
from the reflection data), WINGX, OLEX2 etc. For macromolecules they may 
indeed be generated from the space group name by SHELXC or SHELXPRO 
(which gets the name from a PDB file). In all these cases a large number 
of non-standard space groups (including "I2") are recognised. XPREP 
actually knows the symmtery operators for 413 space groups, i.e. the 230 
conventional settings and 183 non-standard settings! However a user who
is prepared to edit the operators in the .ins file is by no means 
restricted to only these 413 settings, as long as the operators are 
internally consistent the programs should work fine.

What I am advocating for the CCP4 world is that all programs that read
the mtz file should regard the symmetry operators stored in it, and not
the space group name or number that are also to be found there or 
maybe read from the instruction input file, as the definitive 
information about symmetry. Otherwise if some programs use the 
operators, some the name and some the number, chaos is inevitable and 
appears to be happening already. How many CCP4 programs know that 
space group number 4005 is actually "I2", or should it be "I 1 2 1"?!
At least Kevin's CLIPPER library is setting a good example.

George

PS. In a SHELX .ins file space group "I2" is defined by:

LATT -2
SYMM -X, Y, -Z

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, Ian Tickle wrote:

> In fact it's not quite true to say that the symm ops are used as the
> definitive source of space group information in all circumstances: where
> the SG info is read from some types of file (e.g. MTZ header), but by no
> means all (e.g. PDB files don't contain symm ops), then it appears that
> at least in some cases the symm ops take precedence.  However some
> programs don't read a file containing the symm ops and neither do they
> expect the user to supply the symm ops, because it's clearly much more
> convenient (and much less error-prone!) to ask the user to type in the
> SG number or name, and then do a look-up in syminfo.lib for the symm
> ops.  It seems to me that's entirely reasonable - what would you say if
> a program asked you to type in (interactively) the symm ops for a cubic
> space group!
> 
> Cheers
> 
> -- Ian
> 
> > -----Original Message-----
> > From: [log in to unmask] [mailto:[log in to unmask]]
> On
> > Behalf Of George M. Sheldrick
> > Sent: 11 June 2009 17:17
> > To: [log in to unmask]
> > Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless
> > question ]
> > 
> > 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:[log in to unmask]]
> > > > > > Sent: 11 June 2009 00:35
> > > > > > To: Ian Tickle
> > > > > > Cc: [log in to unmask]; 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
> > >
> > >
> 
> 
> 
> Disclaimer
> This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [log in to unmask] and destroy all copies of the message and any attached documents. 
> Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain.  Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
> Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
>