On 2 October 2014 13:51, Kay Diederichs <[email protected]> wrote:
> > I don't see any "sticking to initial indexing" as worthwhile to worry > about, since in the first integration, P1 is often used anyway, and it is > quite normal (and easy) to re-index after the intensities become available, > during scaling. Re-indexing from P1 to the true spacegroup often changes > the cell parameters and their order, and this is sufficiently easy and > well-documented in the output. > Far from it: re-indexing would be a huge problem for us and one we wish to avoid at all costs. We had a case where the systematic absences were ambiguous (not uncommon!) and for a long time it wasn't clear which of two SGs (P21212 or P212121) it was. So we simply kept our options open and assigned the SG in XDS as P222 in all cases. This of course meant that the cell was automatically assigned with a<b<c. We have a LIMS system with an Oracle database which keeps track of all processing (including all the failed jobs!) and it was a fundamental design feature that all crystals of the same crystal form (i.e. same space group & similar cell) were indexed the same way relative to a reference dataset (the REFINDEX program ensures this, by calculating the correlation coefficient of the intensities for all possible indexings). So crystals may be initially re-indexed from the processed SG (where for example 2 axes have similar lengths) to conform with the reference dataset (in P222), but then once they are in the database there's no way of storing a re-re-indexed dataset based on a different space group assignment without disruption of all previous processing. We collected datasets from about 50 crystals over a 6 month period and stored the data in the database as we went along before we had one which gave a Phaser solution (having tried all 8 SG possibilities of course), and that resolved the SG ambiguity without reference to systematic absences (it was P212121). But there was no way we were going to go back and re-index everything (for what purpose in any case?), since it would require deleting all the data from the database, re-running all the processing and losing all the logging & tracing info of the original processing. However changing the space group in the MTZ header from P222 to P212121 without changing the cell is of course trivial. I don't see how "symmetry trumps geometry" can be a universal rule. How can it be if you're not even sure what the correct space group is? Also the IUCr convention in say monoclinic space groups requires that for a and c the "two shortest non-coplanar axis lengths be chosen" which is the same as saying that beta should be as close a possible to 90 (but by convention > 90). This is an eminently sensible and practical convention! So in one case a C2 cell with beta = 132 transforms to I2 with beta = 93. It is important to do this because several programs analyse the anisotropy in directions around the reciprocal axes and if the axes are only 48 deg apart you could easily miss significant anisotropy in the directions perpendicular to the reciprocal axes (i.e. parallel to the real axes). So at least in this case it is essential that "geometry trumps symmetry". > > this is true; running in all 8 possible primitive orthorhombic space > groups is a fallback that should save the user, and I don't know why it > didn't work out in that specific case. Still, personally I find it much > cleaner to use the space group number and space group symbol from ITC > together with the proper ordering of cell parameters. I rather like to > think once about the proper ordering, than to artificially impose a<b<c , > and additionally having to specify which is the pure rotation (in 18) or > the screw (in 17). And having to specify one out of 1017 / 2017 / 1018/ > 2018/ 3018 is super-ugly because a) there is no way I could remember which > is which, b) they are not in the ITC, c) XDS and maybe other programs do > not understand them. > I completely agree that the CCP4 SG numbers are super-ugly: they are only there for internal programmer use and should not be made visible to the user (I'm sure there are lots of other super-ugly things hiding inside software!). Please use the H-M symbols: a) they're trivial to remember, b) they are part of the official ITC convention, c) they're designed to be unique (even without embedded spaces!), and d) all programs that use the CCP4 symmetry library (also Global Phasing & Phenix) recognise them. In any case XDS doesn't need to recognise any SG symbols with screw axes: they are totally irrelevant for integrating the images. If for example the user inputs the space group as P2122, P21212, P212121 my script will convert all screws to rotations so all of these become P222 for the purpose of running XDS. This of course doesn't affect XDS one iota, and I can change the MTZ header to the correct space group at my leisure (but definitely no re-indexing!). So I don't understand why the choice of P2122 vs P2221 etc is relevant as far as XDS is concerned: it just needs to know that the space group is P222. I can even tolerate C2 from XDS since where necessary it will get auto-re-indexed to I2 on first entry into the database (but never subsequently!). Cheers -- Ian
