I did some tests of s/r MSYMLB3 and the problem seems to lie there, or
at least its behaviour is inconsistent with the documentation, so it may
be a generic problem rather than specifically a problem with
mtz2various.
I just read in the space-group number and name, call MSYMLB3 and print
what comes back. Now according to $CDOC/symlib.doc:
1. The routine will try first to match the assigned NAMSPG_CIF to
ANY
name given on the spacegroup line:
It is satisfied by the first fit it finds:
eg: 47 8 8 Pmmm PGmmm ORTHORHOMBIC 'P 2/m 2/m 2/m' 'P m m m'
You could call the subroutine with NAMSPG_CIF = 'Pmmm' or 'P 2/m
2/m 2/m' or 'P m m m'
But it will always return the LONGEST possible name. ie 'P 2/m
2/m
2/m'
2. If there is no match to the spacegroup NAME, the space group is
identified by its number. This requires that the number is
UNIQUE,
so alternate settings are numbered n000 + Int Tab number.
i.e. the name (if valid) is supposed to take precedence over the number.
Here's what happens:
SG number: 5
SG name : I2
SG number/name: 5 'C 1 2 1'
SG number: 5
SG name : I 2
SG number/name: 5 'C 1 2 1'
SG number: 5
SG name : I 1 2 1
SG number/name: 5 'C 1 2 1'
SG number: 0
SG name : I2
SG number/name: 4005 'I 1 2 1'
SG number: 0
SG name : C2
SG number/name: 5 'C 1 2 1'
SG number: 4005
SG name : C2
SG number/name: 4005 'I 1 2 1'
SG number: 4005
SG name : I2
SG number/name: 4005 'I 1 2 1'
So in fact the number (if valid) always takes precedence, despite what
the documentation claims. This is what happens in mtz2various, i.e. SG
number = 5 read from header and translated to 'C 1 2 1', and SG name in
header = 'I 1 2 1' is ignored.
Cheers
-- Ian
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
On
> Behalf Of Ian Tickle
> Sent: 11 June 2009 17:28
> To: Kevin Cowtan
> Cc: [email protected]; [email protected]; Phil Evans;
George M.
> Sheldrick
> Subject: RE: [ccp4bb] mtz2various is broken [ was: Another pointless
> question ]
>
> mtz2various seems to get the symm info correctly from the header using
> LRSYMI but then it calls MSYMLB3 using the SG number '5' (and the
> correct name 'I121') which will cause the SG name and the symm ops to
be
> overwritten with the wrong ones (i.e. those for 'C2'). Again the
> problem here is that the number is taking precedence over the name.
> That's the way it has been done historically and it always worked
> before, because there has always been a 1-to-1 correspondence between
> the number and symm ops (via symop.lib or syminfo.lib), and that has
now
> been broken. If we're now doing it differently, i.e. the symm ops
> taking precedence where there's a conflict, then someone must take
> responsibility to ensure that all programs are updated to use the new
> convention. I've no idea whether the problem is only in mtz2various
or
> whether others are affected. From what Ethan said it sounds like some
> programs (e.g. Refmac) have been updated.
>
> It seems to me the easiest way to fix this is to ensure that the symm
> info in the header is all consistent with syminfo.lib, which in this
> case means ensuring that the SG number in the header is the
traditional
> CCP4 one, i.e. 4005 for I2. If most programs ignore this anyway as
you
> say then obviously it can't affect them. It just means that programs
> writing a CIF file need to write the number mod 1000, but this is
> trivial.
>
> Just got George's response: I agree that using the symm ops is the
only
> safe way in the long term, but in the meantime we have to deal with
the
> fact that some programs are still using the numbers (or names).
>
> Cheers
>
> -- Ian
>
> > -----Original Message-----
> > From: [email protected]
[mailto:[email protected]]
> On
> > Behalf Of Kevin Cowtan
> > Sent: 11 June 2009 16:56
> > To: [email protected]
> > Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless
> > question ]
> >
> > 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:[email protected]]
> > >>> Sent: 11 June 2009 00:35
> > >>> To: Ian Tickle
> > >>> Cc: [email protected]; 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 [email protected] 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
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
[email protected] 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
