Re: [ccp4bb] asking for a reference for cacodylate decomposition in protein crystals upon X-ray exposure
Am 29 Jul 2012 um 18:53 hat Tatyana Sysoeva geschrieben: Hi! I heard a couple of times that use of cacodylate buffers in crystallization is bad, and not only because of the compound toxicity. As I understood, presence of the cacodylate in a protein crystal will cause a particular crystal degradation pattern upon X-ray exposure - darkening of the crystals, gas formation I tried to find some references on that and failed in doing so. I found some earlier discussions like this one: http://www.proteincrystallography.org/ccp4bb/message23691.html but don't have anything to reference in literature. I would appreciate if someone can point me to a right direction. I am sorry if this question is out of the groups topic range. Thank you in advance! Sincerely, Tanya Dear Tanya, cacodylate can be attacked by nucleophilic side chains and can form covalent adducts, e.g.: http://www.jbc.org/content/278/3/2008.long Good luck, Karsten --- Karsten Niefind University of Cologne Department of Chemistry Institute of Biochemistry Otto-Fischer-Str. 12-14 D-50674 Cologne Tel.: +49 221 470 6444 Fax: +49 221 470 3244
[ccp4bb] manipulation of water molecules in pdb files
Dear all, I have a refine structure with 8 ncs copies and several hundreds of water molecules (which was put in one chain). Now I try to separate these molecules by renaming to the chain id of each adjacent protein molecule. I know RCSB can do this during deposition process. Do anyone know a program can do a similar task? Many thanks! Best, Zhiyi
Re: [ccp4bb] asking for a reference for cacodylate decomposition in protein crystals upon X-ray exposure
Dear Tatyana, We once had a project where the crystallization condition contained cacodylate. The crystals diffracted to 1.9A and survived reasonably well under the beam (maybe there was indeed some colour change upon exposure, I do not remember exactly). We were working with drug soaks. The original structure is 1HYV. The most interesting result of cacodylate presence is modification of Cys residues. It was interpreted as S-dimethylarsinoyl cysteine. Best wishes, Sergei On 30-Jul-12 12:53 AM, Tatyana Sysoeva wrote: Hi! I heard a couple of times that use of cacodylate buffers in crystallization is bad, and not only because of the compound toxicity. As I understood, presence of the cacodylate in a protein crystal will cause a particular crystal degradation pattern upon X-ray exposure - darkening of the crystals, gas formation I tried to find some references on that and failed in doing so. I found some earlier discussions like this one: http://www.proteincrystallography.org/ccp4bb/message23691.html but don't have anything to reference in literature. I would appreciate if someone can point me to a right direction. I am sorry if this question is out of the groups topic range. Thank you in advance! Sincerely, Tanya -- Prof. Sergei V. Strelkov Laboratory for Biocrystallography Department of Pharmaceutical Sciences, Katholieke Universiteit Leuven ON2, Campus Gasthuisberg, Herestraat 49 bus 822, 3000 Leuven, Belgium Work phone: +32 16 330845 Fax: +32 16 323469 OR +32 16 323460 Mobile: +32 486 294132 Lab pages: http://pharm.kuleuven.be/anafar
Re: [ccp4bb] Alternative conformation of Phe and Tyr?
Dear experts, Thank you for your helpful input. I think it's clear now to conclude that the alternative conformations exist on both Phe and Tyr residues. Counter level = 1 sigma http://i50.tinypic.com/anzfrn.png Counter level = 0.7 sigma - the alternative conformation of Phe can be confirmed. http://i49.tinypic.com/5v57pi.jpg Counter level = 0.3 sigma - the alternative conformation of Tyr can be confirmed. http://i48.tinypic.com/11vh7he.jpg Thank you Dr. Herman for your additional comments. Yes I can confirm that the in position cannot be occupied by both residues since we had another structure in which Phe was mutated to Trp. In this structure, the Trp always has in conformation and Tyr always has out conformation. My best regards, Tri Ngo On Mon, Jul 30, 2012 at 4:45 PM, herman.schreu...@sanofi.com wrote: ** Hi Bernard, When I wrote my comment, I considered the same, since correlated alternative conformations are in my experience quite common. However, I do not believe it is the case here. The Phe and Tyr can have two conformations: an in conformation, pointing towards the other, and an out conformation, pointing away from the other. There is no problem for both side chains occupying the out position, but only one of them can occupy the in conformation, since both side chains in this conformation would clash. This means that the sum of the partial occupancies for the in conformation can not be greater than one, which, as I recall correctly, is also what is observed with ~0.3 for the in conformation and ~0.7 for the out conformation. However, the partial occupancies need not be the same for the Phe and the Tyr. My two cents, Herman PS: I was told that in refmac clashes between parital occupancies are ignored if their sum is less or equal than 1. -- *From:* CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *On Behalf Of *Bernhard Rupp *Sent:* Friday, July 27, 2012 5:02 PM *To:* CCP4BB@JISCMAIL.AC.UK *Subject:* Re: [ccp4bb] Alternative conformation of Phe and Tyr? Hmmm…I have a question for the experts: It seems to me from the figure (although that is for Tri Ngo to verify), that these partial occupancies are correlated. When conformation A of TYR (in the green density) is occupied, Phe B in the blue density probably cannot be occupied because of a VdW clash. (Again, caveat that I can’t see that exactly from the static image) I recall that Shelxl allows to constrain such occupancies, but how are Refmac and Phenix dealing with that? How would I implement that? Are clashes between partial occs just ignored? ** ** Even if I am wrong about the existence of a clash in this particular case, such situations are not uncommon imho. ** ** Thx, BR *From:* CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *On Behalf Of *Pavel Afonine *Sent:* Friday, July 27, 2012 7:17 AM *To:* CCP4BB@JISCMAIL.AC.UK *Subject:* Re: [ccp4bb] Alternative conformation of Phe and Tyr? ** ** Hi, ** ** you can't expect to see something with occupancy ~0.3 at the same cutoff level as you use to see fully occupied sites. So most likely the solution is to use a lower cutoff levels, as many suggested already. Two maps you attached look totally expectable to me. ** ** Pavel On Fri, Jul 27, 2012 at 1:01 AM, Tri Ngo ngoduc...@gmail.com wrote: Dear ccp4bb, ** ** I am working on refinement of an enzyme structure. I notice an alternative conformation (gauche+ and gauche-) on both residues Phe and Tyr. ** ** Here is the image of electron density before refinement. Based on the different map intensity, I am quite sure there is an alternative conformation on both positions. ** ** http://i50.tinypic.com/29zaoap.jpg ** ** However, after running occupancy refinement by Phenix, I don't see the density map at the gauche- conformation of Tyr residue. Please take a look at the image 2. ** ** http://i50.tinypic.com/anzfrn.png ** ** So do you think the gauche- conformation of Tyr exists in this structure. Should I keep it in the final model because there is no positive map there? ** ** ** ** Thank you very much for your input. ** ** -- ** *Ngo Duc Tri* * * PhD Student Structural Biology Lab School of Medicine - Sungkyunkwan University - Korea Phone: 031-299-6150 - Cell: 010-7774-8210 ** ** ** ** -- * Ngo Duc Tri * PhD Student Structural Biology Lab School of Medicine - Sungkyunkwan University - Korea Phone: 031-299-6150 - Cell: 010-7774-8210
Re: [ccp4bb] manipulation of water molecules in pdb files
Dear Zhiyi, I think that sortwater (http://www.ccp4.ac.uk/html/sortwater.html), will do something along what you want. Remember to read the documentation ;-) Best regards, Folmer 2012/7/30 Zhiyi Wei ustcwebri...@gmail.com Dear all, I have a refine structure with 8 ncs copies and several hundreds of water molecules (which was put in one chain). Now I try to separate these molecules by renaming to the chain id of each adjacent protein molecule. I know RCSB can do this during deposition process. Do anyone know a program can do a similar task? Many thanks! Best, Zhiyi -- Folmer Fredslund
[ccp4bb] refinement of ligands
Dear all, I am currently trying to refine co-crystallized ligand structures at 2.8-3.4 Å resolution. After initial molecular replacement the density in the maps, both 2Fo-Fc and Fo-Fc looks good and the ligand seams to have bound. However after running Refmac directly on the output files the maps get much worse. I am using a clean pdb, without ligand or water for the Phaser and subsequent Refmac runs. Also when refining with the ligand in the B factors are a lot higher for the ligand then the surrounding residues, only when lowering the occupancy to 0.7-0.8 for the ligand the B factors look better. Is that acceptable to do at this resolution? R-free is in the 0.24-0.27 range. There is only a marginal change in R-free with the addition of ligand. TLS refinement seams to help alot for overall R values but does not improve the maps. I have also tried Phenix with simulated annealing, rigid body and reference structures. So the question is how best to proceed with refinement at the rather low resolution?? Regards, Damian Damian Niegowski Ph.D. Institute of Medical Biochemistry and Biophysics Karolinska Institutet Scheeles väg 2 171 77 STOCKHOLM e-mail: damian.niegow...@ki.se phone: 0046 8 524 876 33 fax: 0046 8 736 04 39
Re: [ccp4bb] refinement of ligands
Dear Damian, The initial map after molecular replacement and BEFORE atomic refinement is maybe not the highest quality map, but definitively the map with the least model bias. If you see good density for you inhibitors in those maps, they almost certainly will have bound. In that case I would fit the inhibitor in those very first maps and continue from there. The inhibitor density probably got worse during refmac refinement without inhibitor since refinement programs try to minimize the difference between Fobs and Fcalc. If an inhibitor is present in Fobs, but not in the model (Fcalc), the refinement program might try to tweak the model such that this difference (the inhibitor) gets flattened out. This is called model bias. Modern refinement programs try to counteract this effect by using maximum likelyhood or other statistical methods, but apparently at the low resolution you have refmac did not have enough data to succesfully remove this model bias. You may want to try buster for refinement, since this program may suffer less from model bias. Buster also allows you to do a group occupancy refinement of you inhibitor, since it may indeed by present at partial occupancy. An Rfree of 0.24 would be ok, 0.27 is a little high but still not really worrying. If your Rfactors go down a lot with TLS, this means that you have a lot of movement in your protein and that your maps are as good as they will get. Best, Herman -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Damian Niegowski Sent: Monday, July 30, 2012 12:04 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] refinement of ligands Dear all, I am currently trying to refine co-crystallized ligand structures at 2.8-3.4 Å resolution. After initial molecular replacement the density in the maps, both 2Fo-Fc and Fo-Fc looks good and the ligand seams to have bound. However after running Refmac directly on the output files the maps get much worse. I am using a clean pdb, without ligand or water for the Phaser and subsequent Refmac runs. Also when refining with the ligand in the B factors are a lot higher for the ligand then the surrounding residues, only when lowering the occupancy to 0.7-0.8 for the ligand the B factors look better. Is that acceptable to do at this resolution? R-free is in the 0.24-0.27 range. There is only a marginal change in R-free with the addition of ligand. TLS refinement seams to help alot for overall R values but does not improve the maps. I have also tried Phenix with simulated annealing, rigid body and reference structures. So the question is how best to proceed with refinement at the rather low resolution?? Regards, Damian Damian Niegowski Ph.D. Institute of Medical Biochemistry and Biophysics Karolinska Institutet Scheeles väg 2 171 77 STOCKHOLM e-mail: damian.niegow...@ki.se phone: 0046 8 524 876 33 fax: 0046 8 736 04 39
Re: [ccp4bb] Space group R32 and H32
Without wishing to re-ignite previous discussions on this topic (perhaps FLAME ... /FLAME tags would be in order!), I would point out that this and similar confusion with other space groups has arisen largely from a failure of some programmers (and users!) to fully comprehend the important difference between a 'standard symbol' and a 'setting symbol' for a space group, no doubt because in many cases these are superficially identical, or a least very similar. This point is also made in the Computational Crystallography Newsletter article on H3 and H32 that I referenced earlier. The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a space group and crucially is designed to be independent of the setting (orientation and/or origin). It is used to identify a space group without reference to the setting, and therefore its main use is to provide page headings and index entries in ITC. There exist exactly 230 H-M standard symbols for the 230 unique 3D space groups. The H-M standard symbol is the same for all settings of a particular space group and therefore cannot be used to define the setting: for that you obviously need additional information. The standard symbol is thus of little or no relevance to practical crystallography: for that you must use a setting symbol. However for the majority of space groups only one setting is accepted as 'conventional' so in those cases the standard and setting symbols are identical; it's only where there are multiple settings that problems arise. A simple analogy might be to say that an object is called 'building' and that is also its standard symbol. It describes the object without reference to its orientation or position and so is not relevant to the practical problem of defining the view of the building: for that you need extra symbols. For example you might need to specify one of the setting symbols 'building (front elevation)', 'building (side elevation)' or 'building (plan)'. So R32 is a H-M standard symbol which corresponds to the 2 alternate setting symbols R32:r and R32:h as described in the article. Plainly you can't use the H-M symbol R32 to uniquely specify the setting since it is the standard symbol for both the R32:r and R32:h settings. The latter are _not_ H-M symbols: they are ITC extensions of the H-M symbol. For other space groups further confusion has arisen because ITC often uses the exact same character string for both the standard symbol and one of the corresponding alternate setting symbols. An obvious example is P21212: this is the H-M standard symbol for SG #18 but is also one of the 3 ITC setting symbols for P21212, the other two being P22121 and P21221. Perhaps the intention would have been clearer if the ITC setting symbols had all been made different from the standard symbol, as they are in the R32 case. For example P21212a, P21212b and P21212c would have been equally valid choices for the ITC setting symbols but do not express a 'preferred' setting (since there isn't one). Similarly the standard symbol for SG #5 (unique axis b) is C2, and the alternate setting symbols are A2, C2 and I2, but they could equally well have been (for example) C2a, C2c and C2i, which doesn't express a preference for any one of the alternate settings. Either way, according to the ITC rules, the choice of 'conventional' setting for a space group (i.e. the recommended default choice when there are no other grounds such as isomorphism with a previously determined structure) is made by reference to the unit cell. For R32 the conventional cell happens to be the hexagonal one (a = b != c, alpha = beta = 90, gamma = 120) with symbol R32:h; for all orthorhombic SGs the convention is a b c and the setting symbol derives from that. Cheers -- Ian On 28 July 2012 22:22, Edward A. Berry ber...@upstate.edu wrote: Are all the software packages consistent in their (mis)use of these symbols? Recently I scaled data (scalepack) as R3, imported to ccp4 as H3, and had to make a link in $ODAT/symm from R32 to H32 (which it turned out to be). Ian Tickle wrote: If we're all agreed that ITC(A) is taken as the authority on all matters of space group symbology (and I for one certainly agree that it should be), then SG symbol H32 (SG #145: http://img.chem.ucl.ac.uk/sgp/medium/145bz1.htm) has nothing to do with R32 (SG #155: http://img.chem.ucl.ac.uk/sgp/medium/155az1.htm)! According to the Hermann-Mauguin system of nomenclature H32 (more correctly written as H3_2 where the '_' indicates a subscripted screw axis) would be the hexagonal-centred (H) lattice setting of P32 (P3_2 in H-M). H32 as an alternate setting symbol for R32 is a very recent PDB invention which conflicts with the well-established H-M convention used throughout ITC. The ITC symbols for the rhombohedral hexagonal axis settings of SG R32 are R32:r and R32:h respectively, i.e. obvious extensions of the H-M symbols without introducing any conflict with the existing
Re: [ccp4bb] Space group R32 and H32
Hi there, at this point I'm confused, at least with respect to one thing. If I have a solved a structure in spacegroup #155, with a=b and different from c, and alpha=beta=90, gamma=120, this would be reported as R32 in the international tables. However programs refers to it as H32. What should I report in the (in)famous table 1 ? Thanks in advance, ciao, s On Jul 30, 2012, at 5:23 PM, Ian Tickle wrote: Without wishing to re-ignite previous discussions on this topic (perhaps FLAME ... /FLAME tags would be in order!), I would point out that this and similar confusion with other space groups has arisen largely from a failure of some programmers (and users!) to fully comprehend the important difference between a 'standard symbol' and a 'setting symbol' for a space group, no doubt because in many cases these are superficially identical, or a least very similar. This point is also made in the Computational Crystallography Newsletter article on H3 and H32 that I referenced earlier. The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a space group and crucially is designed to be independent of the setting (orientation and/or origin). It is used to identify a space group without reference to the setting, and therefore its main use is to provide page headings and index entries in ITC. There exist exactly 230 H-M standard symbols for the 230 unique 3D space groups. The H-M standard symbol is the same for all settings of a particular space group and therefore cannot be used to define the setting: for that you obviously need additional information. The standard symbol is thus of little or no relevance to practical crystallography: for that you must use a setting symbol. However for the majority of space groups only one setting is accepted as 'conventional' so in those cases the standard and setting symbols are identical; it's only where there are multiple settings that problems arise. A simple analogy might be to say that an object is called 'building' and that is also its standard symbol. It describes the object without reference to its orientation or position and so is not relevant to the practical problem of defining the view of the building: for that you need extra symbols. For example you might need to specify one of the setting symbols 'building (front elevation)', 'building (side elevation)' or 'building (plan)'. So R32 is a H-M standard symbol which corresponds to the 2 alternate setting symbols R32:r and R32:h as described in the article. Plainly you can't use the H-M symbol R32 to uniquely specify the setting since it is the standard symbol for both the R32:r and R32:h settings. The latter are _not_ H-M symbols: they are ITC extensions of the H-M symbol. For other space groups further confusion has arisen because ITC often uses the exact same character string for both the standard symbol and one of the corresponding alternate setting symbols. An obvious example is P21212: this is the H-M standard symbol for SG #18 but is also one of the 3 ITC setting symbols for P21212, the other two being P22121 and P21221. Perhaps the intention would have been clearer if the ITC setting symbols had all been made different from the standard symbol, as they are in the R32 case. For example P21212a, P21212b and P21212c would have been equally valid choices for the ITC setting symbols but do not express a 'preferred' setting (since there isn't one). Similarly the standard symbol for SG #5 (unique axis b) is C2, and the alternate setting symbols are A2, C2 and I2, but they could equally well have been (for example) C2a, C2c and C2i, which doesn't express a preference for any one of the alternate settings. Either way, according to the ITC rules, the choice of 'conventional' setting for a space group (i.e. the recommended default choice when there are no other grounds such as isomorphism with a previously determined structure) is made by reference to the unit cell. For R32 the conventional cell happens to be the hexagonal one (a = b != c, alpha = beta = 90, gamma = 120) with symbol R32:h; for all orthorhombic SGs the convention is a b c and the setting symbol derives from that. Cheers -- Ian On 28 July 2012 22:22, Edward A. Berry ber...@upstate.edu wrote: Are all the software packages consistent in their (mis)use of these symbols? Recently I scaled data (scalepack) as R3, imported to ccp4 as H3, and had to make a link in $ODAT/symm from R32 to H32 (which it turned out to be). Ian Tickle wrote: If we're all agreed that ITC(A) is taken as the authority on all matters of space group symbology (and I for one certainly agree that it should be), then SG symbol H32 (SG #145: http://img.chem.ucl.ac.uk/sgp/medium/145bz1.htm) has nothing to do with R32 (SG #155: http://img.chem.ucl.ac.uk/sgp/medium/155az1.htm)! According to the Hermann-Mauguin system of nomenclature H32 (more correctly written as H3_2 where
Re: [ccp4bb] Space group R32 and H32
Hi Sebastiano How programs refer to it is irrelevant for the purposes of publication! If you want to be precise and stick to the ITC convention on nomenclature it's space group R32 in the setting R32:h, since as I explained it's only the standard symbol R32 which is generally shown in the main ITC table of space groups; the setting symbols are not shown in all cases. However simply calling it 'R32:h' is also completely unambiguous and acceptable (but calling it 'R32' most definitely is not!). For the PDB CRYST1 record you have (unfortunately) to call it 'H32'. Hope this clears it up. -- Ian On 30 July 2012 17:20, Sebastiano Pasqualato sebastiano.pasqual...@gmail.com wrote: Hi there, at this point I'm confused, at least with respect to one thing. If I have a solved a structure in spacegroup #155, with a=b and different from c, and alpha=beta=90, gamma=120, this would be reported as R32 in the international tables. However programs refers to it as H32. What should I report in the (in)famous table 1 ? Thanks in advance, ciao, s On Jul 30, 2012, at 5:23 PM, Ian Tickle wrote: Without wishing to re-ignite previous discussions on this topic (perhaps FLAME ... /FLAME tags would be in order!), I would point out that this and similar confusion with other space groups has arisen largely from a failure of some programmers (and users!) to fully comprehend the important difference between a 'standard symbol' and a 'setting symbol' for a space group, no doubt because in many cases these are superficially identical, or a least very similar. This point is also made in the Computational Crystallography Newsletter article on H3 and H32 that I referenced earlier. The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a space group and crucially is designed to be independent of the setting (orientation and/or origin). It is used to identify a space group without reference to the setting, and therefore its main use is to provide page headings and index entries in ITC. There exist exactly 230 H-M standard symbols for the 230 unique 3D space groups. The H-M standard symbol is the same for all settings of a particular space group and therefore cannot be used to define the setting: for that you obviously need additional information. The standard symbol is thus of little or no relevance to practical crystallography: for that you must use a setting symbol. However for the majority of space groups only one setting is accepted as 'conventional' so in those cases the standard and setting symbols are identical; it's only where there are multiple settings that problems arise. A simple analogy might be to say that an object is called 'building' and that is also its standard symbol. It describes the object without reference to its orientation or position and so is not relevant to the practical problem of defining the view of the building: for that you need extra symbols. For example you might need to specify one of the setting symbols 'building (front elevation)', 'building (side elevation)' or 'building (plan)'. So R32 is a H-M standard symbol which corresponds to the 2 alternate setting symbols R32:r and R32:h as described in the article. Plainly you can't use the H-M symbol R32 to uniquely specify the setting since it is the standard symbol for both the R32:r and R32:h settings. The latter are _not_ H-M symbols: they are ITC extensions of the H-M symbol. For other space groups further confusion has arisen because ITC often uses the exact same character string for both the standard symbol and one of the corresponding alternate setting symbols. An obvious example is P21212: this is the H-M standard symbol for SG #18 but is also one of the 3 ITC setting symbols for P21212, the other two being P22121 and P21221. Perhaps the intention would have been clearer if the ITC setting symbols had all been made different from the standard symbol, as they are in the R32 case. For example P21212a, P21212b and P21212c would have been equally valid choices for the ITC setting symbols but do not express a 'preferred' setting (since there isn't one). Similarly the standard symbol for SG #5 (unique axis b) is C2, and the alternate setting symbols are A2, C2 and I2, but they could equally well have been (for example) C2a, C2c and C2i, which doesn't express a preference for any one of the alternate settings. Either way, according to the ITC rules, the choice of 'conventional' setting for a space group (i.e. the recommended default choice when there are no other grounds such as isomorphism with a previously determined structure) is made by reference to the unit cell. For R32 the conventional cell happens to be the hexagonal one (a = b != c, alpha = beta = 90, gamma = 120) with symbol R32:h; for all orthorhombic SGs the convention is a b c and the setting symbol derives from that. Cheers -- Ian On 28 July 2012 22:22, Edward A. Berry
Re: [ccp4bb] Space group R32 and H32
That is perfectly clear. What was confusing me was indeed (mostly) the PDB CRYST1 record. I guess I will go for R32:h. Thanks a lot, ciao, s On Jul 30, 2012, at 6:36 PM, Ian Tickle wrote: Hi Sebastiano How programs refer to it is irrelevant for the purposes of publication! If you want to be precise and stick to the ITC convention on nomenclature it's space group R32 in the setting R32:h, since as I explained it's only the standard symbol R32 which is generally shown in the main ITC table of space groups; the setting symbols are not shown in all cases. However simply calling it 'R32:h' is also completely unambiguous and acceptable (but calling it 'R32' most definitely is not!). For the PDB CRYST1 record you have (unfortunately) to call it 'H32'. Hope this clears it up. -- Ian On 30 July 2012 17:20, Sebastiano Pasqualato sebastiano.pasqual...@gmail.com wrote: Hi there, at this point I'm confused, at least with respect to one thing. If I have a solved a structure in spacegroup #155, with a=b and different from c, and alpha=beta=90, gamma=120, this would be reported as R32 in the international tables. However programs refers to it as H32. What should I report in the (in)famous table 1 ? Thanks in advance, ciao, s On Jul 30, 2012, at 5:23 PM, Ian Tickle wrote: Without wishing to re-ignite previous discussions on this topic (perhaps FLAME ... /FLAME tags would be in order!), I would point out that this and similar confusion with other space groups has arisen largely from a failure of some programmers (and users!) to fully comprehend the important difference between a 'standard symbol' and a 'setting symbol' for a space group, no doubt because in many cases these are superficially identical, or a least very similar. This point is also made in the Computational Crystallography Newsletter article on H3 and H32 that I referenced earlier. The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a space group and crucially is designed to be independent of the setting (orientation and/or origin). It is used to identify a space group without reference to the setting, and therefore its main use is to provide page headings and index entries in ITC. There exist exactly 230 H-M standard symbols for the 230 unique 3D space groups. The H-M standard symbol is the same for all settings of a particular space group and therefore cannot be used to define the setting: for that you obviously need additional information. The standard symbol is thus of little or no relevance to practical crystallography: for that you must use a setting symbol. However for the majority of space groups only one setting is accepted as 'conventional' so in those cases the standard and setting symbols are identical; it's only where there are multiple settings that problems arise. A simple analogy might be to say that an object is called 'building' and that is also its standard symbol. It describes the object without reference to its orientation or position and so is not relevant to the practical problem of defining the view of the building: for that you need extra symbols. For example you might need to specify one of the setting symbols 'building (front elevation)', 'building (side elevation)' or 'building (plan)'. So R32 is a H-M standard symbol which corresponds to the 2 alternate setting symbols R32:r and R32:h as described in the article. Plainly you can't use the H-M symbol R32 to uniquely specify the setting since it is the standard symbol for both the R32:r and R32:h settings. The latter are _not_ H-M symbols: they are ITC extensions of the H-M symbol. For other space groups further confusion has arisen because ITC often uses the exact same character string for both the standard symbol and one of the corresponding alternate setting symbols. An obvious example is P21212: this is the H-M standard symbol for SG #18 but is also one of the 3 ITC setting symbols for P21212, the other two being P22121 and P21221. Perhaps the intention would have been clearer if the ITC setting symbols had all been made different from the standard symbol, as they are in the R32 case. For example P21212a, P21212b and P21212c would have been equally valid choices for the ITC setting symbols but do not express a 'preferred' setting (since there isn't one). Similarly the standard symbol for SG #5 (unique axis b) is C2, and the alternate setting symbols are A2, C2 and I2, but they could equally well have been (for example) C2a, C2c and C2i, which doesn't express a preference for any one of the alternate settings. Either way, according to the ITC rules, the choice of 'conventional' setting for a space group (i.e. the recommended default choice when there are no other grounds such as isomorphism with a previously determined structure) is made by reference to the unit cell. For R32 the conventional cell happens to be the hexagonal one (a = b != c,
Re: [ccp4bb] Space group R32 and H32
Dear Ian, I made a modest contribution to this discussion a long time ago, and I will only limit myself to one point. I think you may be confusing setting and lattice mode. A change of setting is performed by an integer matrix with determinant 1 (a unimodular matrix) whereas a change of lattice mode involves two mutually inverse integer matrices with determinants (mutually inverse, of course) different from 1. The case of R32 and H32 seems to stick out like a sore thumb because we never use the primitive-lattice versions of the centered-lattice space groups in the monoclinic, orthorhombic and tetragonal classes - and yet they exist! The problem with them is that e.g. 2-fold axes are represented by non-diagonal matrices that are somehow thought to be an eyesore, so we sacrifice mathematical rigour (the theory of arithmetic classes) to the comfort of having a 2-fold axis represented by the familiar diagonal matrix with one 1 and two -1 on it. The matrices that would reindex those primitive lattices to the usual centered ones would have determinants 2 or 4 in one direction, and 1/2 or 1/4 in the other. However, as we never see these representations of centered space groups in a primitive lattice basis, we are startled when we come to the trigonal class. Here, the 3-fold axis has two distinct representations by integer matrices: one in which the three axes undergo a circular permutation (so they have to be of equal lengths and separated by equal angles), and the other in which one axis (z) is invariant, and the 3-fold symmetry is represented by a 120-degree rotation in the (x,y) plane. These two representations cannot be mapped into each other by means of a unimodular matrix: if one reindexes one representation into the other, the determinant is 3 in one direction and 1/3 in the other. In this case, it is a matter of opinion which representation of a 3-fold axis has the greatest aesthetic merit, so the two possibilities are in use, unlike the poor non-diagonal 2-fold axis representations that no one wants to see. It is a matter of convention and vocabulary whether one calls these two modes of indexing the rhombohedral and hexagonal lattice modes, or calls them settings: one thing is certain, and that is that the mathematical phenomenon in question is of a different kind from the reindexing of P21212 into P22121 with which you draw a parallel. At least this is what my distant memories of space-group theory seem to be telling me :-)) . With best wishes, Gerard. -- On Mon, Jul 30, 2012 at 04:23:02PM +0100, Ian Tickle wrote: Without wishing to re-ignite previous discussions on this topic (perhaps FLAME ... /FLAME tags would be in order!), I would point out that this and similar confusion with other space groups has arisen largely from a failure of some programmers (and users!) to fully comprehend the important difference between a 'standard symbol' and a 'setting symbol' for a space group, no doubt because in many cases these are superficially identical, or a least very similar. This point is also made in the Computational Crystallography Newsletter article on H3 and H32 that I referenced earlier. The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a space group and crucially is designed to be independent of the setting (orientation and/or origin). It is used to identify a space group without reference to the setting, and therefore its main use is to provide page headings and index entries in ITC. There exist exactly 230 H-M standard symbols for the 230 unique 3D space groups. The H-M standard symbol is the same for all settings of a particular space group and therefore cannot be used to define the setting: for that you obviously need additional information. The standard symbol is thus of little or no relevance to practical crystallography: for that you must use a setting symbol. However for the majority of space groups only one setting is accepted as 'conventional' so in those cases the standard and setting symbols are identical; it's only where there are multiple settings that problems arise. A simple analogy might be to say that an object is called 'building' and that is also its standard symbol. It describes the object without reference to its orientation or position and so is not relevant to the practical problem of defining the view of the building: for that you need extra symbols. For example you might need to specify one of the setting symbols 'building (front elevation)', 'building (side elevation)' or 'building (plan)'. So R32 is a H-M standard symbol which corresponds to the 2 alternate setting symbols R32:r and R32:h as described in the article. Plainly you can't use the H-M symbol R32 to uniquely specify the setting since it is the standard symbol for both the R32:r and R32:h settings. The latter are _not_ H-M symbols: they are ITC extensions of the H-M symbol. For other space
