> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Victor Lamzin > Sent: 18 September 2007 12:48 > To: [EMAIL PROTECTED]; CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] arp/warp in p22121 > > Dear Florian, > > ARP/wARP supports 65 space groups where proteins crystallise and it > indeed uses the Hermann-Mauguin convention as given in the > International > Tables. The space group P22121 (number 3018 in the CCP4 symop.lib) is > not supported by ARP/wARP. The standard for it would be number 18, > P21212. The easiest is to re-index your data.
IMHO, gratuitous permutation of the cell axes in the data & co-ordinates is certainly not always an easy option since it's a real pain to have datasets around with different indexings: it causes endless confusion, particularly as in one case I had in P22121 where the a & b cell lengths were very close so it wasn't obvious just by looking at the files whether they had been re-indexed or not! 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 (though I suppose you could argue that ARP/wARP isn't technically a CCP4 program). It seems to me that the IUCr cell choice convention has a perfectly rational basis: the cell is chosen at the time the images are indexed solely on the basis of the assigned Bravais lattice symmetry, and provided that no problems with pseudo-symmetry are discovered later on it should never normally need to be changed thereafter. Systematic absences (not including absences due to centred lattices) have no influence on the choice of cell for the simple reason that they are not always reliable indicators of the true space group (particularly screw-axis absences). Assignment of the space-group symbol often does not occur until the heavy-atom Patterson or translation function solution stage, and I don't see the sense in being forced to permute the cell axes at that stage. It seems to me that a design goal of 'user-friendly' software should be to minimise the opportunity for the user to make obvious blunders which can waste a lot of time to sort out (even if it means making life a little more difficult for the programmer)! -- Ian 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
