[ccp4bb] Question about enzyme behavior
Dear all, Sorry for a non purely crystallographic question. I am working on an enzyme which binds Fe2+ cations to catalyzes an FeII-dependent hydroxylation reaction. Because of fast oxidation in presence of the enzyme, it is very difficult to soak Fe2+ ions into the crystals. We succeed only under anaerobic conditions (glove box). I use a combination of dithionite as a reducing agent and Fe2+SO4 or (NH4)2Fe(SO4)2 as Fe2+ source. Despite these precautions, the Fe2+ is most often disordered in the active site. When I add Fe2+ under aerobic conditions, Fe2+ oxidizes immediately upon contact with the protein solution (despite 1mM Dithionite for 5mM Fe2+ and protein concentration = 230uM). Furthermore, the hydroxyl donor molecule, which should bind Fe2+ (before the substrate) and one residue of the protein, is not seen in the electron-density maps in the active site. I have tried several soaking conditions. When I try a co-crystallization approach, adding Fe2+ and this hydroxyl donor molecule directly to the protein solution under anaerobic conditions, the protein precipitates. Does anybody have an idea or experience with this type of results? or how to fix the molecule to such a site? What type of phenomena could occur at the active site preventing the binding of the product? Thanks for your help Best regards Tatiana
Re: [ccp4bb] Space group numbers
On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon
Re: [ccp4bb] Question about enzyme behavior
Hi Tatiana, Your problem is most reminiscent to the problem that Max Perutz faced when he dealt with deoxy-haemoglobin crystals, but in those days only mounting in capillaries was the way to bring the crystals to the beam, so he used dithionite, just like you, but mounted the crystals in (specially made for him at LMB) glove box under Nitrogen atmosphere. I guess you're now freezing your crystals for data collection, right? I'm not sure how to do this in a glove box nor am I sure whether after freezing your crystals is protected against oxidation. Maybe. But perhaps you can also consider using Parthon oil (or something similar) as cryo-protectant so it will coat your crystal in the glove box and will also reduce oxidation? Good luck, Boaz Boaz Shaanan, Ph.D. Dept. of Life Sciences Ben-Gurion University of the Negev Beer-Sheva 84105 Israel E-mail: bshaa...@bgu.ac.il Phone: 972-8-647-2220 Skype: boaz.shaanan Fax: 972-8-647-2992 or 972-8-646-1710 From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of ISABET Tatiana [tatiana.isa...@synchrotron-soleil.fr] Sent: Thursday, October 02, 2014 11:22 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Question about enzyme behavior Dear all, Sorry for a non purely crystallographic question. I am working on an enzyme which binds Fe2+ cations to catalyzes an FeII-dependent hydroxylation reaction. Because of fast oxidation in presence of the enzyme, it is very difficult to soak Fe2+ ions into the crystals. We succeed only under anaerobic conditions (glove box). I use a combination of dithionite as a reducing agent and Fe2+SO4 or (NH4)2Fe(SO4)2 as Fe2+ source. Despite these precautions, the Fe2+ is most often disordered in the active site. When I add Fe2+ under aerobic conditions, Fe2+ oxidizes immediately upon contact with the protein solution (despite 1mM Dithionite for 5mM Fe2+ and protein concentration = 230uM). Furthermore, the hydroxyl donor molecule, which should bind Fe2+ (before the substrate) and one residue of the protein, is not seen in the electron-density maps in the active site. I have tried several soaking conditions. When I try a co-crystallization approach, adding Fe2+ and this hydroxyl donor molecule directly to the protein solution under anaerobic conditions, the protein precipitates. Does anybody have an idea or experience with this type of results? or how to fix the molecule to such a site? What type of phenomena could occur at the active site preventing the binding of the product? Thanks for your help Best regards Tatiana
Re: [ccp4bb] Space group numbers
I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon
Re: [ccp4bb] Space group numbers
The strange thing is that small molecule crystallographers do not suffer from this problem, because they don't use space group numbers! This is just as well, because instead of just 8 combinations of primitive orthorhombic space groups and settings, they have to consider 111 (if I have counted correctly). George On 10/02/2014 11:50 AM, Frank von Delft wrote: I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon -- 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
Re: [ccp4bb] Space group numbers
How does XDS decide on eg P 21 21 2 when say c b a? The initial indexing may decide that the cell fits a primitive orthorhombic system, but I presume that it will then have some convention, probably a b c, since the identification of screws can only be done after integration, and even then may be uncertain. If e.g. Pointless later decides that the a axis is a dyad, and the b c axes are 2(1) screws, then it can assign space group P 2 21 21 without permuting the indices. If XDS is assigning space group P 21 21 2 then it must have permuted the axes from the initial indexing. It seems to me more straightforward to stick to the initial indexing rather than having to reindex after you have decided the true space group: this was Ian Tickle's point and is also supposedly the official IUCr-approved convention. There are of course ambiguous cases e.g. a ~= b, but that is the same as the indexing ambiguities in e.g. P3, and that needs a reference dataset to resolve. There is no problem in solving a structure in e.g. P 2 21 21, and indeed I would always run MR in all 8 possible primitive orthorhombic space groups, very easy to do in Phaser Phil On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon
[ccp4bb] 3 letter code
Hello everyone I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. -- Regards Faisal School of Life Sciences JNU
Re: [ccp4bb] Space group numbers
Hi, we shouldn't be using numbers at all (CCP4-style or otherwise, since no-one else outside the MX community uses these). We should be using the unique full Hermann-Mauguin symbol, since the 'standard setting' space group number in IT obviously does not uniquely define the setting, and it's the setting that matters. Note that the standard setting symbol P2221 means 'either P2122 or P2212 or P2221' according to the a=b=c convention (this is universal amongst the crystallography communities), so you still have to define the setting if you refer to the standard symbol. I'm aware that some software uses the list of general equivalent positions to define the space group but IMO that's overkill. If I wan't to talk about space group F432 you can't expect me to recite the list of 96 g.e.p.s! - the H-M symbol is sufficient. There are of course other cases besides P2221 where the setting is ambiguous (e.g. C2/A2/I2 and various cases of origin shifting), so using the correct symbol for the setting is critical. The most important features of any convention are a) that it's documented in an 'official' publication (i.e. not informal such as software documentation, otherwise how am I supposed to reference it?), and b) everyone subscribes to it. If you think we should be using a different convention then I want to see the proper documentation for it, with everything spelled out in excruciating detail (so it should be at least as thick as ITC!). It seems to me that ITC fulfils these requirements admirably! Cheers -- Ian On 2 October 2014 10:25, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon
[ccp4bb] AW: [ccp4bb] Question about enzyme behavior
Dear Tatania, Without having the details, it is difficult to make specific comments, but here are some suggestions: Aerobic experiments: you claim that added Fe2+ immediately oxidizes when added to a buffer containing 5 mM Fe2+. That means that the 5 mM Fe2+ in your buffer was already oxidized. Here I think it is not the amount of protein, but amount of dissolved oxygen in your buffer which is the important parameter. Did you degas your buffer before adding Fe2+ and dithionite? Glove box experiment: when your protein precipitates when Fe2+ and hydroxyl donor are added to the solution, this may point to some conformational change, which may also explain the disordered binding upon soaking. Does your protein have some natural partners which you could use for cocrystallization? Also, is some non-reacting analog of the hydroxyl donor known? Such a compound may block the enzyme one step before the complex you are now trying to generate. Good luck! Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Boaz Shaanan Gesendet: Donnerstag, 2. Oktober 2014 11:37 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Question about enzyme behavior Hi Tatiana, Your problem is most reminiscent to the problem that Max Perutz faced when he dealt with deoxy-haemoglobin crystals, but in those days only mounting in capillaries was the way to bring the crystals to the beam, so he used dithionite, just like you, but mounted the crystals in (specially made for him at LMB) glove box under Nitrogen atmosphere. I guess you're now freezing your crystals for data collection, right? I'm not sure how to do this in a glove box nor am I sure whether after freezing your crystals is protected against oxidation. Maybe. But perhaps you can also consider using Parthon oil (or something similar) as cryo-protectant so it will coat your crystal in the glove box and will also reduce oxidation? Good luck, Boaz Boaz Shaanan, Ph.D. Dept. of Life Sciences Ben-Gurion University of the Negev Beer-Sheva 84105 Israel E-mail: bshaa...@bgu.ac.il Phone: 972-8-647-2220 Skype: boaz.shaanan Fax: 972-8-647-2992 or 972-8-646-1710 From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of ISABET Tatiana [tatiana.isa...@synchrotron-soleil.fr] Sent: Thursday, October 02, 2014 11:22 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Question about enzyme behavior Dear all, Sorry for a non purely crystallographic question. I am working on an enzyme which binds Fe2+ cations to catalyzes an FeII-dependent hydroxylation reaction. Because of fast oxidation in presence of the enzyme, it is very difficult to soak Fe2+ ions into the crystals. We succeed only under anaerobic conditions (glove box). I use a combination of dithionite as a reducing agent and Fe2+SO4 or (NH4)2Fe(SO4)2 as Fe2+ source. Despite these precautions, the Fe2+ is most often disordered in the active site. When I add Fe2+ under aerobic conditions, Fe2+ oxidizes immediately upon contact with the protein solution (despite 1mM Dithionite for 5mM Fe2+ and protein concentration = 230uM). Furthermore, the hydroxyl donor molecule, which should bind Fe2+ (before the substrate) and one residue of the protein, is not seen in the electron-density maps in the active site. I have tried several soaking conditions. When I try a co-crystallization approach, adding Fe2+ and this hydroxyl donor molecule directly to the protein solution under anaerobic conditions, the protein precipitates. Does anybody have an idea or experience with this type of results? or how to fix the molecule to such a site? What type of phenomena could occur at the active site preventing the binding of the product? Thanks for your help Best regards Tatiana
Re: [ccp4bb] 3 letter code
On 02/10/14 11:50, Faisal Tarique wrote: I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. No. But here's how to find it yourself: Go to rcsb.org nitrophenyl phosphate - Search Top hit in Chemical Name table. or similarly File - Search Monomer Library in Coot. Paul.
Re: [ccp4bb] 3 letter code
I took the liberty of googling this for you. I trust that other search engines will give the same answer. Try your favorite next time. http://www.ebi.ac.uk/pdbe-srv/pdbechem/chemicalCompound/complete/4NP Andreas On 02/10/2014 11:50, Faisal Tarique wrote: Hello everyone I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. -- Regards Faisal School of Life Sciences JNU -- Andreas Förster Crystallization and X-ray Facility Manager Centre for Structural Biology Imperial College London
Re: [ccp4bb] 3 letter code
Thank you..i got it On Thu, Oct 2, 2014 at 5:04 PM, Andreas Förster docandr...@gmail.com wrote: I took the liberty of googling this for you. I trust that other search engines will give the same answer. Try your favorite next time. http://www.ebi.ac.uk/pdbe-srv/pdbechem/chemicalCompound/complete/4NP Andreas On 02/10/2014 11:50, Faisal Tarique wrote: Hello everyone I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. -- Regards Faisal School of Life Sciences JNU -- Andreas Förster Crystallization and X-ray Facility Manager Centre for Structural Biology Imperial College London -- Regards Faisal School of Life Sciences JNU
Re: [ccp4bb] 3 letter code
When I google 3 letter code for p nitrophenyl phosphate the second site listed is: http://www.ebi.ac.uk/pdbe-srv/pdbechem/chemicalCompound/complete/4NP Which looks like it might contain the answer you seek. HTH, Dave [image: David Briggs on about.me] David Briggs about.me/david_briggs http://about.me/david_briggs On 2 October 2014 11:50, Faisal Tarique faisaltari...@gmail.com wrote: Hello everyone I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. -- Regards Faisal School of Life Sciences JNU
Re: [ccp4bb] 3 letter code
Hi Faisal The 3letter code for p nitrophenyl phosphate would be 4NP http://www.rcsb.org/pdb/explore/explore.do?structureId=1D1Q On Thu, Oct 2, 2014 at 4:20 PM, Faisal Tarique faisaltari...@gmail.com wrote: Hello everyone I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. -- Regards Faisal School of Life Sciences JNU -- Thanks Regards, Pooja Kesari Research Scholar Department Of Biotechnology Indian Institute of Technology Roorkee INDIA
Re: [ccp4bb] 3 letter code
Hi Faisal, You can also look in LigandExpo http://ligand-expo.rcsb.org/index.html If you don't find a result immediately, you can also search by formula, even without hydrogens. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Paul Emsley Sent: Thursday, October 02, 2014 13:31 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] 3 letter code On 02/10/14 11:50, Faisal Tarique wrote: I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. No. But here's how to find it yourself: Go to rcsb.org nitrophenyl phosphate - Search Top hit in Chemical Name table. or similarly File - Search Monomer Library in Coot. Paul.
Re: [ccp4bb] Question about enzyme behavior
Dear Tatiana, Having worked also worked on various Fe(II) dependent hydroxylases, may I suggest trying some other less redox sensitive divalent cations? My old lab routinely used to screen hydroxylases with (to my knowledge) Co and Mn, which essentially inhibited enzymatic turnover, so they were also able to add peptide substrates and get structures with inhibitory metal ion, cofactor and substrate bound. I know there were also instances where purification on a Ni column resulted in pretty much irreversible binding of an Ni(II) ion in the active site, which unfortunately prevented functional characterisation as it had a higher binding affinity than the physiological cofactor Fe(II)! Also, from your description I am guessing there is a fair chance you are working with 2-oxoglutarate dependent hydroxylases? If so there are various cofactor analogues available (N-oxalylglycine among others) which prevent enzymatic turnover and may help trap your iron in the ferrous oxidation state. We often used to add ascorbate, as it prevented a phenomenon called uncoupled turnover where the Fe would end up as a Fe(IV)=O species due to a side reaction that didn't involve substrate hydroxylation. Feel free to message off-board if you want more details on any of the above. Best Regards, Tom On 2 October 2014 18:22, ISABET Tatiana tatiana.isa...@synchrotron-soleil.fr wrote: Dear all, Sorry for a non purely crystallographic question. I am working on an enzyme which binds Fe2+ cations to catalyzes an FeII-dependent hydroxylation reaction. Because of fast oxidation in presence of the enzyme, it is very difficult to soak Fe2+ ions into the crystals. We succeed only under anaerobic conditions (glove box). I use a combination of dithionite as a reducing agent and Fe2+SO4 or (NH4)2Fe(SO4)2 as Fe2+ source. Despite these precautions, the Fe2+ is most often disordered in the active site. When I add Fe2+ under aerobic conditions, Fe2+ oxidizes immediately upon contact with the protein solution (despite 1mM Dithionite for 5mM Fe2+ and protein concentration = 230uM). Furthermore, the hydroxyl donor molecule, which should bind Fe2+ (before the substrate) and one residue of the protein, is not seen in the electron-density maps in the active site. I have tried several soaking conditions. When I try a co-crystallization approach, adding Fe2+ and this hydroxyl donor molecule directly to the protein solution under anaerobic conditions, the protein precipitates. Does anybody have an idea or experience with this type of results? or how to fix the molecule to such a site? What type of phenomena could occur at the active site preventing the binding of the product? Thanks for your help Best regards Tatiana -- Skype: tom.murray.rust Twitter: tmurrayrust http://twitpic.com/photos/tmurrayrust +44 7970 480 601 (UK)
Re: [ccp4bb] Space group numbers
With the successful introduction of racemic crystallization to macromolecular, a large number of possible space groups have been opened up to this audience. You can find examples in the PDB of space groups P -1 (i.e. P 1-bar), I -4 2 d, etc. On 10/02/14 06:51, George Sheldrick wrote: The strange thing is that small molecule crystallographers do not suffer from this problem, because they don't use space group numbers! This is just as well, because instead of just 8 combinations of primitive orthorhombic space groups and settings, they have to consider 111 (if I have counted correctly). George On 10/02/2014 11:50 AM, Frank von Delft wrote: I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon -- === All Things Serve the Beam === David J. Schuller modern man in a post-modern world MacCHESS, Cornell University schul...@cornell.edu
Re: [ccp4bb] Space group numbers
Yes, we ran into exactly that issue as well. Jūrgen .. Jürgen Bosch Johns Hopkins University Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research Institute 615 North Wolfe Streetx-apple-data-detectors://4, W8708 Baltimore, MD 21205x-apple-data-detectors://5/0 Office: +1-410-614-4742tel:%2B1-410-614-4742 Lab: +1-410-614-4894tel:%2B1-410-614-4894 Fax: +1-410-955-2926tel:%2B1-410-955-2926 http://lupo.jhsph.eduhttp://lupo.jhsph.edu/ On Oct 2, 2014, at 05:38, Kay Diederichs kay.diederi...@uni-konstanz.demailto:kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.ukmailto:p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of the misleading (I'd say) ordering abc . I'm probably also harping on this because it took me so many years to discover this failure mode, and I would like to prevent others from falling into this trap. HTH, Kay The space group names are unambiguous (though also watch out for R3 R32 which are normally indexed as centred hexagonal, but could be indexed in a primitive cell) Phil On 30 Sep 2014, at 13:07, Simon Kolstoe simon.kols...@port.ac.ukmailto:simon.kols...@port.ac.uk wrote: Dear ccp4bb, Could someone either provide, or point me to, a list of space-groups relevant to protein crystallography just by space group number? I can find lots of tables that list them by crystal system, lattice etc. but no simple list of numbers. Thanks, Simon
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 11:38:08 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: How does XDS decide on eg P 21 21 2 when say c b a? The initial indexing may decide that the cell fits a primitive orthorhombic system, but I presume that it will then have some convention, probably a b c, since the identification of screws can only be done after integration, and even then may be uncertain. If e.g. Pointless later decides that the a axis is a dyad, and the b c axes are 2(1) screws, then it can assign space group P 2 21 21 without permuting the indices. If XDS is assigning space group P 21 21 2 then it must have permuted the axes from the initial indexing. It seems to me more straightforward to stick to the initial indexing rather than having to reindex after you have decided the true space group: this was Ian Tickle's point and is also supposedly the official IUCr-approved convention. XDS was written for users who read the table of H00 0K0 00L intensities and sigmas in CORRECT.LP (i.e. after integration), and know that the only pure two-fold rotation axis should be called c in space group 18, and the only two-fold screw axis should be called c in space group 17. This XDS user then has to choose the correct one out of the three possible ways to order the axes. So, XDS does not decide, the user decides. Nowadays many XDS users use POINTLESS, which is perfectly adequate, except for space groups 17 and 18 where the problem arises, unless the non-default SETTING SYMMETRY-BASED is chosen. 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. There are of course ambiguous cases e.g. a ~= b, but that is the same as the indexing ambiguities in e.g. P3, and that needs a reference dataset to resolve. There is no problem in solving a structure in e.g. P 2 21 21, and indeed I would always run MR in all 8 possible primitive orthorhombic space groups, very easy to do in Phaser 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 abc , 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. best, Kay Phil On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS
Re: [ccp4bb] 3 letter code
Thank you every one.. On Thu, Oct 2, 2014 at 5:27 PM, Robbie Joosten robbie_joos...@hotmail.com wrote: Hi Faisal, You can also look in LigandExpo http://ligand-expo.rcsb.org/index.html If you don't find a result immediately, you can also search by formula, even without hydrogens. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Paul Emsley Sent: Thursday, October 02, 2014 13:31 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] 3 letter code On 02/10/14 11:50, Faisal Tarique wrote: I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. No. But here's how to find it yourself: Go to rcsb.org nitrophenyl phosphate - Search Top hit in Chemical Name table. or similarly File - Search Monomer Library in Coot. Paul. -- Regards Faisal School of Life Sciences JNU
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com wrote: Hi, we shouldn't be using numbers at all (CCP4-style or otherwise, since no-one else outside the MX community uses these). We should be using the unique full Hermann-Mauguin symbol, since the 'standard setting' space group number in IT obviously does not uniquely define the setting, and it's the setting that matters. Note that the standard setting symbol P2221 means 'either P2122 or P2212 or P2221' according to the a=b=c convention (this is universal amongst the crystallography communities), so you still Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition) , these conventions refer to the cell obtained by the transformations from Table 9.3.1. They have been chosen for convenience in this table. To me, this indicates that abc _could_ be obtained _if_ one were to transform. But the question is: why would one want to transform? I don't see sticking to the original indexing as a convincing convenience. have to define the setting if you refer to the standard symbol. I'm aware My copy of ITC Vol A says (p 41) about Table 3.2: the 'standard' space group symbols ... are printed in bold face. The Table has P 21 21 2 (18) and P 2 2 21 (17) in bold face. There is no ambiguity here. that some software uses the list of general equivalent positions to define the space group but IMO that's overkill. If I wan't to talk about space group F432 you can't expect me to recite the list of 96 g.e.p.s! - the H-M symbol is sufficient. There are of course other cases besides P2221 where the setting is ambiguous (e.g. C2/A2/I2 and various cases of origin shifting), so using the correct symbol for the setting is critical. The most important features of any convention are a) that it's documented in an 'official' publication (i.e. not informal such as software documentation, otherwise how am I supposed to reference it?), and b) everyone subscribes to it. If you think we should be using a different convention then I want to see the proper documentation for it, with everything spelled out in excruciating detail (so it should be at least as thick as ITC!). It seems to me that ITC fulfils these requirements admirably! Switching the default in POINTLESS from SETTING CELL-BASED to SETTING SYMMETRY-BASED would make me happy, but more importantly, would avoid a lot of problems. thanks, Kay Cheers -- Ian On 2 October 2014 10:25, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the default SETTING CELL-BASED has no advantages that I can see). Or they use the good old manual way of inspecting, by eye, the systematic absences along H00 0K0 00L - this cannot fail. To me, symmetry trumps cell metric so SETTING SYMMETRY-BASED should be the default. I'm harping on this because I have recently seen how a Molecular Replacement solution was not obtained in space group 18 because of
Re: [ccp4bb] Space group numbers
I'm still a bit confused about why there is a problem: why use SG numbers? P 2 21 21 (or indeed P22121) is clear and unambiguous. There is no need to use the numbers (and certainly not the weird CCP4 numbers like 3018 which I was trying to hide in Pointless Phil On 2 Oct 2014, at 15:04, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com wrote: Hi, we shouldn't be using numbers at all (CCP4-style or otherwise, since no-one else outside the MX community uses these). We should be using the unique full Hermann-Mauguin symbol, since the 'standard setting' space group number in IT obviously does not uniquely define the setting, and it's the setting that matters. Note that the standard setting symbol P2221 means 'either P2122 or P2212 or P2221' according to the a=b=c convention (this is universal amongst the crystallography communities), so you still Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition) , these conventions refer to the cell obtained by the transformations from Table 9.3.1. They have been chosen for convenience in this table. To me, this indicates that abc _could_ be obtained _if_ one were to transform. But the question is: why would one want to transform? I don't see sticking to the original indexing as a convincing convenience. have to define the setting if you refer to the standard symbol. I'm aware My copy of ITC Vol A says (p 41) about Table 3.2: the 'standard' space group symbols ... are printed in bold face. The Table has P 21 21 2 (18) and P 2 2 21 (17) in bold face. There is no ambiguity here. that some software uses the list of general equivalent positions to define the space group but IMO that's overkill. If I wan't to talk about space group F432 you can't expect me to recite the list of 96 g.e.p.s! - the H-M symbol is sufficient. There are of course other cases besides P2221 where the setting is ambiguous (e.g. C2/A2/I2 and various cases of origin shifting), so using the correct symbol for the setting is critical. The most important features of any convention are a) that it's documented in an 'official' publication (i.e. not informal such as software documentation, otherwise how am I supposed to reference it?), and b) everyone subscribes to it. If you think we should be using a different convention then I want to see the proper documentation for it, with everything spelled out in excruciating detail (so it should be at least as thick as ITC!). It seems to me that ITC fulfils these requirements admirably! Switching the default in POINTLESS from SETTING CELL-BASED to SETTING SYMMETRY-BASED would make me happy, but more importantly, would avoid a lot of problems. thanks, Kay Cheers -- Ian On 2 October 2014 10:25, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence, XDS will use the space group 17 or 18 (which is what POINTLESS reports), but the user must provide the correct ordering (which does not necessarily mean abc) of cell parameters in XDS.INP. The easiest way, for XDS users, would be to run POINTLESS with the SETTING SYMMETRY-BASED option (I wish the latter were the default because the
[ccp4bb] 'flatten-solvent' option in 3D auto-refine
Dear Sjors, In 3D auto-refine routine, what does the flatten-solvent option does? Specifically, i'd like to know is there a mask involved and if yes, what kind of mask? Thanks for this and for your explanations in Grenoble. Isai
Re: [ccp4bb] Space group numbers
On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de 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 abc. 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 abc , 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
Re: [ccp4bb] 3 letter code
Dear ccp4bb, Another easy method to find and/or generate ligands is via the smiles code: Wikipedia has smiles codes for many compounds: http://en.wikipedia.org/wiki/Para-Nitrophenylphosphate look up the smiles code: smiles: C1=CC(=CC=C1[N+](=O)[O-])OP(=O)(O)O You can now generate the cif file with phenix.elbow $ phenix.elbow smiles=C1=CC(=CC=C1[N+](=O)[O-])OP(=O)(O)O At the PDB select -ligand and enter the smiles code. select the exact match if it exists. The smiles code will also help you search for similar molecules Enrico. On Thu, 02 Oct 2014 15:45:36 +0200, Faisal Tarique faisaltari...@gmail.com wrote: Thank you every one.. On Thu, Oct 2, 2014 at 5:27 PM, Robbie Joosten robbie_joos...@hotmail.com wrote: Hi Faisal, You can also look in LigandExpo http://ligand-expo.rcsb.org/index.html If you don't find a result immediately, you can also search by formula, even without hydrogens. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Paul Emsley Sent: Thursday, October 02, 2014 13:31 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] 3 letter code On 02/10/14 11:50, Faisal Tarique wrote: I request you to please tell me the 3 letter code for p nitrophenyl phosphate.. No. But here's how to find it yourself: Go to rcsb.org nitrophenyl phosphate - Search Top hit in Chemical Name table. or similarly File - Search Monomer Library in Coot. Paul. -- Enrico A. Stura D.Phil. (Oxon) ,Tel: 33 (0)1 69 08 4302 Office Room 19, Bat.152, Tel: 33 (0)1 69 08 9449Lab http://www-dsv.cea.fr/ibitecs/simopro/ltmb/cristallogenese LTMB, SIMOPRO, IBiTec-S, CE Saclay, 91191 Gif-sur-Yvette, FRANCE http://scholar.google.com/citations?hl=enuser=Kvm06WIoPAsCpagesize=100sortby=pubdate http://www.chem.gla.ac.uk/protein/mirror/stura/index2.html e-mail: est...@cea.fr Fax: 33 (0)1 69 08 90 71
Re: [ccp4bb] Question about enzyme behavior
Watch out with oils and oxygen. Oxygen is fairly soluble in oils. When we worked on deoxyhemerythrin, we had to degas our sealing wax to keep things anaerobic. If you heat wax, and then put it in a vacuum, it'll froth as all the gases come out of the liguid. Then of course it hardens and you have to heat and vacuum again. It took several cycles of that to degas the sealing wax for our capillaries. (That shows how long ago that was.) Ron On Thu, 2 Oct 2014, Boaz Shaanan wrote: Hi Tatiana, Your problem is most reminiscent to the problem that Max Perutz faced when he dealt with deoxy-haemoglobin crystals, but in those days only mounting in capillaries was the way to bring the crystals to the beam, so he used dithionite, just like you, but mounted the crystals in (specially made for him at LMB) glove box under Nitrogen atmosphere. I guess you're now freezing your crystals for data collection, right? I'm not sure how to do this in a glove box nor am I sure whether after freezing your crystals is protected against oxidation. Maybe. But perhaps you can also consider using Parthon oil (or something similar) as cryo-protectant so it will coat your crystal in the glove box and will also reduce oxidation? Good luck, Boaz Boaz Shaanan, Ph.D. Dept. of Life Sciences Ben-Gurion University of the Negev Beer-Sheva 84105 Israel E-mail: bshaa...@bgu.ac.il Phone: 972-8-647-2220 Skype: boaz.shaanan Fax: 972-8-647-2992 or 972-8-646-1710 From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of ISABET Tatiana [tatiana.isa...@synchrotron-soleil.fr] Sent: Thursday, October 02, 2014 11:22 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Question about enzyme behavior Dear all, Sorry for a non purely crystallographic question. I am working on an enzyme which binds Fe2+ cations to catalyzes an FeII-dependent hydroxylation reaction. Because of fast oxidation in presence of the enzyme, it is very difficult to soak Fe2+ ions into the crystals. We succeed only under anaerobic conditions (glove box). I use a combination of dithionite as a reducing agent and Fe2+SO4 or (NH4)2Fe(SO4)2 as Fe2+ source. Despite these precautions, the Fe2+ is most often disordered in the active site. When I add Fe2+ under aerobic conditions, Fe2+ oxidizes immediately upon contact with the protein solution (despite 1mM Dithionite for 5mM Fe2+ and protein concentration = 230uM). Furthermore, the hydroxyl donor molecule, which should bind Fe2+ (before the substrate) and one residue of the protein, is not seen in the electron-density maps in the active site. I have tried several soaking conditions. When I try a co-crystallization approach, adding Fe2+ and this hydroxyl donor molecule directly to the protein solution under anaerobic conditions, the protein precipitates. Does anybody have an idea or experience with this type of results? or how to fix the molecule to such a site? What type of phenomena could occur at the active site preventing the binding of the product? Thanks for your help Best regards Tatiana
Re: [ccp4bb] Space group numbers
Hi Phil, as far as I understand, you are stating a consensus (do not use numbers, do use the Hermann-Mauguin-symbols), rather than a problem. The problem seems that the artificial space group numbers 1018, etc., contained in symop.lib, do not follow the consensus and thus cause irritation. Best, Tim On 10/02/2014 04:46 PM, Phil Evans wrote: I'm still a bit confused about why there is a problem: why use SG numbers? P 2 21 21 (or indeed P22121) is clear and unambiguous. There is no need to use the numbers (and certainly not the weird CCP4 numbers like 3018 which I was trying to hide in Pointless Phil On 2 Oct 2014, at 15:04, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com wrote: Hi, we shouldn't be using numbers at all (CCP4-style or otherwise, since no-one else outside the MX community uses these). We should be using the unique full Hermann-Mauguin symbol, since the 'standard setting' space group number in IT obviously does not uniquely define the setting, and it's the setting that matters. Note that the standard setting symbol P2221 means 'either P2122 or P2212 or P2221' according to the a=b=c convention (this is universal amongst the crystallography communities), so you still Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition) , these conventions refer to the cell obtained by the transformations from Table 9.3.1. They have been chosen for convenience in this table. To me, this indicates that abc _could_ be obtained _if_ one were to transform. But the question is: why would one want to transform? I don't see sticking to the original indexing as a convincing convenience. have to define the setting if you refer to the standard symbol. I'm aware My copy of ITC Vol A says (p 41) about Table 3.2: the 'standard' space group symbols ... are printed in bold face. The Table has P 21 21 2 (18) and P 2 2 21 (17) in bold face. There is no ambiguity here. that some software uses the list of general equivalent positions to define the space group but IMO that's overkill. If I wan't to talk about space group F432 you can't expect me to recite the list of 96 g.e.p.s! - the H-M symbol is sufficient. There are of course other cases besides P2221 where the setting is ambiguous (e.g. C2/A2/I2 and various cases of origin shifting), so using the correct symbol for the setting is critical. The most important features of any convention are a) that it's documented in an 'official' publication (i.e. not informal such as software documentation, otherwise how am I supposed to reference it?), and b) everyone subscribes to it. If you think we should be using a different convention then I want to see the proper documentation for it, with everything spelled out in excruciating detail (so it should be at least as thick as ITC!). It seems to me that ITC fulfils these requirements admirably! Switching the default in POINTLESS from SETTING CELL-BASED to SETTING SYMMETRY-BASED would make me happy, but more importantly, would avoid a lot of problems. thanks, Kay Cheers -- Ian On 2 October 2014 10:25, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Be careful: the International Tables space group number may be ambiguous. For example sg number 18 may refer to P 21 21 2 or its permuted settings P 21 2 21 or P 2 21 21, if you follow the proper IUCr convention that primitive orthorhombic space groups have abc I would like to point out that there is an alternative interpretation of the International Tables (Vol A, 4th ed. 1995). In that interpretation (which e.g. XDS follows) space group 18 has the 'standard' space group symbol, P21 21 2 (bold letters in Table 3.2). This is of course not ambiguous at all; the pure 2-fold then corresponds to the c axis and there is always a permuation of axes to achieve this. As a result, the axes are not necessarily ordered such that abc . The latter ordering is just a convention which was chosen for convenience and the convention refer(s) to the cell obtained by the transformations from Table 9.3.1 (citing from table 9.3.2) - in other words, the convention is fulfilled _after_ the transformation (which of course is just order-permuting while keeping right-handedness) - nothing new here. In my understanding, CCP4 developers have (years ago) understood this convention as a condition, which lead them to invent CCP4 space group symbols 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be the reason for the default being SETTING CELL-BASED in POINTLESS. Users of XDS should be aware that by default, POINTLESS therefore permutes the axes such that abc . This however may lead to space groups 1017 / 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the POINTLESS log file (last I checked). In consequence,
Re: [ccp4bb] Space group numbers
How can it be if you're not even sure what the correct space group is? Ambiguities may arise in the presence of pseudosymmetry and/or packing disorders. In some cases, you can determine crystal structure from the same data in different space groups that do not have subgroup/supergroup relationship. One of the space groups may produce better results, something that can be determined quite late into the process. Similar situation may arise then merging data from multiple nearly isomorphous crystals that individually may be better describes by alternative space group symmetries. Zbyszek Otwinowski On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de 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 abc. 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 abc , 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
[ccp4bb] monitoring refmac refinement
I would be grateful for any advice on how to obtain refmac information equivalent in detail to the shelxl Disagreeable restraints before cycle N listing. In the later stages of refining a set of related structures, I have been alternating between shelxl and refmac. Typically this relies on shelxl for occupancy assignment of alternate conformations and associated partially occupied solvent, followed by refmac on the shelxl result to improve bulk solvent modeling. Most of the time this two step approach works well and yields an improvement in the final model. However occasionally the refmac step heads in the opposite direction: InitialFinal R factor0.1156 0.1390 R free0.1192 0.1477 Rms BondLength0.0108 0.0110 Rms BondAngle1.3876 1.8731 Rms ChirVolume0.1147 0.0979 This seems to happen rather erratically relative to changes in the model and I've been unable to determine which restraints/weights are responsible. Thanks for any pointers, Alastair Fyfe UCSC
Re: [ccp4bb] monitoring refmac refinement
Dear Alistair, Erratic behaviour is often caused by the antibumping restraints because they get switched off and on, and riding hydrogens and changes in the occupancies can affect their action. This probably applies to both programs. Any suggestions for improving the bulk solvent model in shelxl would be welcome, it is clearly inadequate. Since shelxl can now input partial structure factors using a/.fab/ file, this might be a good way of testing other solvent models. Best wishes, George On 10/02/2014 09:07 PM, Alastair Fyfe wrote: I would be grateful for any advice on how to obtain refmac information equivalent in detail to the shelxl Disagreeable restraints before cycle N listing. In the later stages of refining a set of related structures, I have been alternating between shelxl and refmac. Typically this relies on shelxl for occupancy assignment of alternate conformations and associated partially occupied solvent, followed by refmac on the shelxl result to improve bulk solvent modeling. Most of the time this two step approach works well and yields an improvement in the final model. However occasionally the refmac step heads in the opposite direction: InitialFinal R factor0.1156 0.1390 R free0.1192 0.1477 Rms BondLength0.0108 0.0110 Rms BondAngle1.3876 1.8731 Rms ChirVolume0.1147 0.0979 This seems to happen rather erratically relative to changes in the model and I've been unable to determine which restraints/weights are responsible. Thanks for any pointers, Alastair Fyfe UCSC -- 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
Re: [ccp4bb] monitoring refmac refinement
On Thursday, 02 October, 2014 12:07:54 Alastair Fyfe wrote: I would be grateful for any advice on how to obtain refmac information equivalent in detail to the shelxl Disagreeable restraints before cycle N listing. This is controlled by the MONI keyword. To get a full list on every cycle MONI MANY In the later stages of refining a set of related structures, I have been alternating between shelxl and refmac. Typically this relies on shelxl for occupancy assignment of alternate conformations and associated partially occupied solvent, followed by refmac on the shelxl result to improve bulk solvent modeling. Most of the time this two step approach works well and yields an improvement in the final model. However occasionally the refmac step heads in the opposite direction: InitialFinal R factor0.1156 0.1390 R free0.1192 0.1477 Rms BondLength0.0108 0.0110 Rms BondAngle1.3876 1.8731 Rms ChirVolume0.1147 0.0979 This seems to happen rather erratically relative to changes in the model and I've been unable to determine which restraints/weights are responsible. Thanks for any pointers, Alastair Fyfe UCSC -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 16:00:30 +0100, Ian Tickle ianj...@gmail.com wrote: On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de 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. Ian, I'm not aware that I tried to impose re-indexing on anyone, which your reaction seems to imply. Quite to the contrary: re-indexing needs to be under the control of the user - and the user specifies cell parameters and space group number in XDS.INP. If I understand correctly, your use case is not the typical one encountered by novice crystallographers, and I'm quite sure you know very well how to deal with it. My whole point is about the default SETTING in POINTLESS which may lead to problems for XDS users, for space groups 17 and 18. To fix it, there is no need to re-invent the wheel, write new volumes of ITC, specify all space group operators, or specify space group symbols instead of numbers. best, Kay 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 abc. 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 abc , 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
[ccp4bb] Aimless low resolution shell
Dear ccp4bb, I am having an issue with low resolution shell when converting unmerged data from Scalepack using Aimless. My data has a resolution of 30- 2.6 angstroms as written in the .sca file. However, when I convert it to mtz using Aimless the resolution changes automatically to 91.46 - 2.6. I was trying to manually change the resolution limits, and while the high resolution limit does change, the low resolution remains at 91.46 angstroms. When looking at my mtz file in HKLview I can see that only H,K,L and Rfree are to 91.46 angstroms. All other columns are to the requested 30 angstroms. I am wondering if it is supposed to do that or there is something I am not doing right? Thank you for your help! -- Alisa Glukhova postdoctoral fellow Tesmer lab University of Michigan
Re: [ccp4bb] Aimless low resolution shell
I would like to add that this happens only when the Ensure unique data and add R free column flag is ON. I tested this on both Linux and Mac Maverick systems. Thanks again! On Thu, Oct 2, 2014 at 8:15 PM, Alisa Glukhova alis...@umich.edu wrote: Dear ccp4bb, I am having an issue with low resolution shell when converting unmerged data from Scalepack using Aimless. My data has a resolution of 30- 2.6 angstroms as written in the .sca file. However, when I convert it to mtz using Aimless the resolution changes automatically to 91.46 - 2.6. I was trying to manually change the resolution limits, and while the high resolution limit does change, the low resolution remains at 91.46 angstroms. When looking at my mtz file in HKLview I can see that only H,K,L and Rfree are to 91.46 angstroms. All other columns are to the requested 30 angstroms. I am wondering if it is supposed to do that or there is something I am not doing right? Thank you for your help! -- Alisa Glukhova postdoctoral fellow Tesmer lab University of Michigan -- Alisa Glukhova graduate student Tesmer lab
