 |
 |
I think this is only a problem in the primitive orthorhombic system (at least I assume people don't want hexagonal axes along a, A & B centred lattices etc, although there is no reason in principle why not). Following some earlier discussions with Ian, Pointless now honours (and preserves) a reference file (HKLREF) in eg P 2 21 21, and also explicit reindex operations, but an initial indexing will still enforce the "standard" setting eg P 21 21 2, because I accept the "reference" setting from the cctbx library ie suppose you have a crystal which when indexed with a <= b <= c and Pointless decides unambiguously for the sake of argument) that the axis along a is a 2-fold and the other two are 2(1) screws, ie space group P 2 21 21. At present this will be reindexed to the "standard" setting P 21 21 2, but is that what you want, or should it be left as a<b<c? Which criterion takes precedence? Phil On 19 Sep 2007, at 17:54, Ian Tickle wrote: > Hi Sue > > It's certainly true that the convention in the 1935 and 1952 > editions of > IT Volume 1 *appeared* to be the 'standard setting' convention that > you > describe because only the 'standard' settings were listed, and this > was > the way that many crystallographers interpreted it (actually only > macromolecular crystallographers, the small molecule people stick > to the > IUCr convention), so this is probably where you're coming from. > However > the 1983 edition of Volume A clarified the situation and made it clear > that this was never the intention, so all the conventional settings > are > now shown on the SG diagram pages. P22121 & P21221 certainly are > defined in IT Vol. A - look on the diagram page for SG no. 18 & you'll > see them. > > The 'standard symbol' for a space group is merely the heading on the > page used only for indexing purposes, so space groups P22121, > P21221 and > P21212 all have the same standard symbol P21212; hence the standard > symbol is not unique and can't be used to unambiguously define the > space > group. The 'standard setting' is merely the space group setting that > has the same name as the standard symbol. Even if that weren't > true do > we really want to be still sticking to a convention that was abandoned > 25 years ago and doesn't a later convention override an earlier one > anyway? > > Actually the convention in use is not the issue anyway, I don't care > which convention is used as long as all programs use the same > convention! - then I'll never need to permute axes (just as > fundamentally I don't care which co-ordinate format is used as long as > all programs use the same one, then I'll never need to reformat). So > Mosflm uses the IUCr convention (i.e. a<=b<=c for primitive > orthorhombic), and therefore any program which doesn't support that > convention for any space group forces you to permute the axes > completely > unnecessarily. > > -- Ian > >> -----Original Message----- >> From: Sue Roberts [mailto:[log in to unmask]] >> Sent: 19 September 2007 16:38 >> To: Ian Tickle >> Subject: Re: [ccp4bb] arp/warp in p22121 >> >> Hi Ian >> >> But there's an older convention, which is to use the space groups >> settings defined in the International Tables - and P22121 is not a >> standard setting. >> >> Sue >> >> >> On Sep 19, 2007, at 8:18 AM, Ian Tickle wrote: >> >>> I'm confused now, sticking to the IUCr convention should not >>> require any >>> axis permutation. My beef is specifically against unnecessary axis >>> permutations! Surely it's when the program doesn't support the >>> convention that you are forced to permute the axes? >>> >>> Besides I did solve a structure in P22121 with Phaser so >> I'm even more >>> confused! >>> >>> -- Ian >>> >>>> -----Original Message----- >>>> From: [log in to unmask] >>>> [mailto:[log in to unmask]] On Behalf Of Airlie McCoy >>>> Sent: 19 September 2007 15:09 >>>> To: [log in to unmask] >>>> Subject: Re: [ccp4bb] arp/warp in p22121 >>>> >>>>> The problem is specifically that ARP/wARP *doesn't* >> support the IUCr >>>>> convention as given in IT (Vol. A, >= 1983 edition, Table >>>> 9.3.4.1, p.758 >>>>> in 5th ed.) regarding choice of cell in primitive >> orthorhombic space >>>>> groups, and I suspect in centred monoclinic ones also. >>>> AFAIK ARP/wARP >>>>> and pointless are the only two CCP4 programs that currently >>>> don't fully >>>>> support the IUCr convention >>>> >>>> Phaser doesn't "support" the IUCr convention, and if it was >>>> used for the >>>> original MR in this case (I don't know whether it was or >>>> not), then it >>>> would have caused the "problem". We have had user requests to >>>> change the >>>> output to the IUCr convention, but other people get confused >>>> if the axes >>>> are permuted. So the choice will be made an output option - >>>> Frank von Delft >>>> suggested the keyword "IUCR [ON/OFF]"! Vote for your choice >>>> of default >>>> now... >>>> >>>> Airlie McCoy >>>> >>>> >>> >>> >>> 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 >>> >> >> Sue Roberts >> Biochemistry & Biophysics >> University of Arizona >> >> [log in to unmask] >> >> >> >> >> > > > 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