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 [EMAIL PROTECTED]:
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor Lamzin
Sent: 10 June 2008 16:45
To: PhilEvans
Cc: CCP4BB@JISCMAIL.AC.UK
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 [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
