Then it's clear what the problem is: whichever program created your file put the wrong space group number in (or copied it from an input file). For I2 it must be '4005' not '5', no question. This is the number found in the $CLIBD/syminfo.lib entry under 'symbol ccp4':
begin_spacegroup number 5 basisop x,y,-x+z symbol ccp4 4005 symbol Hall ' C 2y (x,y,-x+z)' symbol xHM 'I 1 2 1' symbol old 'I 1 2 1' 'I 2' symbol laue '-P 2y' '2/m' symbol patt '-I 2y' '2/m' symbol pgrp ' P 2y' '2' hklasu ccp4 'k>=0 and (l>0 or (l=0 and h>=0))' mapasu ccp4 0<=x<-1; 0<=y<-1; 0<=z<-1 mapasu zero 0<=x<=1/2; 0<=y<1/2; 0<=z<1 mapasu nonz 0<=x<=1/2; 0<=y<1/2; 0<=z<1 cheshire 0<=x<=1/2; 0<=y<=0; 0<=z<=1/2 symop x,y,z symop -x,y,-z cenop x,y,z cenop x+1/2,y+1/2,z+1/2 end_spacegroup so it's clearly a programming bug. CCP4 requires that I2 be numbered 4005 to distinguish it from C2 otherwise the confusion you observed will ensue! This is because in the CCP4 library calls the number takes precedence over the name, since space-group names used by CCP4 have historically tended to vary according to whether or not apostrophes, spaces and/or additional '1's are present!, but the number has remained unique. However CIF files should observe the ITC(A) numbering/naming convention, shown under 'number' and 'symbol xHM' in syminfo.lib, because in ITC(A) the name takes precedence over the number. So there the number should be converted to '5', and of course in PDB files only the ITC(A) name is used. Cheers -- Ian > -----Original Message----- > From: Ethan Merritt [mailto:[email protected]] > Sent: 11 June 2009 16:21 > To: Ian Tickle > Cc: [email protected]; Phil Evans > Subject: Re: mtz2various is broken [ was: Another pointless question ] > > 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 > > > > > > > > Your version fails to convert space group "4005" to "5". > > > > True, but at least it gets the space group name and the symmetry > > operators right! I think the conversion from '4005' to '5' in your case > > is not intentional! > > > > Cheers > > > > -- Ian > > > > > > > > I am running 6.1.1 built from the source tarball. > > > This version does convert "4005" to "5", but then it makes the > > > mistake in subroutine wcifhr(mtzin,iun,dbhead) of calling > > > C--- Change short H-M symbol to full CIF-style symbol: > > > call MSYMLB3(24,nspgrx,spgrnx_cif,spgrnx_cifs,pgnamx, > > > & nsympx,nsym,rsym) > > > > > > which looks up the space group name and symops based on the converted > > > number. > > > Having done that, it now thinks the space group is C2, even though > > > the cell parameters and reflection indices are not correct for that > > > setting. > > > > > > So both versions are broken, but in different ways. > > > > > > I have not been able to track down which routine in which source file > > > was changed. But since I see the same problem in 6.0.2, I'm not sure > > > there > > > _is_ a difference in the source files I have on hand. Is it possible > > that > > > this was partially fixed for 6.1.0 but then reverted because of the > > > problem you > > > report, leaving it broken again? > > > > > > Ethan > > > > > > > > > > First an extract from the mtz2various log file: > > > > > > > > * Cell Dimensions : (obsolete - refer to dataset cell dimensions > > above) > > > > > > > > 70.3025 68.7834 93.7125 90.0000 94.1913 90.0000 > > > > > > > > * Resolution Range : > > > > > > > > 0.00030 0.24999 ( 58.124 - 2.000 A ) > > > > > > > > * Sort Order : > > > > > > > > 1 2 3 0 0 > > > > > > > > * Space group = 'I2' (number 4005) > > > > > > > > > > > > Then the CIF output: > > > > > > > > ########## > > > > # # > > > > # CELL # > > > > # # > > > > ########## > > > > > > > > > > > > _cell.entry_id junk > > > > _cell.length_a 70.3025 > > > > _cell.length_b 68.7834 > > > > _cell.length_c 93.7125 > > > > _cell.angle_alpha 90.0000 > > > > _cell.angle_beta 94.1913 > > > > _cell.angle_gamma 90.0000 > > > > > > > > > > > > ############## > > > > # # > > > > # SYMMETRY # > > > > # # > > > > ############## > > > > > > > > > > > > _symmetry.entry_id junk > > > > _symmetry.Int_Tables_number 4005 > > > > _symmetry.space_group_name_H-M 'I 1 2 1' > > > > > > > > > > > > #################### > > > > # # > > > > # SYMMETRY_EQUIV # > > > > # # > > > > #################### > > > > > > > > > > > > loop_ > > > > _symmetry_equiv.id > > > > _symmetry_equiv.pos_as_xyz > > > > 1 'X, Y, Z' > > > > 2 '-X, Y, -Z' > > > > 3 'X+1/2, Y+1/2, Z+1/2' > > > > 4 '-X+1/2, Y+1/2, -Z+1/2' > > > > > > > > The only thing I see is different is that your space group is shown > > as > > > > 'I121' whereas mine is just 'I2' > > > > > > > > Hope this helps! > > > > > > > > Cheers > > > > > > > > -- Ian > > > > > > > > > -----Original Message----- > > > > > From: [email protected] > > [mailto:[email protected]] > > > > On > > > > > Behalf Of Ethan Merritt > > > > > Sent: 08 June 2009 21:56 > > > > > To: [email protected]; Phil Evans > > > > > Subject: mtz2various is broken [ was: Another pointless question ] > > > > > > > > > > On Friday 08 May 2009 10:36:28 Phil Evans wrote: > > > > > > I2 is always an alternative setting to C2, & Pointless (by > > default) > > > > > > will choose this (since 1.2.12 I think) if it gives a smaller > > beta > > > > > > angle than the C2 setting > > > > > > > > > > > > I am assured that this is the IUCr approved "standard", along > > with > > > > > > always setting primitive orthorhombic space groups with a < b < > > c > > > > even > > > > > > if this makes eg space group 18 P 2 21 21. However, there are > > some > > > > > > "old-fashioned" programs :-) which don't like this (arp/warp at > > > > > > present for example, though I believe this will change in > > future), > > > > so > > > > > > Pointless does offer the option SETTING SYMMETRY-BASED, also an > > > > option > > > > > > in the ccp4i GUI, to choose the "reference" setting and C2 > > > > > > > > > > A follow-up to this discussion. > > > > > > > > > > I finished refinement, and I am ready to deposit with the PDB. > > > > > However, when I went to produce a *.cif file for deposition, I > > found > > > > > that mtz2various is confused by the I2 setting. It kept the cell > > > > > edges and angles from I2, but created a *.cif output file that > > claims > > > > > the cell is C2 and it lists the symmetry operators for C2. > > > > > > > > > > I manually corrected the header records in the *.cif file, but the > > > > > program itself should be fixed as well. > > > > > > > > > > I ran: > > > > > > > > > > ### CCP4 6.1: MTZ2VARIOUS version 6.1 : 12/11/08## > > > > > > > > > > The mtz2various log file contains the line: > > > > > > > > > > * Space group = 'I121' (number 5) > > > > > > > > > > By contrast, running mtzdmp on the input file it is converting > > reports > > > > > > > > > > * Space group = 'I 1 2 1' (number 4005) > > > > > > > > > > > > > > > cheers, > > > > > > > > > > Ethan > > > > > > > > > > > > > > > > Keeping the obliquity of the cell small has some advantages: it > > may > > > > > > make map viewing easier, and improve the accuracy of map > > > > interpolation > > > > > > in programs which are a bit casual about doing this properly > > > > > > > > > > > > Phil > > > > > > > > > > > > > > > > > > On 8 May 2009, at 17:45, Ethan Merritt wrote: > > > > > > > > > > > > > I was very surprised recently when a run of pointless chose to > > > > > > > transform my data into spacegroup I2 [*]. Here are excerpts > > from > > > > the > > > > > > > output log: > > > > > > > > > > > > > > %%%%%%%%%%%% > > > > > > > Selecting space group I 1 2 1 as there is a single space group > > > > with > > > > > > > the highest score > > > > > > > Space group confidence (= Sqrt(Score * (Score - > > NextBestScore))) > > > > > > > = 0.37 > > > > > > > %%%%%%%%%%%% > > > > > > > The input crystal system is C-centred monoclinic > > > > > > > (Cell: 291.8 98.38 148.6 90 120.3 90) > > > > > > > The crystal system chosen for output is body-centred > > monoclinic > > > > > > > (Cell: 148.6 98.38 252 90 90.33 90) > > > > > > > %%%%%%%%%%%% > > > > > > > > > > > > > > Notice that the log file output doesn't say, for instance, > > > > > > > "you might want to consider the non-standard setting I2". > > > > > > > It says "there is a single space group with the highest > > score", > > > > > > > and proceeds to convert away from the standard setting C2. > > > > > > > > > > > > > > I am not complaining, as in fact this solved a bit of a > > mystery > > > > for > > > > > > > me. > > > > > > > The diffraction images had originally been indexed as I222. > > > > > > > Integration > > > > > > > proceeded without a hitch, but the data failed miserably to > > scale > > > > > > > acceptably. > > > > > > > Running pointless immediately made clear what the problem had > > > > been. > > > > > > > > > > > > > > Instead I am merely curious. > > > > > > > What are the criteria that pointless uses to decide such a > > thing? > > > > > > > In this case the beta angle is _very_ near to 90. I have fed > > > > other > > > > > > > C2 data sets to pointless and not seen even a mention of I2 in > > the > > > > > > > output. Is the "score" mentioned in the log file some > > weighted > > > > > > > function that > > > > > > > says the closer beta approaches 90 after re-indexing, the > > more > > > > that > > > > > > > re-indexing is preferred? > > > > > > > > > > > > > > Ethan > > > > > > > > > > > > > > > > > > > > > [*] Not least because I had never previously encountered "I2" > > as > > > > the > > > > > > > name of a spacegroup. Live and learn. > > > > > > > > > > > > > > > -- > > > > > Ethan A Merritt > > > > > Biomolecular Structure Center > > > > > University of Washington, Seattle 98195-7742 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
