Re: [ccp4bb] arp/warp in p22121: what to do in Pointless

[Phil Evans]

OK I'll try to change the default behaviour, after I've fixed the  
current round of bugs!

Sometimes reindexing is required from the Mosflm indexing even  
without a reference set, if the Laue group assignment is wrong, or  
where there is pseudo lattice symmetry (eg we have a case which is  
really R3 but pseudo I-centred cubic, so Mosflm may choose the wrong  
3-fold in its indexing)

My POV was that on the first dataset, you don't care about the  
indexing, just about the space group, but this is undermined by the  
frequent uncertainty about systematic absences.

I think the best thing to do is to choose the reindexing for the Laue  
group (or point group), and not to switch it for different possible  
space groups within the Laue group. I think this should be able to  
pick up the I121 setting of C2 (though I might have to make that a  
special case: similarly George's P21/n v. P21/c)

Phil

On 24 Sep 2007, at 17:59, Ian Tickle wrote:


Phil,

It also affects centred monoclinic: to avoid some cases of beta > 120
you have to use the I121 setting instead of C121 (and it is a
conventional setting, see IT vol. A pp.126-7).  For example the
conventional (but non-standard) I121 setting: a=50 b=60 c=51 beta=90.2
would I think be re-indexed by pointless to the unconventional (but
standard) C121 setting: a=71.3 b=60 c=50 beta=134.3.

Trigonal, tetragonal & hexagonal settings with a or b unique are
definitely not only non-standard but also non-conventional: they  
violate
Table 9.3.4.1 in IT Vol. A and they don't appear in the diagrams, so
let's not go there!  The point about the IUCr convention is that the
cell is determined by the rules in Table 9.3.4.1 so you would never  
get
into that situation.  For the oP lattice the cell is determined  
once and
for all by the rules in exactly the same way: the systematic absences
are not taken into account because they are not always reliable,  
e.g. it
may be only after you've solved the TF that you can assign the SG
correctly, or at least beyond reasonable doubt, and re-indexing at  
that
point makes no sense.

To summarise my POV: I don't really care which convention you use,  
but I
think gratuitous re-indexing (i.e. without the user specifically  
asking
for it) is just very confusing, and this is what can happen if you  
stick
to the standard settings.  I'm all for educating users, and re- 
indexing
1 or 2 datasets can be very educational, but if you have lots of
datasets to deal with it's no longer amusing!  Sometimes re-indexing
*is* needed, e.g. because you already have isomorphous protein-ligand
structures and you want to be able to compare them easily, but this
should *only* be done to conform to a reference dataset.  I don't see
any point in re-indexing just to conform to the 'standard setting'
'non-convention' which is derived from a mis-reading of the 1952 ed of
IT (my guess is they didn't list all the conventional settings because
the publisher wanted to save money! - but at least they saw sense for
the 1983 ed.).

In any case this will only affect users of Arp/Warp, all other CCP4
programs (and most non-CCP4 programs, e.g. Shel-X, CNS etc) can handle
non-standard settings, and if you use Mosflm and always specify SG  
P222
for all oP cases (which I always do anyway), you would have to re- 
index
anyway.

-- Ian

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Phil Evans
Sent: 24 September 2007 16:58
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] arp/warp in p22121: what to do in Pointless

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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Airlie McCoy
Sent: 19 September 2007 15:09
To: CCP4BB@JISCMAIL.AC.UK
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 [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


Sue Roberts
Biochemistry & Biophysics
University of Arizona

[EMAIL PROTECTED]







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




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