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 >
