I have the 2002 edition, and indeed it only contains space group numbers up to 230. The page numbers quoted by Ian contain space group numbers 17 and 18.
Although I am all for program authors building in support for the "screwy orthorhombics" (as I call them), I should admit that my fuddy-duddy strategy for dealing with them remains simply to use space groups 17 and 18, and permute the cell edges around with REINDEX to put the unique (screw or non-screw) axis on the "c" position. I have yet to encounter a program that gets broken when presented with data that doesn't have a<b<c, but there are many non-CCP4 programs out there that still don't seem to understand P22121, P21221, P2122 and P2212. This is not the only space group convention "issue" out there! The R3x vs H3x business continues to be annoying to this day! -James Holton MAD Scientist On Thu, Mar 31, 2011 at 11:36 AM, Santarsiero, Bernard D. <b...@uic.edu> wrote: > Interesting. My IT, both volume I and volume A (1983) only have P21212 for > space group #18. Do I have to purchase a new volume A every year to keep > up with the new conventions? > > Cheers, > > Bernie > > > On Thu, March 31, 2011 12:57 pm, Ian Tickle wrote: >>> I would like to share my experiencde with a rather unexpected problem of >>> indexing conventions. Perhaps I can save people some >>> time.... >> >>> I have a crystal in the more unusual P21212 space-group (No 18). Its >>> unit cell lengths are b>a>c (please note). I systematically >>> use XDS for data integration, since so far it was able to handle even >>> the most horrible-looking spots. >> >>> Now XDS indexed my data in space-group 18, but with the axes order >>> a<b<c! It had, in fact, "invented" a space-group P22121, >>> which does not exist. I did not realise this until I had spent a couple >>> of weeks with beautiful peaks in rotation functions, but >>> hopeless results in translation functions. It wasn't until I looked more >>> closely into the definition of the screw axes that I realised the >>> problem. >> >>> POINTLESS does not allow a reindexing of reflexions within the same >>> space-group, but fortunately REINDEX did the trick at the >>> level of intensities, because I like to use SCALA for careful scaling of >>> my data. >> >>>I was wo,dering if XDS could perhaps reindex reflexions according >>> to Int. Table conventions once the screw axes of a crystal system have >>> been >>> identified? >> >> The International Tables / IUCr / NIST convention _is_ a<=b<=c for >> orthorhombic so no re-indexing is necessary or desirable. See IT vol. >> A 5th ed. (2002), table 9.3.4.1 (p. 758 in my edition) for all the >> conventional cells. The problem may be that some programs are not >> sticking to the agreed convention - but then the obvious solution is >> to fix the program (or use a different one). Is the problem that XDS >> is indexing it correctly as P22121 but calling it SG #18 (i.e. instead >> of the correct #3018). That would certainly confuse all CCP4 programs >> which generally tend to use the space-group number first if it's >> available. >> >> I'm not clear what you mean when you say P22121 doesn't exist? It's >> clearly shown in my edition of IT (p. 202). Maybe your lab needs to >> invest in the most recent edition of IT? >> >> Cheers >> >> -- Ian >> >
