Re: [ccp4bb] Alternating positive and negative density
Hi Peter, my estimate of the distance between the peaks would be based on bond distances and about twice that of Dale, but I agree with his general conclusion. Either a reflection (roughly in the h 0 0 direction) is stronger than it should be (ice?), or a very strong reflection was considered as outlier and removed (in the CORRECT step). I would try two things: a) to confirm the general conclusion, I would compare the filled (electron_density_maps.map_coefficients.fill_missing_fobs=True) and the default non-filled maps from phenix.refine. The filled maps should show the problem much less. (Caveat: I have not tried this) b) inspect the outliers in XDS_ASCII.HKL with something like sort -nk5 XDS_ASCII.HKL | more looking for observations which have negative sigma (i.e. are outliers) _and_ have high intensity _and_ have |h| |k| _and_ |h| |l| . If you find any, I would simply remove the negative sign with an editor, save the modified XDS_ASCII.HKL and re-run XDSCONV, finally obtaining a MTZ file that includes this reflection. HTH, Kay On Mon, 24 Jun 2013 00:57:49 -0400, Peter Randolph ps...@virginia.edu wrote: Short version: Hi, I'm working on what should be a straightforward molecular replacement problem (already solved protein in new space group), but my Fo-Fc map contains a peculiar series of alternating positive and negative peaks of difference density. I'm wondering if anyone has anyone seen this before? Sample images are attached and more background is below. More background: I had initially solved an *apo* structure of my protein (from previous diffraction data in another crystal form), and more recently collected diffraction data for crystals of the protein co-crystallized with potential binding partners (small RNAs). All the datasets I've processed so far have the same spacegroup (P2(1)2(1)2(1)) and cell dimensions as the apo structure. I have tried two general approaches, both with the same initial steps of indexing / integrating / scaling in XDS, converting to MTZ format without R-free flags, then importing R-free-flags from the (previous) apo structure's MTZ. I would then run phenix.refine for initial rigid-body refinement using the apo-model and the new mtz to see if there were signs of any new positive density corresponding to bound ligands. While the 2Fo-Fc map fits the apo protein 3D model perfectly, the Fo-Fc map shows bands of alternating positive and negative density running throughout the structure. What's odd is that these 'bands' appear to be systematic rather than random (please see attached image), and aren't located anywhere that a binding partner could bind, leading me to suspect they may be artefactual (these bands actually run through the body of the protein, so one possibility is that the b-strands are off-register by a multiple of a peptide unit?). If I use the same mtz file and structural model, and instead do molecular replacement with phaser, I see the same issue. I've tried this workflow with a couple of datasets and using P222 as well as P2(1)2(1)2(1), and each time I see the same issue of spurious(?) bands. Any help or advice would be much appreciated, especially if anyone has seen anything like this? Thanks a lot, Peter Randolph -- Peter Randolph PhD Candidate Mura Laboratory Department of Chemistry University of Virginia (434)924.7979
Re: [ccp4bb] iMosflm bug?
This might be a problem with fonts. On my laptop the menu items use a sans serif font and that particular window is just wide enough to fit all the items. The font also looks more attractive and readable than your screenshot. I'm guessing (from your desktop background!) that you also use Ubuntu. Unfortunately I can't remember how I set fonts up on my machine, but it may help to: 1) install the ttf-mscorefonts-installer package 2) ensure the package gsfonts-x11 is *not* installed (this causes an incorrect mapping of unicode symbols so you get things like the registered trademark symbol appearing - an effect apparently known as mojibake...) Cheers -- David On 25 June 2013 03:46, Thomas Cleveland thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland
Re: [ccp4bb] iMosflm bug?
Hi As David suggests, this is certainly a problem with fonts - you're getting a large variant of Courier; the default font in iMosflm is Helvetica, and it looks like your X-display isn't finding it for some reason. You should be able to re-size the window by dragging out the bottom right hand corner of the Processing options window, even if there's no visible handle. Ubuntu has been becoming less good at having normal Linux things installed by default over the last few years - I'm sure Canonical has very good reasons for this, but it has put me off recommending it. On 25 Jun 2013, at 10:08, David Waterman wrote: This might be a problem with fonts. On my laptop the menu items use a sans serif font and that particular window is just wide enough to fit all the items. The font also looks more attractive and readable than your screenshot. I'm guessing (from your desktop background!) that you also use Ubuntu. Unfortunately I can't remember how I set fonts up on my machine, but it may help to: 1) install the ttf-mscorefonts-installer package 2) ensure the package gsfonts-x11 is *not* installed (this causes an incorrect mapping of unicode symbols so you get things like the registered trademark symbol appearing - an effect apparently known as mojibake...) Cheers -- David On 25 June 2013 03:46, Thomas Cleveland thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland Harry -- ** note change of address ** Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] Refinement against frames
Dear Boaz, Indeed, small molecule crystallographers are routinely converting pixels into I's and can refine structures to very low R-values, but only to a limited resolution. The Bragg intensities are very strong, and background scattering stays almost unnoticed. Once they start studying accurate electron densities the flaws in the models (Icalc) become apparent. However, protein crystals are different: they have large disordered solvent regions, disorder in the proteins conformations, and background scattering of the mother liquor/air/crystal mount that may be even stronger than the many weak intensities. The disorder of the protein will lead to incoherent scattering that also produces significant background scattering, which at moderate B-factors may make up half of the total scattering. Converting pixel intensities into I_bragg (after subtracting some background) and refining against those (or F's) is clearly a simplification, and only gives us the average structure and not the true structure. The disorder may also lead to more structured non-Bragg scattering, which we call diffuse scattering, indicating that our crystal is in fact not periodic. Understanding what is really going on in our crystal, and trying to model the observed raw diffraction patterns is in fact very interesting, may solve the problems of trying to convert I's to F's, may give a better estimate of the 'average' structures and tell us how the protein molecules are really behaving (in the crystal). Trying to model diffraction images comes with lots of additional problems, because instrumental characteristics have also to be modeled. However, it is a very interesting route to go. There may be a moment in future where we think we can do this. It would be good if than we would have raw images available of all those weirdly diffracting crystals, that we managed in some way or another to extract I_bragg (or Ispot-Iback) from. Greetings, Loes. On 06/24/13 14:21, Boaz Shaanan wrote: Hi Tim, I agree with you. Another point to remember about this issue of pixel-F's (or I's) conversion is that small molecule crystallographers take the same route and produce structures with 1-2% R-factors, so this conversion is hardly our problem. The main culprit in the issues that have been discussed so lucidly on the BB recently have mostly to do with the vast amount of weak reflections in diffraction patterns of macromolecules (and how to decide on resolution in such situations). Digging into the peak/background pixels and signal/noise ratio there is just going to open another Pandora box. My 2p thoughts. Cheers, 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 Tim Gruene [t...@shelx.uni-ac.gwdg.de] Sent: Monday, June 24, 2013 2:59 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Refinement against frames -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear John, actually I am not a friend of this idea. Processing software make an excellent job of removing the instrumental part from our data. If we start to integrate against frames, the next structural title might be something like Crystal structure of ABC a xA resolution measured at beamline xyz with a frame width of f degrees and a total rotation range of phi degreees... the point I am trying to make: once integrating against frames one may have to take a lot of issues into account for interpreting the structure. And do you think that refining against frames will actually give greater chemical or biological insight into the sample, or will it only give a more accurate description of the crystal contents? These are two different things and the latter is - in my opinion - not what structures are about. Best, Tim P.S.: I changed the subject line, because the thread based sorting of my emails is soon going to exceed the width of my screem for the original one. On 06/24/2013 08:13 AM, Jrh wrote: Dear Tom, I find this suggestion of using the full images an excellent and visionary one. So, how to implement it? We are part way along the path with James Holton's reverse Mosflm. The computer memory challenge could be ameliorated by simple pixel averaging at least initially. The diffuse scattering would be the ultimate gold at the end of the rainbow. Peter Moore's new book, inter alia, carries many splendid insights into the diffuse scattering in our diffraction patterns. Fullprof analyses have become a firm trend in other fields, admittedly with simpler computing overheads. Greetings, John Prof John R Helliwell DSc FInstP On 21 Jun 2013, at 23:16, Terwilliger, Thomas C terwilli...@lanl.gov wrote: I hope I am not duplicating too much of this fascinating
[ccp4bb] Job opportunity in Drug Discovery, Glasgow, UK
The Beatson Institute for Cancer Research Drug Discovery Programme Glasgow UK Scientist, Protein Crystallography Competitive Benefits Package The Beatson Drug Discovery Programme is an industry standard unit at the cutting edge of drug discovery. Exploiting the basic biology strengths within the Beatson Institute and wider Cancer Research UK network, the programme targets some of the most exciting and challenging cancer targets. Central to our strategy is Fragment-Based Drug Discovery methods and we use NMR and Surface Plasmon Resonance as primary tools for fragment-based hit identification. In addition, we also use X-Ray crystallography as a key component of our Structure-Based Drug Design approach towards discovering novel drug molecules. We are seeking a highly motivated and talented scientist who will participate in crystallisation and x-ray structure solution of key protein targets. You will be a protein crystallographer with some experience who may have recently completed a productive Ph.D. in structural biology. Experience in automated crystallisation methods, synchrotron data collection and the solving of small molecule-protein complex structures would be an advantage. The successful candidate will have a creative approach to problem solving, good interpersonal skills and be comfortable working in a dynamic environment. In return, you will receive a competitive benefits package commensurate with your skills and experience and find at the Beatson, an inspiring, supportive and creative atmosphere where your contribution really will make a difference. Applications with covering letter, CV and names of three referees should be sent to: Dr Christopher H Gray, Drug Discovery Programme, The Beatson Institute for Cancer Research, Garscube Estate, Switchback Road, Bearsden, Glasgow, G61 1BD or by email to c.g...@beatson.gla.ac.uk Closing date for applications is August 2nd, 2013.
Re: [ccp4bb] Refinement against frames
Dear Loes, Thanks for the message. To the best of my recollection (I actually come from small molecules crystallography) the problems of small molecule crystallographers when it comes to studying accurate e.d.'s (e.g. bond densities and such) have mostly to do with separating the effect of atomic thermal motion and true residual bond densities, i.e. mostly issues of modelling the thermal motion. TDS is a pain for small molecule crystallography and protein crystallographers. It's reminiscent of the British weather - everybody complains about it but nobody does anything about it. Do small molecule crystallographers model TDS properly and correct the data for it nowadays in studies of accurate e.d.? Modelling the thermal motion in proteins by B-factors is known to be a gross over-simplification because of many reasons, some of which you mentioned. TDS is another issue. There have been attempts in the past by several groups to deal with TDS in protein crystals but I'm not sure the community was convinced that it lead to improvement of the data. Whether TDS is the main culprit for the relatively high R factor of protein structures (that is relative to small molecules) is not clear. Modelling TDS (both the parts that arise from protein dynamics and crystal disorder) in protein data, in order to improve our data and the resulting atomic models is a good thing. Why should that logically lead to refinement against frames once the TDS has been modelled properly and the data corrected accordingly (future tense should be used here, actually), is not clear to me. I would think that working on one (or a few) data sets that suffer from severe TDS, correcting the data, and re-refining the models to see what difference it makes would be a good starting point. Cheers, 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 Loes Kroon-Batenburg [l.m.j.kroon-batenb...@uu.nl] Sent: Tuesday, June 25, 2013 1:09 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Refinement against frames Dear Boaz, Indeed, small molecule crystallographers are routinely converting pixels into I's and can refine structures to very low R-values, but only to a limited resolution. The Bragg intensities are very strong, and background scattering stays almost unnoticed. Once they start studying accurate electron densities the flaws in the models (Icalc) become apparent. However, protein crystals are different: they have large disordered solvent regions, disorder in the proteins conformations, and background scattering of the mother liquor/air/crystal mount that may be even stronger than the many weak intensities. The disorder of the protein will lead to incoherent scattering that also produces significant background scattering, which at moderate B-factors may make up half of the total scattering. Converting pixel intensities into I_bragg (after subtracting some background) and refining against those (or F's) is clearly a simplification, and only gives us the average structure and not the true structure. The disorder may also lead to more structured non-Bragg scattering, which we call diffuse scattering, indicating that our crystal is in fact not periodic. Understanding what is really going on in our crystal, and trying to model the observed raw diffraction patterns is in fact very interesting, may solve the problems of trying to convert I's to F's, may give a better estimate of the 'average' structures and tell us how the protein molecules are really behaving (in the crystal). Trying to model diffraction images comes with lots of additional problems, because instrumental characteristics have also to be modeled. However, it is a very interesting route to go. There may be a moment in future where we think we can do this. It would be good if than we would have raw images available of all those weirdly diffracting crystals, that we managed in some way or another to extract I_bragg (or Ispot-Iback) from. Greetings, Loes. On 06/24/13 14:21, Boaz Shaanan wrote: Hi Tim, I agree with you. Another point to remember about this issue of pixel-F's (or I's) conversion is that small molecule crystallographers take the same route and produce structures with 1-2% R-factors, so this conversion is hardly our problem. The main culprit in the issues that have been discussed so lucidly on the BB recently have mostly to do with the vast amount of weak reflections in diffraction patterns of macromolecules (and how to decide on resolution in such situations). Digging into the peak/background pixels and signal/noise ratio there is just going to open another Pandora box. My 2p thoughts. Cheers, Boaz
Re: [ccp4bb] iMosflm bug?
Hi, I have seen this before. I would also check the screen resolution (size) used by the terminal to launch the program matches the largest size capable by your monitor. You can check and change this with the xrandr command. Type man xrandr for info. Cheers, Reginald McNulty On Jun 25, 2013, at 2:35 AM, Harry Powell ha...@mrc-lmb.cam.ac.uk wrote: Hi As David suggests, this is certainly a problem with fonts - you're getting a large variant of Courier; the default font in iMosflm is Helvetica, and it looks like your X-display isn't finding it for some reason. You should be able to re-size the window by dragging out the bottom right hand corner of the Processing options window, even if there's no visible handle. Ubuntu has been becoming less good at having normal Linux things installed by default over the last few years - I'm sure Canonical has very good reasons for this, but it has put me off recommending it. On 25 Jun 2013, at 10:08, David Waterman wrote: This might be a problem with fonts. On my laptop the menu items use a sans serif font and that particular window is just wide enough to fit all the items. The font also looks more attractive and readable than your screenshot. I'm guessing (from your desktop background!) that you also use Ubuntu. Unfortunately I can't remember how I set fonts up on my machine, but it may help to: 1) install the ttf-mscorefonts-installer package 2) ensure the package gsfonts-x11 is *not* installed (this causes an incorrect mapping of unicode symbols so you get things like the registered trademark symbol appearing - an effect apparently known as mojibake...) Cheers -- David On 25 June 2013 03:46, Thomas Cleveland thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland Harry -- ** note change of address ** Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] Refinement against frames
Dear Boaz, Dear Boaz, On 06/25/13 14:09, Boaz Shaanan wrote: Dear Loes, Thanks for the message. To the best of my recollection (I actually come from small molecules crystallography) the problems of small molecule crystallographers when it comes to studying accurate e.d.'s (e.g. bond densities and such) have mostly to do with separating the effect of atomic thermal motion and true residual bond densities, i.e. mostly issues of modelling the thermal motion. TDS is a pain for small molecule crystallography and protein crystallographers. It's reminiscent of the British weather - everybody complains about it but nobody does anything about it. Do small molecule crystallographers model TDS properly and correct the data for it nowadays in studies of accurate e.d. I agree that in small molecule crystallography thermal motion has to be modelled accurately, certainly for accurate electron density studies. The thermal motion leads to TDS, and can be found at /near Bragg positions. This is mostly ignored. Modelling the thermal motion in proteins by B-factors is known to be a gross over-simplification because of many reasons, some of which you mentioned. TDS is another issue. There have been attempts in the past by several groups to deal with TDS in protein crystals but I'm not sure the community was convinced that it lead to improvement of the data. Whether TDS is the main culprit for the relatively high R factor of protein structures (that is relative to small molecules) is not clear. Modelling TDS (both the parts that arise from protein dynamics and crystal disorder) in protein data, in order to improve our data and the resulting atomic models is a good thing. In proteins also TDS occurs but more importantly large (correlated) domain motions lead to scattering in between Bragg peaks, in the shape of large diffuse clouds or streaks or whatever. Why should that logically lead to refinement against frames once the TDS has been modelled properly and the data corrected accordingly (future tense should be used here, actually), is not clear to me. I would think that working on one (or a few) data sets that suffer from severe TDS, correcting the data, and re-refining the models to see what difference it makes would be a good starting point. The fact that these can be observed tells us that proteins crystals show much more dynamics (frozen in as static disorder) than we tend to assume. And thus our description of protein structures is simplified. Best wishes, Loes. Cheers, 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 Loes Kroon-Batenburg [l.m.j.kroon-batenb...@uu.nl] Sent: Tuesday, June 25, 2013 1:09 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Refinement against frames Dear Boaz, Indeed, small molecule crystallographers are routinely converting pixels into I's and can refine structures to very low R-values, but only to a limited resolution. The Bragg intensities are very strong, and background scattering stays almost unnoticed. Once they start studying accurate electron densities the flaws in the models (Icalc) become apparent. However, protein crystals are different: they have large disordered solvent regions, disorder in the proteins conformations, and background scattering of the mother liquor/air/crystal mount that may be even stronger than the many weak intensities. The disorder of the protein will lead to incoherent scattering that also produces significant background scattering, which at moderate B-factors may make up half of the total scattering. Converting pixel intensities into I_bragg (after subtracting some background) and refining against those (or F's) is clearly a simplification, and only gives us the average structure and not the true structure. The disorder may also lead to more structured non-Bragg scattering, which we call diffuse scattering, indicating that our crystal is in fact not periodic. Understanding what is really going on in our crystal, and trying to model the observed raw diffraction patterns is in fact very interesting, may solve the problems of trying to convert I's to F's, may give a better estimate of the 'average' structures and tell us how the protein molecules are really behaving (in the crystal). Trying to model diffraction images comes with lots of additional problems, because instrumental characteristics have also to be modeled. However, it is a very interesting route to go. There may be a moment in future where we think we can do this. It would be good if than we would have raw images available of all those weirdly diffracting crystals, that we managed in some way or another to extract I_bragg (or Ispot-Iback) from. Greetings,
Re: [ccp4bb] Alternating positive and negative density
that should have been sort -gk5 XDS_ASCII.HKL | more (I should have tested before posting!) best, Kay On Tue, 25 Jun 2013 09:16:52 +0100, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: ... b) inspect the outliers in XDS_ASCII.HKL with something like sort -nk5 XDS_ASCII.HKL | more looking for observations which have negative sigma (i.e. are outliers) _and_ have high intensity _and_ have |h| |k| _and_ |h| |l| . If you find any, I would simply remove the negative sign with an editor, save the modified XDS_ASCII.HKL and re-run XDSCONV, finally obtaining a MTZ file that includes this reflection.
Re: [ccp4bb] iMosflm bug?
Hi everyone, Thanks for all your responses. I will try working on the fonts when I get back to my computer and report back when I find a working solution. I'm using a fresh installation of Ubuntu 13.04 amd64, so hopefully it will be relevant to other users of newer Ubuntu releases. Harry, I could drag the lower right corner to make the window *smaller*, but it would not let me make it any bigger. Reginald, I'll take a look at that. Thanks, Thomas On Mon, Jun 24, 2013 at 10:46 PM, Thomas Cleveland thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland
Re: [ccp4bb] High Rwork/Rfree values
Hi, Phil, Sorry for the confusion. I did use MR solution/data combination to run Refmac and I did reindex the data and re-run MR with the reindexed MTZ file and run refmac. Both gave the above given high Rwork/Rfree values (0.35/0.41). If I refine the original MTZ native data file with the PDB file Phaser wrote, the R values are extremely high (0.50/0.52). Thank you for these points you made. 1. throw the thing at Arp/wArp and look hard at the maps you get out. The structure might have changed more than you thought. “Arp/wArp generated structure has too many dummy atoms with GLY chains and it’s hard to interpret the map”. 2. rescale the data in P1 and put it into Pointless and/or Xtriage to check for twinning and point group assignment “It gave P22121 as Phaser solution pointed. No twinning is suspected.” 3. I'm fairly sure that the (72.6, 78.0, 112.5) and (66.5, 70.5, 137.0) cells are unrelated but #2 will show that. 4. If all else fails solve it in P1 and find the space group by inspection afterwards I put the rescaled P1 data and ensemble model (P212121 glycosylated solution) to Phaser, I haven’t seen any distinctive solution. I start to suspect the P22121 solution is wrong. I have three domains in the structure, maybe the domain is swapped? Maybe I should start to grow better quality crystals in order to solve it. Thank you. Haiying On Mon, Jun 24, 2013 at 9:23 AM, Phil Jeffrey pjeff...@princeton.eduwrote: Haiying, As far as I can tell you've got a successful solution in molecular replacement via Phaser and then gone and refined it in the wrong space group. Based on what you've told us: you took your initial data in primitive orthorhombic and solved for the structure in Phaser while sampling all possible space groups. Phaser is telling you that your *original* data indexing is truly space group P22(1)2(1) and if you take that m.r. solution/data combination and simple *assign* the space group it should work in Refmac. In fact Phaser should have written the correct space group in the PDB file header. If you refine your original MTZ native data file with the PDB file Phaser wrote, what do you get ? You seem to have reindexed the data but not rotated the model (or re-run molecular replacement). That makes the model and data out-of-sync. Phaser does not reindex the data internally, and that's why it tries eight space groups in primitive orthorhombic rather than just the minimal set P222, P222(1), P2(1)2(1)2, P2(1)2(1)2(1). The others that it tries are alternative settings of these space groups (where appropriate). If you want to refine in P2(1)2(1)2 then reindex the data (h,k,l) - (k,l,h) and re-run molecular replacement with the reindexed MTZ file. If the above is a misinterpretation of what you wrote, my alternative advice on this is: 1. throw the thing at Arp/wArp and look hard at the maps you get out. The structure might have changed more than you thought. 2. rescale the data in P1 and put it into Pointless and/or Xtriage to check for twinning and point group assignment 3. I'm fairly sure that the (72.6, 78.0, 112.5) and (66.5, 70.5, 137.0) cells are unrelated but #2 will show that. 4. If all else fails solve it in P1 and find the space group by inspection afterwards Phil Jeffrey Princeton -- Haiying Bie, Ph.D. Postdoc Fellow at Michael James lab 4-29 Medical Science Building Department of Biochemistry University of Alberta, Edmonton, T6G 2H7
[ccp4bb] post-doc position @ Portugal on drug-design
The Associate Laboratory REQUIMTE-CQFB, from Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa (https://www.fct.unl.pt/en) is opening a post-doc position to integrate a multidisciplinary team in Structural Biology. The applicant must have a PhD in biochemistry, biology or related fields and preference will be given to demonstrated experience in protein crystallography and small molecules crystallography. Contract: Initial duration is 3 months, renewable for additional 12 months, with starting date predicted for 1st of September of 2013. Monthly Stipend: According to the amounts stipulated by FCT (www.fct.pt) for Research Grants in Portugal - 1495,00€ Job description: The main purpose of the work is to structurally characterize at the molecular level the interaction of plasma proteins (human serum albumin and human transferrin) with potential drugs (CORMs). These are CO releasing molecules that have demonstrated therapeutic effects in several models of disease (inflammation, apoptosis, cell proliferation, among others) (Santos-Silva, JACS 2011, Curr Med Chem 2011; Santos, J Inorg Biochem 2012; Seixas, Dalton Trans. 2012). Biochemical and crystallographic studies, in combination with theoretical calculations, will be performed, in the Protein Crystallography lab of the Chemistry Department from Faculdade de Ciências e Tecnologia of Universidade Nova de Lisboa (Lisbon-Caparica, Portugal) under the supervision of Doctor Teresa Santos Silva and Prof. Maria João Romão ( http://xtal.dq.fct.unl.pt). The work is part of an on-going collaboration with Prof. Carlos Romão from ITQB-UNL(Oeiras, Portugal) (www.itqb.unl.pt), and the Pharmaceutical company Alfama. Deadline for application: 15 July 2013 Applications should include: motivation letter, Curriculum Vitae, names and emails of 2 possible referees, copy of the degree certificate as well as other documents considered to be relevant, and sent to Dr Teresa Santos-Silva, t...@fct.unl.pt. Please go to the following website to find about further details on this application and project: http://www.eracareers.pt/opportunities/index.aspx?task=globaljobId=37399 Applications must be sent to t...@fct.unl.pt
Re: [ccp4bb] iMosflm bug?
This may no longer apply to the current version, but in older versions of imosflm and mosflm, I needed to install some xfonts to get the windows to display text properly. These xfonts are also required for ccp4i to fit the fonts properly into the windows unless you like tweaking the install. In any event, these fonts will probably not harm anything. The microsoft fonts may also be desirable. sudo apt-get install ttf-mscorefonts-installer # installs microsoft fonts sudo apt-get install xfs xfstt xfonts-75dpi xfonts-100dpi # installs xfonts and xfont server Cheers, ___ Roger S. Rowlett Gordon Dorothy Kline Professor Department of Chemistry Colgate University 13 Oak Drive Hamilton, NY 13346 tel: (315)-228-7245 ofc: (315)-228-7395 fax: (315)-228-7935 email: rrowl...@colgate.edu On 6/25/2013 8:58 AM, Reginald McNulty wrote: Hi, I have seen this before. I would also check the screen resolution (size) used by the terminal to launch the program matches the largest size capable by your monitor. You can check and change this with the xrandr command. Type man xrandr for info. Cheers, Reginald McNulty On Jun 25, 2013, at 2:35 AM, Harry Powell ha...@mrc-lmb.cam.ac.uk mailto:ha...@mrc-lmb.cam.ac.uk wrote: Hi As David suggests, this is certainly a problem with fonts - you're getting a large variant of Courier; the default font in iMosflm is Helvetica, and it looks like your X-display isn't finding it for some reason. You should be able to re-size the window by dragging out the bottom right hand corner of the Processing options window, even if there's no visible handle. Ubuntu has been becoming less good at having normal Linux things installed by default over the last few years - I'm sure Canonical has very good reasons for this, but it has put me off recommending it. On 25 Jun 2013, at 10:08, David Waterman wrote: This might be a problem with fonts. On my laptop the menu items use a sans serif font and that particular window is just wide enough to fit all the items. The font also looks more attractive and readable than your screenshot. I'm guessing (from your desktop background!) that you also use Ubuntu. Unfortunately I can't remember how I set fonts up on my machine, but it may help to: 1) install the ttf-mscorefonts-installer package 2) ensure the package gsfonts-x11 is *not* installed (this causes an incorrect mapping of unicode symbols so you get things like the registered trademark symbol appearing - an effect apparently known as mojibake...) Cheers -- David On 25 June 2013 03:46, Thomas Cleveland thomas.clevel...@gmail.com mailto:thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland Harry -- ** note change of address ** Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] str solving problem
Dear Eugene plz find the merging statics over this link https://www.dropbox.com/sh/3155bp0c8axo7tx/0P1RWTTD8z?n=21758536 I have tried different subset of images for indexing, only cell edges are changing very marginal ( 1 ) but no change in space group. Dear Manfred I have collected my data over mar345 detector, not present in detector type dropdown, how can I add. regards and thanks to all pramod On Mon, Jun 24, 2013 at 10:31 PM, Eugene Valkov eugene.val...@gmail.comwrote: Hi Pramod, Can you post your merging statistics in different space groups, not just log files from scaling? These are summarised nicely by Scala or Aimless. Also, have you tried indexing from different subsets of images? Perhaps there is a substantial contribution from a 'satellite' crystal in one orientation or crystal will be less split? I've had cases where I could not index properly if I had just used 0 and 90, but when I tried different subsets of images it worked. This is very easy to do in iMosflm. Andrew Leslie or other Mosflm developers, if they are reading this, might well be interested in looking at your images as they are currently interested in these kinds of problems with multiple lattices (see *Acta Cryst.* (2013). D*69*, 1195-1203) Eugene On 21 June 2013 21:58, Pramod Kumar pramod...@gmail.com wrote: Dear ... Francis Last I remember, HKL2000 bases its indexing on the 'strongest' spots on an image (though you could manually select spots). It could result in a misindex if the strongest spots come from separate lattices.. I have used both HKL2000 and mosflm giving the same results (although I have used manual selection of spots as a trial but results are identical). Try a program that uses all spots for indexing, across all images (XDS for example) and you might get the true space group.. I have given several efforts to the XDS but its giving error data image of particular no. does not exist (initially it was saying 11th image than i change image range then it says 21st and so on) *kindly check my data collection profile and XDS.INP* file in attachment' Or if the crystal is big enough, you could try shooting it in different areas and 'searching' for a better spot to collect data. Or 'grow a better crystal'. raising the crystals and struggle is on the peak... Dear Eugene plz find the attached scale log file, scaling table of mosflm When you index spots in Mosflm, do your predictions agree with the spots? plz see the snapshot of predicted spots.. Dear Eleanor Yes both the molecule are visible in the ASU. Dear Pozharski Balbes pipeline hitting extremely high marks when fed into Phaser while being complete nonsense (it's a 150kDa multi-domain protein and resulting domain arrangement made absolutely no sense). Refinement was stuck with high R-values and I sadly gave up on it for now. I suspected that refmac step included in the pipeline artificially shifts the model so that it conforms to Patterson map better, which results in high score in Phaser. My domain arrangement is as expected, two molecules in ASU. thanks and regards pramod On Thu, Jun 20, 2013 at 3:50 PM, Eleanor Dodson eleanor.dod...@york.ac.uk wrote: As others say - the Rfactors look pretty good for MR, mine usually start over 50% even with a better model and one hopes they then decrease.. But you say you took the Balbes model into phaser? and I think Balbes automatically runs cycles of refinement so any comment on R factors may not mean much. Have you found both molecules in the asymmetric unit? You only give LLG for one? Eleanor On 19 June 2013 17:44, Eugene Valkov eugene.val...@gmail.com wrote: Yes, I would agree with Francis that diffraction shows contribution from several lattices, which could lead to misindexing. However, it should be feasible to get a model that refines from this sort of data. Pramod - could you please post your data processing statistics from your scaling program? Better if you have several for different spacegroups. Also, I have no idea how HKL200 does this, but could you please provide an indexing solution table from Mosflm that shows penalties associated with each type of space group? Was there a sharp penalty drop at some point or was it more gradual? When you index spots in Mosflm, do your predictions agree with the spots? Or is there a substantial portion that are missed? I would consider altering thresholds in Mosflm for indexing (see the manual). Eugene On 19 June 2013 17:34, Francis E. Reyes francis.re...@colorado.eduwrote: On Jun 17, 2013, at 12:36 PM, Pramod Kumar pramod...@gmail.com wrote: I have a crystal data diffracted around 2.9 A*, during the data reduction HKL2000 not convincingly showed the space group (indexed in lower symmetry p1), while the mosflm given C-centered Orthorhombic, and again with little play around HKL2000 given CO no ice ring is appeared,
[ccp4bb] insertion code problem
Dear group, I have a insertion code question. I used molecular replacement (CCP4, autoMR) to solve two structures: one is monomer, and another one is tetramer. The model I used is one chain of a dimer and the model has insertion code. After molecular replacement and refinement using refmac5 in CCP4, the new structures lost the insertion code, and the residues were numbered consecutively. Can anyone tell me how to keep the insertion code in the new structures? Thank you, Rain
[ccp4bb] Rfree is 20%,why still green and red density?
Hi everyone, I now meet some problems when trying to solve structure.Space group is P6422, and Mathews function shows there are 4 molecules in one asymmetry unit. However, Phenix-autobuild shows only 2 molecules in on one asymmetry unit, after refinement, Rfree=20%,(resolution is 2.8A). Although AA fit the map well, there are still some green and red density. I wonder if anyone met this problem before? Any suggestion is welcome. Best, Jiang Yan
Re: [ccp4bb] iMosflm bug? - SOLVED
Hi everyone, Thanks again for the help. As several people suggested, it seems to have been a fonts package that was needed. I'm not sure if there is a single particular package that would have solved the problem, but I installed the following combination: t1-xfree86-nonfree ttf-xfree86-nonfree ttf-xfree86-nonfree-syriac xfonts-75dpi xfonts-100dpi xfs xfstt (ttf-mscorefonts-installer was already installed by default) Everything is working fine now. Thanks again. -Thomas On Tue, Jun 25, 2013 at 10:23 AM, Thomas Cleveland thomas.clevel...@gmail.com wrote: Hi everyone, Thanks for all your responses. I will try working on the fonts when I get back to my computer and report back when I find a working solution. I'm using a fresh installation of Ubuntu 13.04 amd64, so hopefully it will be relevant to other users of newer Ubuntu releases. Harry, I could drag the lower right corner to make the window *smaller*, but it would not let me make it any bigger. Reginald, I'll take a look at that. Thanks, Thomas On Mon, Jun 24, 2013 at 10:46 PM, Thomas Cleveland thomas.clevel...@gmail.com wrote: Has anyone else encountered this? When I go to processing options in iMosflm 1.0.7, many of the parameters on the right hand side of the window are cut off, and there is no way to scroll over so that I can enter them. I've attached link to a picture of what it looks like. https://www.dropbox.com/s/muwblcgohhxu94c/iMosflm-cut-off.png Thanks, Thomas Cleveland
