Hi Manfred There's a difference between the 'standard' and the 'conventional' settings of the Bravais lattices and of their corresponding space group symbols according to ITC Vol A. For most space groups (i.e. all except those with standard symbols C2, P21212 and P2221 for non-centrosymmetric space groups) they are of course the same. The standard symbol is always shown in the title line at the top left of the space group diagram page in Vol A, and the symbols for all the alternate settings are shown next to the individual space group diagrams. The standard symbol for the space group is the one you would use if you were classifying the space groups, e.g. if you were interested in the distribution of space groups you probably would not want to distinguish between P2122, P2212 and P2221 so you would use the standard symbol (which for each of these settings is P2221) to label them, i.e. the standard symbol doesn't distinguish between the possible settings. The 'standard setting' is however uniquely defined: it's the alternate setting whose symbol is the same as the standard symbol. The conventional settings for all the Bravais lattice types are defined in Table 9.3.4.1.
The advantage (and indeed the whole rationale) in using the conventional setting of the unit cell as opposed to the standard setting is that it is determined uniquely by the choice of Bravais lattice and cell parameters *only*, and doesn't require a knowledge of the orientation of screw axes and glide planes, and so can be defined once and for all when the data is indexed, even before systematic absences have been identified and interpreted. Assignment of the space group symbol of course has to wait until either the absences are unambiguously interpreted or the space group is unambiguously determined in some other way, e.g. heavy-atom or TF solution. So if the conventional setting is used, re-indexing is almost never required (except in the special case I mentioned). In contrast, assignment of the standard setting does in general require correct interpretion of systematic absences, which as we all know is not 100% reliable. So if the initial interpretation of systematic absences was omitted or was wrong, and you insist on having the data in the standard setting, then re-indexing may be required. Cheers -- Ian > -----Original Message----- > From: Manfred S. Weiss [mailto:[EMAIL PROTECTED] > Sent: 21 January 2008 11:13 > To: Ian Tickle > Cc: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] Spacegroup choices, reindexing and so on > > > Dear Ian, > > I thought that in cases of for instance P-orthorhombic where > you can have a screw axis along a, b, or c or any combination > of it, the standard is always to make the unique axis the > c-axis. I.e. the longest axis in P222, and P2(1)2(1)2(1), but > the 2(1)-axis in P222(1) or P2(1)22 or P22(1)2 and the 2-axis > in P22(1)2(1) or P2(1)22(1) or P2(1)2(1)2. I am not sure > if all programs (even within CCP4) understand any of the > non-conventional settings. > > Best regards, > > manfred. > > > ******************************************************************** > * * > * Dr. Manfred S. Weiss * > * * > * Team Leader * > * * > * EMBL Hamburg Outstation Fon: +49-40-89902-170 * > * c/o DESY, Notkestr. 85 Fax: +49-40-89902-149 * > * D-22603 Hamburg Email: [EMAIL PROTECTED] * > * GERMANY Web: www.embl-hamburg.de/~msweiss/ * > * * > ******************************************************************** > > > On Mon, 21 Jan 2008, Ian Tickle wrote: > > > > > Hi Manfred > > > > I agree with everything you say except the last bit about > re-indexing! > > For those space groups with alternate settings, e.g. those > with standard > > names C2 or P2221 or P21212, why is it necessary to re-index to the > > 'standard setting' when the data will have been already indexed > > correctly by Mosflm or whatever according to the ITC Vol A > convention > > (e.g. a < b < c for the oI lattice)? It's not clear to me > what you gain > > by re-indexing in that situation (presumably at the > heavy-atom solution > > or translation function stage), and I know from experience > that what you > > lose is the risk of causing endless confusion by having > datasets around > > indexed in both ways. > > > > This becomes particularly problematic when the data is > stored in some > > kind of database, because then you really want to have one > definitive > > space group name per crystal which is defined right at the > outset and > > cannot be changed. Changing the space group in mid-stream > is then not > > an option, except by deleting all the database entries for > that crystal > > and starting all over again with the new space group name. > Of course if > > the initial choice of space group was really wrong (e.g. the wrong > > Bravais lattice assignment) then you have no option but to > start over > > and re-process the data. > > > > The only other situation where re-indexing may be necessary > is where you > > know the correct Bravais lattice and approximate cell parameters > > *before* processing the data, e.g. where you have a > previously solved > > isomorphous or near-isomorphous structure, but where the alternate > > indexings have similar cell parameters so the initial > automatic choice > > of cell orientation may not have been correct. > > > > Cheers > > > > -- Ian > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Manfred S. Weiss > > > Sent: 21 January 2008 09:34 > > > To: Winter, G (Graeme) > > > Cc: CCP4BB@JISCMAIL.AC.UK > > > Subject: Re: [ccp4bb] Spacegroup choices, reindexing and so on > > > > > > Dear Graeme, > > > > > > here is what I would do, or what I would like to have. > > > > > > If you are able to identify the Laue group of the data with > > > some degree of certainty, then all of the processing and > > > scaling should be carried out in this Laue group. > > > > > > Then, by looking at systematic absences you may give probabilities > > > for each of the possible space groups, i.e. each of the eight > > > possibilities in P-orthorhombic. Typically one option will > > > have the highest probability and this is the one which should > > > be written out. In a second run, the user should be given the > > > choice of overriding this. > > > > > > Now, for space groups such as P222_1, this should always be > > > reindexed to standard setting, if it turns out to be the one > > > with the highest probability. > > > > > > Hope that helps, > > > > > > Manfred. > > > > > > > ******************************************************************** > > > * > * > > > * Dr. Manfred S. Weiss > * > > > * > * > > > * Team Leader > * > > > * > * > > > * EMBL Hamburg Outstation Fon: > +49-40-89902-170 * > > > * c/o DESY, Notkestr. 85 Fax: > +49-40-89902-149 * > > > * D-22603 Hamburg Email: > [EMAIL PROTECTED] * > > > * GERMANY Web: > www.embl-hamburg.de/~msweiss/ * > > > * > * > > > > ******************************************************************** > > > > > > > > > On Mon, 21 Jan 2008, Winter, G (Graeme) wrote: > > > > > > > Hi All, > > > > > > > > A user question about the xia2 behaviour has opened a pot > > > of worms, and > > > > I thought I would ask the community for opinions. If (for > > > example) you > > > > are using an automated data processing or analysis tool, and the > > > > systematic absences suggest a spacegroup choice, what would > > > you like to > > > > do: > > > > > > > > (1) nothing - just mention this in the output > > > > (2) assign the "base" version of this spacegroup (e.g. P41212 to > > > > represent that or it's enantiomorph) > > > > (3) create multiple copies of the reflection file with > all of the > > > > spacegroup options > > > > > > > > As a further question, if the spacegroup looks like P 2 > 21 21 (say) > > > > would you like this to be reindexed to the standard setting? > > > > > > > > Now, I suspect that there will be a wide range of > opinions on this. > > > > > > > > Following #1 will give possibly strange effects if > truncate tries to > > > > inflate systematically absent reflections > > > > Following #2 will result in reflections being removed > by truncate > > > > #3 gives lots of reflection files and lots of mess > > > > > > > > Currently I follow #2 with reindexing to the standard setting. > > > > > > > > There have been discussions in the past of being able > to flag "or > > > > enantiomorph" in the spacegroup definition in the mtz file. > > > This would > > > > be useful here, but would not really help with the reindex or no > > > > question... > > > > > > > > Thanks! > > > > > > > > Graeme > > > > > > > > > > > > > > > > > > > > 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
