yes, actually my experience with P 21 2 21 dates back to midyear 2007.
Retesting
with the current refmac version runs fine.
Clemens
Quoting Ian Tickle <[log in to unmask]>:
>
> Victor
>
> 'P 21 2 21' *is* the conventional indexing if a <= b <= c, i.e. it's the
> setting agreed for deposition of crystal structures by the IUCr and the
> US National Institute of Standards & Technology (NIST) since 1983: it
> just doesn't seem to have been agreed by a dwindling number of
> individual program authors. AFAIK Arp/Warp is the only significant
> program relevant to PX which doesn't recognise the complete set of
> conventional settings (as defined in $CLIBD/syminfo.lib and symop.lib).
> In this case, the transformed setting 'P 21 21 2' (corresponding to the
> unconventional cell a <= c <= b) is called the 'standard' setting and is
> the reference symbol used for example as the title of the relevant page
> in ITC vol A, since for convenience the alternate settings 'P 2 21 21',
> 'P 21 2 21' and 'P 21 21 2' are all shown on the same page.
>
>> seems to be a 'non-standard' setting. Refmac also has
>> problems with this
>> spacegroup, reindexing to P21 21 2 fixed the problem for me.
>>
>> Clemens
>
> I've not had any trouble with this spacegroup when using a recent
> version of Refmac/CCP4: are you by any chance using an old version
> (either of Refmac or CCP4)? If not could you post the relevant error
> message so the problem can be identified & fixed, as it certainly ought
> to work.
>
> Re-indexing is usually not a viable option for us as it causes a lot of
> pain with our automated processing: if re-indexing really becomes
> unavoidable then it means we have to delete all the processed data for
> that crystal and other datasets of the same crystal form, then start all
> over again from data processing (i.e. from the MOSFLM/D*trek step), so
> that all datasets & co-ordinates associated with a project in the
> database are indexed the same way. Having datasets around with
> different indexings (particularly as happened once if 2 of the cell
> lengths are very similar) is a recipe for chaos! Anyone trying to
> automate structure solution would likely run into the same problem,
> unless of course they anticipated this eventuality in the database
> design.
>
> So yes, making all software accept the internationally recognised
> conventions could save us a lot of work!
>
> -- Ian
>
>> -----Original Message-----
>> From: [log in to unmask]
>> [mailto:[log in to unmask]] On Behalf Of Victor Lamzin
>> Sent: 10 June 2008 16:45
>> To: PhilEvans
>> Cc: [log in to unmask]
>> Subject: Re: [ccp4bb] Arp/warp space group P 21 2 21
>>
>> Dear Phil,
>>
>> One reason has been simplicity - many ARP/wARP modules operate with
>> space group number only. For space group 18 this would mean P21212.
>> Using space group name might be less robust - I remember some
>> compatibility problems when CCP4 introduced spaces into space group
>> names, this broke some of the parsers, including
>> simple-minded ones from
>> ARP/wARP.
>>
>> If there is, however, a strong wish for ARP/wARP to support
>> 'unconventionally' indexed space groups - then we will
>> certainly try to
>> introduce it.
>>
>> With best regards,
>> Victor
>>
>>
>>
>> PhilEvans wrote:
>> > Is there a reason why Arp/warp doesn't like space group P 21 2 21?
>> >
>> > Phil
>> >
>> >
>>
>>
>
>
> 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
>
>
|