HI Folks OK, so it seems that I have poked the proverbial hornet's nest with this one :o) has triggered some interesting discussions though.
Actually the thing which triggered this question was very simple and is Phil's Case #3 below - true symm = p212121 but "b" axis axial reflections not observed => resolved to lowest # spacegroup != P212121 => no longer isomorphous to similar crystals (at least, according to the unit cell, clearly in real life it is still isomorphous) Annoyingly the arguments from both sides i.e. the case above for resolving to a < b < c and the potential ambiguity if a ~ b are equally compelling, which means that the question remains unanswered. FWIW xia2 has been able to take reference data for most of a decade but this is rarely exercised... Thanks for all of the input, best wishes Graeme -----Original Message----- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Phil Evans Sent: 31 January 2016 22:45 To: ccp4bb Subject: Re: [ccp4bb] Spacegroups, screw axes and ordering Back to the original question I still fail to see the objection to space groups such as P 21 2 21 - these are consistent with international conventions and cause no real confusion We can consider a number of common scenarios following indexing of the dfifraction pattern and integration 1. Simple case: the indexing is correct, the Laue group is obvious and the axial systematic absences clearly indicate the space group. No problem, though you may still wish to test all the space groups in the Laue group. This may of course indicate that the space group is e.g. P 21 2 21, see point 3 2. The indexing is incorrect, but examination of the rotational symmetry (e.g. in Pointless) indicates the Laue group. Usually this gives a clear reindexing, and maybe the space group. 3. The Laue group is clear, but systematic absences are missing or unclear on e.g. one axis, often the case in primitive orthorhombic space groups. Pointless marks the data as “space group” P222 as a Laue group. This is then resolved by testing structure solutions in all possible space groups within the Laue group, e.g. the eight possible P2x2x2x primitive orthorhombics, which is easy in molecular replacement with Phaser, and is also necessary for experimental phasing (though it should be easier to do automatically). If the best solution comes up in say P21 2 21, that can go straight into refinement without further changes. If you insist on changing the space group to P 21 21 2, that means reindexing the data and the solution coordinates, which is likely to cause endless confusion, and is entirely unnecessary. 4. There are indexing ambiguities, or the true space group is known from earlier crystals. In these cases it is sensible to give a reference data set to specify the space group and to give consistent indexing. This has nothing to do with whether the space group is e.g. P 21 2 21 or P 21 21 2. In the new ccp4i2 GUI, a warning message such as the following is printed if alternative indexing is possible and no reference data are given NOTE: the final selected symmetry has alternative indexing schemes, but no reference data has been given Possible alternative indexing operators: [h,k,l], [-k,h,l] If you already have a matching dataset, you should choose it as a reference set to get consistent indexing Why is this a problem? Phil > On 30 Jan 2016, at 21:10, James Holton <jmhol...@lbl.gov> wrote: > > > One very good reason not to drop everything to P1 is because of Rfree. > > If you drop to P1, pick a "random" Rfree set, and then apply n-fold NCS (aka > the crystallographic symmetry), then every reflection in the "free" set has > at least one "NCS-mate" in the working set. Rwork and Rfree would then > always be close together (depending on the NCS weight), and by increasing the > overall X-ray weight you could get any Rfree you want, even if the structure > is totally wrong. > > It's surprising how many people have made the mistake of swapping CS for NCS. > Just search the PDB for structures in P21 with beta angle ~ 90. A few of > them are really P21, but not many. > > Yes, you could make your free-set picking algorithm smarter, but that > requires knowing what the symmetry is! "thin shells" are not always enough. > Especially if you process in P1 and cell edges or angles that should be > identical are allowed to drift. Where you can really get yourself into > trouble is with pseudo-symmetry, such as P222 with an NCS threefold along the > diagonal. Or is that P23? I myself only recently realized that C222 is > actually a subset of P622. Yes, you can solve any structure that > is really P622 in C222 and everything will work. Except Rfree with NCS, of > course. > > This has drifted a bit from the OP question, but perhaps the common thread > here is that there really is a need for better tools when it comes to choice > of symmetry. If you change your space group from H3 to R3, why is it not the > default to update the unit cell and re-index the hkls as well? Same for P312 > to C2, which is really just dropping one symmetry operator (although it is > not obvious from looking at the tables). > > I think the reason is that there will always be two camps when it comes to > automation: 1) people who want the sensible thing they always do manually to > be automatic, and 2) people who don't want default behaviors to change and > break their stuff, producing a lot of unintended consequences when all you > want to do is something simple. When writing automation software (like xia2) > it is difficult to discern how much the user "cares" about a given parameter. > Did they enter "P222" because they don't know what the space group is? Or > did they enter it because they actually think they are in the rarest space > group of them all? The solution I arrived upon in Elves was to add the > extension "-ish" to the space group name whenever it is not set in stone. > Doesn't work in the mtz header, of course, but maybe it should? A flag for > "soft symmetry"? > > In response to the OP, I still prefer using space groups that have numbers > less than 1000. This is because there are programs (like XDS) that only use > space group numbers. Space group number "18" is P21212 in the International > Tables, not P22121 nor P21221. That, and I have never seen violation of the a > < b < c rule break anything. P22121, however, does break things (and the > list changes over time). R3 is even worse. > > At the end of the day, I think it would be great if refinement programs (and > their users) could be a bit smarter when it comes to symmetry-allowed > transformations. Imagine a tool that would allow you to say: "darn it, I want > to switch from P22121 to P21212", and it would change your pdb and mtz to do > that. If it were that easy, we wouldn't be having this discussion. > Moreover, how about: "hey, I want to switch my refinement from P6122 to C2", > and it would expand out your PDB and re-scale your raw data. I think such a > tool would be a popular one. Especially when you're trying to figure out > twinning. > > -James Holton > MAD Scientist > > On Fri, Jan 29, 2016 at 6:10 AM, Quyen Hoang <qqho...@gmail.com> wrote: > Given enough data and modern computing powers, why don’t we just use P1? > > Quyen > > >> On Jan 29, 2016, at 8:45 AM, George Sheldrick <gshe...@shelx.uni-ac.gwdg.de> >> wrote: >> >> The collection and scaling requires the Laue group but not the space group. >> For small molecule structure determination, many more space groups have to >> be considered and the choice may be ambiguous (like I222 and I212121) or >> difficult, so my current small molecule structure solution program SHELXT >> only uses the input space group to deduce the Laue group. After solving the >> structure with the data expanded to P1 it uses the phases to determine the >> space group and origin shift. In practice this is much more reliable than >> using systematic absences. This was not my idea (see papers by Giacovazzo >> and Palatinus), I just wrote a little program to implement it. How the user >> has chosen a, b and c is irrelevant, the program outputs the solution in the >> conventional setting for the space group in question (as the correct >> enantiomorph based on the Friedel differences where appropriate). It also >> finds the most compact arrangement of atoms and centers it is the unit-cell. >> >> Whether this was worth the effort is debatable. SHELXT has been freely >> available for the last couple of years, but the open access paper that >> explains how it works (Acta A71 (2015) 3-8) is rarely cited. >> >> George >> >> >> On 01/29/2016 01:06 PM, Ian Tickle wrote: >>> >>> Hi Kay >>> >>> You are seriously misrepresenting how this works in practice. Isomorphism >>> always takes precedence over convention: convention is not an absolute >>> requirement! Convention is the _default_ in the absence of all other >>> criteria (that's why we have conventions!). Only the _first_ crystal in an >>> isomorphous series would be indexed by convention, the others would be >>> indexed using that as a reference (i.e. based on the intensity correlation, >>> _not_ the unit cell or the assumed space group which may not be reliable, >>> using REFINDEX, which is what we have always used, or POINTLESS) - very >>> simple! At Astex we have be doing this for our large fragment screens for >>> 15 years with no problem. >>> >>> In any case we find that assignment of screw axes by axial reflexions is >>> very unreliable (we have been stung on several occasions!) and we always >>> postpone choice of space group until _after_ the experimental phasing or MR >>> step, or even after the structure refinement step, i.e. doing MR and/or >>> refinement in _all_ 8 possible space groups. So space groups #16, 17, 18 & >>> 19 would always be initally assigned as space group #16 (P222): that's what >>> XDS does anyway, so no change there! I would _always_ recommend that >>> procedure over relying on the axial reflexions for space-group assigment. >>> For some datasets many of the reflexions on one of the axes were not even >>> measured! (i.e. where the crystal happens to be aligned along an axis and >>> only a single scan is done). >>> >>> Contrary to what you are asserting, the convention you propose has been the >>> source of great confusion & muddle in the past, whereas the >>> internationally-agreed one is very clear and has been largely free from >>> confusion (obviously because it was very carefully designed to be that >>> way). What happened on a number of occasions in the past (and quite >>> possibly still happens in some labs) was that the space group was initally >>> assigned as P222 according to the clear procedure described above, with the >>> conventional cell correctly assigned as a <= b <= c. What should happen >>> then is that once the correct space group has been decided, the space group >>> in the header is changed to that - simple, end of story. However some >>> people think they have to re-index to the 'standard setting' for SGs 17 & >>> 18 (note that the standard setting has nothing to do with the conventional >>> cell defined in ITC). So they end up with files indexed differently - a >>> recipe for disaster, since they can easily forget to also transform the >>> co-ordinate file from the MR step, or they do manage to transform it but >>> then mix up the files, thus R-value = random! I have had to sort out >>> peoples' mess on a number of occasions which is why I specified the above >>> idiot-proof procedure when we designed the Astex fragment-screening >>> pipeline back in 2000. >>> >>> See these papers by Alan Mighell at NIST (one of the original authors of >>> the conventional cell tables in ITC) for why we need conventions. >>> >>> http://nvlpubs.nist.gov/nistpubs/jres/106/6/j66mig.pdf >>> http://nvlpubs.nist.gov/nistpubs/jres/107/4/j74mig.pdf >>> >>> The most important feature of an international convention is that it is >>> documented in detail, otherwise how on earth will anyone know how to apply >>> the convention? The document for the IUCr >>> conventional cells is the ITC, based in part on the proposals in the above >>> papers. I'm not aware of any documentation (for all 230 space groups BTW!) >>> for the convention that you are proposing. I just don't understand why >>> after we've all agreed on a convention (or at least our national >>> representatives on the relevant IUCr committees on conventions have on our >>> behalf), why you then want to go and do something completely different? >>> >>> Cheers >>> >>> -- Ian >>> >>> >>> >>> On 29 January 2016 at 09:30, Kay Diederichs >>> <kay.diederi...@uni-konstanz.de> wrote: >>> Good morning Graeme, >>> >>> as may be obvious from earlier conversations about this, I have a rather >>> strong opinion about this: even in 2016, >>> - the a < b < c ordering has no scientific advantage in any way; it may >>> appear more aesthetic to some >>> - the ordering has a clear disadvantage if two cell edges are about the >>> same length, because then, for different measurements, you may end up with >>> different symmetries. This would be even worse if all three a,b,c are >>> approximately the same. What a nightmare e.g. in serial crystallography! >>> >>> Crystallography is difficult enough. Our choices should be such that we >>> make it easier for novices to understand it, and to avoid errors. Failure >>> to find (or think about) the proper re-indexing is one of the most often >>> occurring problems. >>> >>> best, >>> >>> Kay >>> >>> >>> >>> On Fri, 29 Jan 2016 09:13:16 +0000, Graeme Winter >>> <graeme.win...@diamond.ac.uk> wrote: >>> >>> >Good morning all, >>> > >>> >It is with some trepidation I raise the following question: does anyone >>> >still care about reindexing orthorhombic lattices so that the unique axis >>> >is C? I.e. P21221 => P21212 >>> > >>> >Back in the day certain programs would express unhappiness if you fed them >>> >P21 2 21 (say) data - I am certain that this problem has gone away. Is >>> >there any reason in 2016 that (say) xia2 should write out symmetry based >>> >not cell based data? I am leaning towards indexing these so that a < b < c >>> >and then the screw axes are whatever they are. >>> > >>> >How do people feel about this? >>> > >>> >Thanks & best wishes Graeme >>> > >>> >-- >>> >This e-mail and any attachments may contain confidential, copyright and or >>> >privileged material, and are for the use of the intended addressee only. >>> >If you are not the intended addressee or an authorised recipient of the >>> >addressee please notify us of receipt by returning the e-mail and do not >>> >use, copy, retain, distribute or disclose the information in or attached >>> >to the e-mail. >>> >Any opinions expressed within this e-mail are those of the individual and >>> >not necessarily of Diamond Light Source Ltd. >>> >Diamond Light Source Ltd. cannot guarantee that this e-mail or any >>> >attachments are free from viruses and we cannot accept liability for any >>> >damage which you may sustain as a result of software viruses which may be >>> >transmitted in or with the message. >>> >Diamond Light Source Limited (company no. 4375679). Registered in England >>> >and Wales with its registered office at Diamond House, Harwell Science and >>> >Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom >>> >> >> >> -- >> Prof. George M. Sheldrick FRS >> Dept. Structural Chemistry, >> University of Goettingen, >> Tammannstr. 4, >> D37077 Goettingen, Germany >> Tel. >> +49-551-39-33021 >> or -33068 >> Fax. >> +49-551-39-22582 >> >> >> > >
