 |
 |
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: [log in to unmask] * * 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: [log in to unmask] > > [mailto:[log in to unmask]] On Behalf Of Manfred S. Weiss > > Sent: 21 January 2008 09:34 > > To: Winter, G (Graeme) > > Cc: [log in to unmask] > > 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: [log in to unmask] * > > * 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 [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 >