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
|
