There are no 'new' conventions to keep up with: recent editions of the old volume 1 or new A do not disagree on the question of the unit cell conventions (except for minor details which don't affect the majority of the common space groups), where by "recent" I mean "going back ~ 70 years". So it's certainly not the case that the conventions are changing every year (that would be silly!) - they have been defined exactly once in the last 100 years! I believe the unit cell conventions currently in use were actually first defined by the 1952 edition of International Tables, so both the 1969 edition (volume '1') and the 1983 edition (1st of volume 'A') will certainly describe them. I have only the 2002 edition (the 5th) so I can't tell you exactly where to find the relevant info in the older editions. The very first edition of IT (1935 I believe) did not define the unit cell conventions, only the space groups, so I wouldn't recommend that!
The older editions did not include information on alternate space-group settings simply in order to save paper: the 1952 edition was published in the years following WW2 when there was a paper shortage, so this was an important consideration! Only one setting (the 'standard setting') of each space group, chosen arbitrarily, was described and the crystallographer was expected to permute it to get the desired setting. If you need to see all the alternate settings laid out explicitly then you need to get hold of a recent (e.g. the 5th printed or 1st online) edition; failing that you have to work them out yourself! I thought the alternate settings were first described (though possibly without the diagrams) in the 1st (1983) edition of volume A, but I'm relying on memory and could well be wrong. The setting was often chosen to be consistent with a pre-existing isomorphous structure (i.e. generally isomorphism overrides convention); if there was none either the setting was defined by the unit cell convention, or often it was simply easiest to use the standard setting. Of course not everyone followed the conventions: it was common to write programs that could handle only the standard settings (and it still is!). Wiser programmers allowed space-groups to be defined arbitrarily by the equivalent positions instead of the number or symbol, so then it was straightforward to select any desired alternate setting. Note that the convention describes the unit cells, from which the space-group symbols are then derived, not the other way around. The ratiionale behind this is simple: there was a time not so long ago (which I remember!) when data collection and structure solution for even routine structures was actually non-trivial (I'm not implying that it's always trivial even nowadays!). However it was possible relatively straightforwardly to obtain the unit cell from precession photos (i.e. the indexing). It used to be common practice to publish an initial communication giving the unit cell and possibly a tentative space group; this would be followed up (often several years later!) by structures determined to successively higher resolution as more data was collected. Of course it was not possible to be 100% certain of the space-group assignment from the precession photos (and for several space-groups there is of course no unique space-group determinable from the systematic absences alone); final space-group assignment often had to wait several years for the structure determination. Hence it made sense to define the setting from the unit cell, not the space group. I recommend the 2 papers from the US National Institute of Standards & Technology (see Phil's posting) for more on this: the NIST conventions are the same as the IUCr ones, i.e. based on the unit cell (in fact Alan Mighell when he was at NIST wrote much of unit-cell convention material in IT). -- Ian On Thu, Mar 31, 2011 at 7:36 PM, Santarsiero, Bernard D. <[email protected]> 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 >> > > > >
