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. <[log in to unmask]> 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
>>
>
>
>
>
|
