Thanks Ian - you have spotted the problem!
I believe the Clipper routines must write out as a number the info
flagged in the syminfo.lib as
number 5 for example ( Spacegroup I 1 2 1)
and not the info flagged as:
symbol ccp4 4005
There are multiple space groups listed with the same number - eg P2 1 1,
P 1 2 1 and P 1 1 2 all are flagged
number 3 so it is useless as a flag.
If Clipper could be changed to use the
symbol ccp4 4005 information when it is available we would not have
problems with backward compatibility
The hierachy for assigning symmetry should I think:
Symmetry operators if you have them: most applications need this and
any name is just a flag to set up the smmetry matrices..
Space group name if it is properly given as in the PDB file eg P 1
2 1 or I 1 21 1 which can be matched via syminfo.lib to the operators.
But many programs still have the option to read in an old fashioned
flag such as the "symbol ccp4" number or a short spacegroup name (eg
P21) and use that to extract symmetry operator information, so I think
we should continue to match these old style names flags to symmetry
operators if there is a match to nbe found.
I believe this is the procedure followed in msymlb3
Can ctruncate at least be changed to use the ccp4symbol when it is
available?
Eleanor
Ian Tickle wrote:
Hi Martyn
Since seeing Ethan's last posting I guessed immediately, following on
from what Kevin had said earlier, that the program in Ethan's sequence
which made the change from SG #4005 to #5 in the MTZ header (and my
tests confirm this) is ctruncate; this behaviour presumably is a feature
of the Clipper library, so I guess is common to all programs using
Clipper (though pointless appears to be an exception - presumably
because it specifically creates the 4005 code rather than simply
transferring it from input to output). All the other programs in his
sequence copy the SG #4005 unchanged.
So essentially the problem is an incompatibility between the old
(c)symlib and the Clipper library; the former still uses the old
conventions that 1) the SG number uniquely identifies alternative
settings corresponding to a given standard setting, and 2) the SG number
takes precedence over the SG name and/or symm ops to determine the space
group, whereas the latter doesn't use unique numbers to identify
alternative settings, and assumes the reverse precedence.
You suggest changing MSYMLB3 to fix this, i.e. essentially changing it
to conform to the symlib documentation (!), so that the SG name takes
precedence over the number - I agree this ought to work. The only issue
I see is that many programs (e.g. see several examples of this usage in
SFALL documentation) allow user input of either the SG name or number,
e.g. in SFALL, PDBSET etc:
SYMM I2
and
SYMM 4005
are equivalent. If we are going to move to the new Clipper-style
convention I wonder how this would be handled, if the SG numbers no
longer uniquely identify the setting. I guess we would lose this rather
useful (IMO at least) feature! I assume you would at least continue to
allow use of CCP4-style SG numbers via MSYMLB3 - all our internal
scripts rely on this feature.
Cheers
-- Ian
-----Original Message-----
From: owner-ccp...@jiscmail.ac.uk [mailto:owner-ccp...@jiscmail.ac.uk]
On
Behalf Of Martyn Winn
Sent: 12 June 2009 20:46
To: Ethan Merritt
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless
question ]
Apologies, have been away. I hope I have extracted the relevant points
from this thread.
For the record, the CCP4 library also uses the symops to determine the
spacegroup, when it can. Hence the observation below that mtzdmp and
refmac find the right spacegroup.
However there are plenty of cases where the symops are not available,
PDB files with CRYST1 card only, user keywords, etc. And there is
plenty
of independently developed application code which may not follow the
library (bearing in mind that we are an anarcho-syndicalist commune
etc
etc).
Ian is right that the surest way of checking the MTZ file is to open
in
a text editor. You can also edit the SYMINF line this way, though this
is probably classed as advanced ccp4 usage... So in my tests
SYMINF 4 2 I 4005 'I 1 2 1' PG2
works fine, while
SYMINF 4 2 I 5 'I 1 2 1' PG2
shows the problem. And yes, the problem is then MSYMLB3 using the 5
rather than the spacegroup name or the operators. We should be able to
fix that.
4005 is for internal usage, converting to 5 on export from the suite.
Probably the generating program should have used 4005.
Cheers
Martyn
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
--
***********************************************************************
*
*
* Dr. Martyn Winn
*
*
*
* STFC Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, U.K.
*
* Tel: +44 1925 603455 E-mail: martyn.w...@stfc.ac.uk
*
* Fax: +44 1925 603825 Skype name: martyn.winn
*
* URL: http://www.ccp4.ac.uk/martyn/
*
***********************************************************************
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 i.tic...@astex-therapeutics.com 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
