Re: [ccp4bb] Fwd: Re: [ccp4bb] reference for true multiplicity?
meant to know this but I'm blanking, so I'll crowdsource instead: Anybody know a (the) reference where it was showed that the best SAD data is obtained by collecting multiple revolutions at different crystal offsets (kappa settings)? It's axiomatic now (I hope!), but I remember seeing someone actually show this. I thought Sheldrick early tweens, but PubMed is not being useful. (Oh dear, this will unleash references from the 60s, won't it.) phx -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742 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] 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] iMosflm bug? - SOLVED
Hi I've just installed a Plain vanilla copy of Ubuntu 13.0.4 (aka rastafarian reefer or somesuch) with iMosflm 1.0.7 and CCP4 6.3.0 and found that Roger's suggestions were all that was needed (but I did log out and in again to use them) - 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 Curiously, although Thomas found that the mscorefonts were installed by default, they weren't on my system. For those of you with time to spare, the Unity desktop that comes with Ubuntu is interesting and may reward further investigation... On 26 Jun 2013, at Wed26 Jun 06:21, Thomas Cleveland wrote: 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 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] Where to cut the data in this medium resolution dataset
Hi I'd agree with Kay here - since the edge of the detector is at ~2.8Å. It is almost always worthwhile integrating to a higher resolution than you can see spots on the images - for what I would call normal datasets, I would always integrate to ~0.2Å higher (as a first estimate), then after examining scaling statistics (e.g. correlation coefficients!) decide if you can actually integrate even higher. For modern extra fine phi slicing, it's usually worthwhile integrating to an even higher resolution before making any decisions about the true resolution, especially if you have non-negligible background on the images. There are a couple of issues with integrating to *much* higher resolution than you actually have - one is due to the crystal detector refinements becoming less stable if you include too many reflections with insignificant !/sig(I) - i.e. refining against noise, and the other is in optimising the profiles measurement boxes (again, using noise to determine these will not lead to optimal values). BTW, unless you have a *really* good reason for scaling with SCALA, I would seriously consider updating your CCP4 installation and using Aimless instead. Phil Evans is no longer developing SCALA, and doesn't seem to have updated the SCALA release notes since 2010, so I suspect that any newer versions (most recent is 3.3.21) only contain minor bug fixes (but I could be wrong). On 23 Jul 2013, at 08:11, Kay Diederichs wrote: Hi Stefan, you write The diffraction pattern looks great, the 3.4A reflections are visible by eye and the edge of the detector is about 2.8A. and for the 3.4A data Mean((I)/sd(I)) in the highest shell is 2.3 . I'm tempted to ask: what prevents you from using higher resolution data to, say, 3.2 or 3.0 A - what do you gain by throwing reflections away? Using higher resolution _will_ reduce overfitting, and should improve the model. In the presence of NCS, Rfree will be biased towards Rwork. In your case of high-order NCS, you might consider choosing the free reflections in thin shells in reciprocal space. HTH, Kay The diffraction pattern looks great, the 3.4A reflections are visible by eye and the edge of the detector is about 2.8A. The crystals were 10x20x50 um in size and spacegroup is P6522. 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] Error running Pointless in CCP4-6.3 OSX (10.8)
Hi I noticed last week that, although the CCP4 updater for OSX requires 64-bit (see CCP4 discussions passim), all the executables are 32-bit (or at least in my current copy, updated a few weeks ago). So there is an inconsistency - no doubt this will be sorted out shortly. If you want a 64-bit build of Pointless for OSX then see Phil Evans' ftp site - ftp://ftp.mrc-lmb.cam.ac.uk/pub/pre Use the most recent version - it may solve your problem. On 12 Aug 2013, at 03:28, Bosch, Juergen wrote: Hi Sheena, simple quickfix to your problem: a) Run CAD and limit the output resolution on that mtz file so you don't run into the memory allocation error of pointless. b) try phenix.xtriage also if it is not a CCP4 program 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 Street, W8708 Baltimore, MD 21205 Office: +1-410-614-4742 Lab: +1-410-614-4894 Fax: +1-410-955-2926 http://lupo.jhsph.edu On Aug 11, 2013, at 9:54 PM, Sheena McGowan (Med) wrote: Dear all We have been trying to run pointless on a large mtz file which seems to be allocating more than 1.5Gb of memory resulting in the following error: The program run with command: /Applications/ccp4-6.3.0/bin/pointless has failed with error message pointless(507) malloc: *** mmap(size=1577435136) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug We are using OSX 10.8.4 and believe that we need a 64bit version of pointless. Looking at the pre release ftp site, we found the latest versions of pointless compiled for OSX 10.8, however they do not run. dyld: Symbol not found: __ZNSt11range_errorD1Ev Referenced from: /Applications/ccp4-6.3.0/bin/pointless-1.8.7.osx10.8 Expected in: /usr/lib/libstdc++.6.dylib in /Applications/ccp4-6.3.0/bin/pointless-1.8.7.osx10.8 Any help would be greatly appreciated (and any know if there is a upcoming release of a pre-compiled CCP4 OSX-64bit??) Regards Sheena SHEENA McGOWAN | ARC Future Fellow Department of Biochemistry and Molecular Biology MONASH UNIVERSITY Rm 243, Building 77, Wellington Rd, Clayton Victoria, AUSTRALIA 3800 T + 61 3 9902 9309 | F + 61 3 9902 9500 E sheena.mcgo...@monash.edu | Skype s.mcgowan W http://www.med.monash.edu.au/biochem/staff/mcgowan.html Australian Society for Biochemistry and Molecular Biology (State Representative) http://www.asbmb.org.au/ 39th Lorne Conference for Protein Structure and Function http://www.lorneproteins.org February 9-13, 2014. Mantra Lorne, Lorne, AUSTRALIA 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] Data processing - twinned xtals
Hi Mahesh In addition to what Mark and Juergen have written, it looks to me like you have very high mosaicity in one direction - the first image shows no distinct lunes; I suspect that may have something to do with the failure to process - but what do you mean when you say you cannot process it? Was the failure at the indexing or integration stage? If the failure is at the indexing stage, it's possible that you may make some progress in indexing if you increase the I/sig(I) threshold in Mosflm processing. Looking closely at some of the spots in the first image it does look like you have more than one lattice there, though I'm not sure I'd describe it as twinning. On 16 Aug 2013, at 15:38, Mahesh Lingaraju wrote: Hi CCP4 folks I have a data set which is looks twinned ( see the image-1 - I zoomed on to the image so that one can spot the twinning. Furthermore, the spots are very smeary from ~ 30 - 120 degrees of data collection, see image 2) I tried using HKL2000 and mosflm to process this data but i cannot process it. I was wondering if anyone has any ideas as to how to process this data or comments on whether this data is even useful. Also, I would really appreciate if someone could share their experiences on solving twinning issues during crystal growth Thanks in advance ! Maheshimage 1.pngimage 2.png 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] Error with iMosflm 1.0.7 of CCP4 6.4.0 kit
Hi David Nothing to do with the iMosflm developers. CCP4 has made some changes that have caused this error to arise in 6.4.0 on Linux (this is not to say that the iMosflm code didn't have the bug, just that it doesn't appear with either our own version or with the same version distributed with ccp4 6.3.0). The guys at ccp4 have produced a fix which will be released shortly, but they tell me this works; For now a quick workaround is to add 2@1 after word exit in line 847 in ccp4-6.4.0/share/ccp4i/imosflm/src/controller.tcl. --- src/controller.tcl 2012-11-30 20:46:13 + +++ src/controller.tcl 2013-10-19 08:52:29 + @@ -844,7 +844,7 @@ # If an executable has been named... if {$l_executable != } { # test the executable, by running it - if {![catch {exec $l_executable exit} l_result]} { + if {![catch {exec $l_executable exit 2@1 } l_result]} { if { [regexp -nocase windows $::tcl_platform(os)] } { set summary_filename [file join $::env(MOSDIR) SUMMARY] #set summary_filename [list $summary_filename] Of course, my favourite fix is to run the version from our website which does not show this bug. Best wishes On 23 Oct 2013, at Wed23 Oct 17:39, David Schuller wrote: iMosflm developers: I have installed CCP4 6.4.0, which includes iMosflm 1.0.7 and ipmosflm 7.0.9. This is on Scientific Linux 6.x, 64 bit distribution. When I run iMosflm either from the command shell or from the ccp4i interface, I get an error just like this: http://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg27243.html iMosflm claims it cannot run without mosflm 7.0.9, followed by output indicating that mosflm 7.0.9 runs. (See attached screen capture of error message) Note the linked description is for the previous versions of imosflm amd mosflm, so this error seems to be a repeat. I downloaded the iMosflm and ipmosflm executables from the iMosflm web site, put ipmosflm in my executable directory, and this seems to fix the problem. You should get the CCP4 folks to investigate this and propagate a fix. Cheers, -- == = All Things Serve the Beam == = David J. Schuller modern man in a post-modern world MacCHESS, Cornell University schul...@cornell.edu imosf.err.jpg 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] strange unit cell
Hi Sangheon As others have said, there is nothing that stops a cell being monoclinic with those cell dimensions - indeed, there is nothing stopping it being triclinic, orthorhombic or tetragonal either (or even rhombohedral, for those of us who like to describe it with non-hexagonal axes). What *is* important is the symmetry of the reciprocal lattice; looking at projections of the reciprocal lattice along the major axes (i.e. a*, b* or c*) using a tool like hklview or viewhkl (both of which are in ccp4 6.4.0) should be sufficient to demonstrate whether you really have the higher symmetry. On 25 Oct 2013, at 01:55, 유상헌 wrote: Hi everyone, Recently I’ve got a protein crystal and I did indexing and scaling with a cubic space group (unit cell 104.115 104.115 104.115 90.0 90.0 90.0). But a Rmerge value was too high (around 0.5-0.6). So, I tried lower symmetry space groups and I successfully solved the structure with a space group P21 (Rwork/Rfree: 0.22/0.27). However, there was one strange fact. The unit cell of the P21 was 104.209 104.225 104.254 90.000 89.967 90.000. I’m confused with this fact that a, b, and c of the unit cell are almost same, and in addition, the beta angle is too close to 90. I didn’t do refinement with a twin option. So, is the space group correct? Is there anyone who know this case? Thanks, Sangheon Yu Rm. 1053 Bldg. 200 School of Agricultural Biotechnology College of Agriculture Life Sciences Seoul National University Seoul 151-921, KOREA 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] A photograph of the Arndt-Wonacott rotation camera?
There is, of course, a photo in The Rotation Method in crystallography, by Arndt and Wonacott, which currently fetches over $245 on Amazon... On 30 Oct 2013, at 16:05, Gerard Bricogne wrote: Dear all, Apologies for such a retro and non-biological question, but would anyone have a photograph of an Arndt-Wonacott rotation camera that he/she would be willing to share? I collected data on the first two prototypes in the early seventies, then on one of the first commercial models, but I cannot find any images of this ground-breaking piece of equipement on the Web. I found images for the Enraf-Nonius precession camera and the CAD-4 diffractometer, but not for the A-W rotation camera. This would be for use as visual material in presentations, and I would gratefully acknowledge the source of it. Thank you in advance! With fingers crossed ... . Gerard. -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * === 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] bluetooth monitor
Hi Or you could look at using something like an Apple TV connected to a wall mounted flat screen monitor to stream via wifi (which may be better suited to fast data rates than bluetooth). Roku or Chromecast might be cheaper alternatives to the Apple TV, but I know almost nothing about them. Wireless presentations from iPad to Apple TV work pretty well, and I'm sure there must be more economical solutions out there. On 30 Oct 2013, at 17:20, mesters wrote: Alternatively, several projectors can do that which could be an alternative? Monitors have a too high resolution and that could be a problem. - J .- Am 29.10.13 18:05, schrieb Brett, Thomas: Hi all: I was wondering if anyone had economical suggestions on a bluetooth LED or LCD monitor. I would like to have a wall mounted monitor that one could easily connect laptops and imacs to for structure display, doing tutorials on building into maps, etc. thanks -tom Tom J. Brett, PhD Assistant Professor of Medicine Division of Pulmonary and Critical Care Washington University School of Medicine Campus Box 8052, 660 S. Euclid Saint Louis, MO 63110 http://brettlab.dom.wustl.edu/ -- protest.jpgDr. Jeroen R. Mesters Gruppenleiter Strukturelle Neurobiologie und Kristallogenese Institut für Biochemie Universität zu Lübeck Zentrum für Medizinische Struktur- und Zellbiologie Ratzeburger Allee 160, D-23538 Lübeck Tel: +49-451-5004065 Fax: +49-451-5004068 Http://www.biochem.uni-luebeck.de Http://www.iobcr.org Http://www.selfish-brain.org Http://www.opticryst.org -- Any intelligent fool can make things bigger and more complex. It takes a lot of genius and a lot of courage to move in the opposite direction (Albert Einstein, 1879-1955) If you can look into the seeds of time and say which grain will grow and which will not - speak then to me (Macbeth) -- Disclaimer * Employees of the Institute are expressly required not to make defamatory statements and not to infringe or authorize any infringement of copyright or any other legal right by email communications. Any such communication is contrary to Institute policy and outside the scope of the employment of the individual concerned. The Institute will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising. Employees who receive such an email must notify their supervisor immediately. * This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. * E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. -- 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] How to show the ligands (both as sticks and sphere) as shown here in Pymol
Hi Wei *Dead easy* in ccp4mg - display your object as ball and stick, clone it, then display the clone with reduced opacity (or increased transparency). On 20 Jan 2014, at 04:40, Wei Shi wrote: Hi all, Please see attached Fig where they show the ligand both as sticks and spheres at the same time. Does anyone happen to know how to display the ligand like this? Thank you so much! Best, Wei Ligand.ppt 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] making high res image in pymol
CCP4MG? On 28 Jan 2014, at 15:27, A K wrote: Hi all, I am trying to generate a high resolution figure of a molecule together with its symmetry mates (250 A readius) for a poster. If I try to ray it, the pymol session crashes (perhaps too many molecules are open). Using png xxx.png, dpi=300 or dpi=600 command doesn't make any difference; the image is still kind of low resolution for A0 or A1. Any idea how I can generate this in pymol? (I am using the free version of pymol) Thank you in advance, Alex 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)
[ccp4bb] new release of Mosflm iMosflm version 7.1.0
Hi folks We are pleased to announce a new release of Mosflm iMosflm; there are quite a few changes (a non-exhaustive list is at the end of this message). The default web-pages for both programs will now lead you directly to the new versions; http://www.mrc-lmb.cam.ac.uk/harry/imosflm and http://www.mrc-lmb.cam.ac.uk/harry/mosflm *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Changes since 1.0.7 / 7.0.9 iMosflm has been re-numbered to 7.1.0 so that its index coincides with that for Mosflm. There was no version of iMosflm between 1.0.7 and 7.1.0. 1. It is now possible to attempt to index and integrate images showing multiple lattices. This is an initial implementation and will only work in straightforward cases, for example the difference in orientation of the lattices must be greater than 1-2 degrees. Also at present it is only possible to use those reflections that are not overlapped when using the data in any downstream processing, and this will usually mean a significant drop in completeness. More details are given below. 2. It is now possible to distribute the integration task over multiple cores (parallel processing) while retaining the graphical output (only for OSX and Linux, not for Windows). 3.It is now possible to merge multiple MTZ files in QuickSymm/ QuickScale. In addition, it is possible to have some control over the scaling (exclude batches, reset resolution limits etc). 4. When completed, the results from the beam-search in the Indexing step are now sorted on the positional residual (discriminating against solutions with larger unit cells) to make it easier to identify the correct solution. 5. A traffic light system of warnings has been introduced, to make it easier to identify when there is a serious problem with processing. 6. Improved spot finding for very small spot sizes (eg in situ crystals with the Pilatus detector). 7. Small changes to autoindexing. 8. Resolution ranges to exclude from processing can now be defined explicitly, to avoid the severe loss in completeness that results from excluding all possible resolution shells for ice diffraction. In addition, anisotropic resolution limits may be specified. 9. It is now possible to define the detector omega angle for non- standard installations. 10. A site file can be used to specify experimental parameters that are known to be incorrect in the image header. This saves having to correct these parameters in every session of iMosflm. The site file has format . Allowed keywords: WAVELENGTH DISPERSION POLARISATION [PINHOLE | MIRRORS | MONO | SYNCHROTRON ] DIVERGENCE BEAM DISTANCE DISTORTION TILT DISTORTION TWIST GAIN DETECTOR REVERSEPHI DETECTOR OMEGA 11. A site file can be read or saved from the Session menu, or on startup using: imosflm --site A message will given in the launch window if any error in the keyword or value is detected. Other command line options are also available, listed by typing imosflm --help. 12. The CCP4 Uniqueify script is run automatically after TRUNCATE, providing an MTZ file with Rfree flags included. 13. QtRView replaces BAUBLES to present results from POINTLESS/ AIMLESS/TRUNCATE, so this no longer depends on a Web browser. 14. Multiple small bug fixes. 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] High Rwork/Rfree vs. Resolution
Hi Kay means, of course, the ACA meeting in Albuquerque, not the IUCr in Montreal! Authors of the major processing packages will be competing for your attention... 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) On 23 Feb 2014, at 07:55, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: Projects and problems like this are clearly a justification for asking to deposit not only the results from data processing, but also the raw data frames. These would allow developers to improve the models underlying their algorithms, and to find those corner cases where the algorithms break. That would help everyone. Maybe you could make this dataset (and sequence) available for the forthcoming IUCr conference, as an example for a difficult dataset? (send email to Ed Collins or me) You would profit from the fact that experienced crystallographers do their best to make the most of your data. best, Kay On Fri, 21 Feb 2014 20:13:33 -0600, Chris Fage cdf...@gmail.com wrote: Thanks for the assistance, everyone. For those who suggested XDS: I forgot to mention that I have tried Mosfim, which is also better than spot fitting than HKL2000. How does XDS compare to Mosflm in this regard? I am not refining the high R-factor structure with NCS options. Also, my unit cell dimensions are 41.74 A, 69.27 A, and 83.56 A, so there isn't one particularly long axis. I'm guessing the low completeness of the 1.65 angstrom dataset has to do with obstacles the processing software encountered on a sizable wedge of frames (there were swaths of in red in HKL2000). I'm not sure why this dataset in particular was less complete than the others. Thanks, Chris On Fri, Feb 21, 2014 at 6:41 PM, Chris Fage cdf...@gmail.com wrote: Dear CCP4BB Users, I recently collected a number of datasets from plate-shaped crystals that diffracted to 1.9-2.0 angstroms and yielded very nice electron density maps. There is no major density unaccounted for by the model; however, I am unable to decrease Rwork and Rfree beyond ~0.25 and ~0.30, respectively. Probably due to the more 2-dimensional nature of my crystals, there is a range of phi angles in which the reflections are smeared, and I am wondering if the problem lies therein. I would be grateful if anyone could provide advice for improving my refinement statistics, as I was under the impression that the R-factors should be ~5% lower for the given resolution. A few more pieces of information: -Space group = P21, with 2 monomers per asymmetric unit; -Chi square = 1.0-1.5; -Rmerge = 0.10-0.15; -Data were processed in HKL2000 and refined in Refmac5 and/or phenix.refine; -PHENIX Xtriage does not detect twinning, but hints at possible weak translational pseudosymmetry; -I was previously able to grow one atypically thick crystal which diffracted to 1.65 angstroms with Rwork/Rfree at 0.18/0.22. Unfortunately, the completeness of the dataset was only ~90%. Regards, Chris
Re: [ccp4bb] Fwd: [ccp4bb] CCP4-6.4.0 source code building failed in Mac OS X 10.8.5
Hi If trying to build on Macs (OSX 10.5 - 10.9) I strongly recommend installing either the High Performance Computing gcc/gfortran or investing in the Intel Compilers. http://hpc.sourceforge.net/ http://software.intel.com/en-us/intel-compilers (if you have ) Performance-wise, there's not much to choose between them these days. Clang just doesn't cut the mustard, and rolling your own compilers from the gcc archive can be fraught with difficulty and lead to incorrectly functioning compilers. On 3 Mar 2014, at 11:08, wu donghui wrote: -- Forwarded message -- From: wu donghui wdh0...@gmail.com Date: Mon, Mar 3, 2014 at 7:07 PM Subject: Re: [ccp4bb] CCP4-6.4.0 source code building failed in Mac OS X 10.8.5 To: Marcin Wojdyr marcin.woj...@diamond.ac.uk Dear Marcin, Yes, I set CC=gcc-4.2.1 in cj.rc file or type in command line. As is shown, it can identify gcc for gcc-4.2.1 checking for gcc... gcc-4.2.1 checking whether the C compiler works… no But indicating that the C compiler does not work. I will try Fortran compiler shortly and let you know. Best, Donghui On Mon, Mar 3, 2014 at 5:43 PM, Marcin Wojdyr marcin.woj...@diamond.ac.uk wrote: On Mon, Mar 03, 2014 at 01:16:37PM +0800, wu donghui wrote: gcc version in my Mac OS X 10.8.5 is as below. Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) That's Apple compiler. It supports C and C++ but not Fortran, so you also need a Fortran compiler such as gfortran. checking for gcc... gcc-4.2.1 checking whether the C compiler works... no Did you set CC=gcc-4.2.1? Marcin -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom 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] Fwd: [ccp4bb] CCP4-6.4.0 source code building failed in Mac OS X 10.8.5
Hi I think you must be doing something wrong if you can't run Mosflm from the ccp4 binary install - it runs for me. How are you trying to run it? If you need the compilers to build Mosflm then I *very* strongly recommend using the compilers I mentioned in my earlier e-mail - they are what the developers of Mosflm (i.e. Andrew Leslie and me) use to build the distribution versions. If you don't have them installed, and you need to build the Mosflm executable, then you should certainly install them. On OSX, installing the HPC compilers is a doddle. However, my even stronger recommendation is to use the executables that we build here in Cambridge - they have been built and tested rigorously, and I don't think you will gain anything from building yourself (apart from maybe a headache...). On 3 Mar 2014, at 14:51, wu donghui wrote: -- Forwarded message -- From: wu donghui wdh0...@gmail.com Date: Mon, Mar 3, 2014 at 10:44 PM Subject: Re: [ccp4bb] CCP4-6.4.0 source code building failed in Mac OS X 10.8.5 To: Marcin Wojdyr woj...@gmail.com Dear Marcin, The reason that I want to build from source is that running ipmosflm can not be done from binary code, while binary code only supports imosflm running. Thanks. Best, Donghui On Mon, Mar 3, 2014 at 8:09 PM, Marcin Wojdyr woj...@gmail.com wrote: Yes, I set CC=gcc-4.2.1 in cj.rc file or type in command line. As is shown, it can identify gcc for gcc-4.2.1 checking for gcc... gcc-4.2.1 checking whether the C compiler works… no To me it looks that you set compiler to non-existent gcc-4.2.1, so it doesn't work. Do you have a reason to build CCP4 from source? There are binaries available for OSX. Best regards Marcin 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)
[ccp4bb] iMosflm update available - version 7.1.1
Dear all We are pleased to announce an update to iMosflm available at http://www.mrc-lmb.cam.ac.uk/harry/imosflm which addresses two main issues - (1) The QuickSymm and QuickScale options did not work correctly under some circumstances, e.g. on MS-Windows and also when running the iMosflm parallel task. They now work more reliably. (2) A problem where a pop-up appeared with the message can't read ::cursor::question_arrow: no such variable when running on OSX using CCP4's TclTk has been fixed. The current version of Mosflm (or ipmosflm...) is still 7.1.0 and this is compatible with iMosflm 7.1.1. This version will be included in the next CCP4 update, due any day now. 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] jiffy for analyzing spot.xds?
Hi Francis At the risk of offending Wolfgang and Kay, why not try using other software to index visualize spots found on the images? Mosflm is the one that comes to my mind straight away, but there are others that could probably do the job... It would certainly be possible to write a jiffy that would read a SPOT.XDS and write it in Mosflm .spt format, which could then be read directly into iMosflm. On 15 Apr 2014, at 02:24, Francis Reyes wrote: Hi all, I'm trying to diagnose a tricky indexing issue and I suspect the spot picking is poor. Any jiffy's for analyzing the spot.xds file (prior to running IDXREF) ? (like an overlay onto the actual image)? Thanks, F - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder -- 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] ipmosflm not connecting to XQuartz on Mac.
Hi Francis It works okay for me on OSX Mavericks when I use the “official” Mosflm build rather than the CCP4 one (choose the “X11” option when downloading). I don’t think the CCP4 build of Mosflm includes the X11 GUI (since we’ve been trying for many years to wean people off it…). I’m assuming when you say you get a hang that it reads the commands but the X11 GUI doesn’t appear (but I could be wrong). It’s probably worth saying here that if people have features that they really do miss from the old GUI that they would like to see in iMosflm, then please let us know - if there’s enough demand we will do our best to oblige (particularly if it’s a straightforward addition to the code…). -- ** 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) On 15 Apr 2014, at 21:54, Francis Reyes francis.re...@colorado.edu wrote: Hi all, Anyone having issues getting ipmosflm to connect to XQuartz? I'm getting a hang when running go just when I expect the old GUI to load. Thanks, F - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder --
Re: [ccp4bb] PyMol and Schrodinger
Hi Since this is the CCP4 BB, I'd give ccp4mg a try... On 23 Apr 2014, at Wed23 Apr 16:43, Cygler, Miroslaw wrote: Hi, I have inquired at Schrodinger about the licensing for PyMol. I was surprised by their answer. The access to PyMol is only through a yearly licence. They do not offer the option of purchasing the software and using the obtained version without time limitation. This policy is very different from many other software packages, which one can use without continuing licensing fees and additional fees are only when an upgrade is needed. At least I believe that Office, EndNote, Photoshop and others are distributed this way. I also remember very vividly the Warren’s reason for developing PyMol, and that was the free access to the source code. He later implemented fees for downloading binary code specific for one’s operating system but there were no time restrictions on its use. As far as I recollect, Schrodinger took over PyMol distribution and development promising to continue in the same spirit. Please correct me if I am wrong. I find the constant yearly licensing policy disturbing and will be looking for alternatives. I would like to hear if you have had the same experience and what you think about the Schrodinger policy. Best wishes, Mirek 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)
[ccp4bb] HKL2MAP .sca files...
Hi folks When I run hkl2map for SAD data using unmerged .sca files produced by Aimless, I am invariably bugged by the fact that merged .sca files (from Aimless) have the unit cell in the first few lines, but the unmerged files don't - so I have to either type in the cell dimensions or (usually) read in the merged file to get the cell dimensions then read in the unmerged file to get the data that SHELXC really wants. So I'm wondering - what's the reasoning behind including the cell dimensions in the merged file and omitting them in the unmerged file? Would it break anything if the cell dimensions were included in the unmerged file? 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] error in starting imosflm
Hi When you get this error, and everything has been closed, what do you get if you type (in the same terminal window that you tried to start iMosflm) - $MOSFLM_EXEC ? It's plain from the message that ipmosflm is not compatible' that iMosflm is trying to run with an incompatible MOSFLM_EXEC (maybe from the old ccp4 6.3 distribution, but there could be other reasons). On 28 Apr 2014, at 13:05, sreetama das wrote: Dear All, Whenever I open up imosflm GUI from the terminal, I get the following error: iMosflm version 7.1.1, 24th March 2014 ipmosflm is not compatible. Please configure iMosflm with the correct executable. clicking the Configure button at the bottom of the error message panel closes everything. the following is shown on the terminal: MOSFLM_EXEC set to ipmosflm testing MOSFLM_WISH (/home/*/Software/CCP4/ccp4-6.3.0/bin/wish) Tcl platform is unix i686 Linux 3.8.0-32-generic TclTk version from info patchlevel is 8.4.19 Tk windowing system is x11 I had run imosflm successfully just 2 hours before this instance. After that, I had enabled the older version of CCP4-6.3 (by sourcing it from the .bashrc file) for sometime to look at the options in molrep (in CCP4-6.3), and then re-enabled the newer CCP4-6.4. Enabling ccp4-6.3 from the .bashrc file typing imosflm opens up the older 7.0.1 version. The option settingsenvironment variables is not working in the newer imosflm version now, changing the value in the GUI of the older version of imosflm doesn't help either. I applied the latest CCP4 updates; that doesn't set things right. Please let me know how to re-configure iMosflm to run with ccp4-6.4. thanks regards, sreetama 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] error in starting imosflm
Hi Sreetama That's the problem - sourcing the old ccp4 6.3 distro has set up MOSFLM_EXEC to point to an old copy of ipmosflm that will not run with the latest iMosflm. Mosflm version 7.0.9 for Image plate and CCD data 14th May 2012 which cannot be used with iMosflm 7.1.0. So it looks like there might be an issue with the ccp4 6.4 setup not over-writing the environment variable MOSFLM_EXEC as it should. The immediate way round this would be to not source ccp4 6.3 in any terminal that you want to run iMosflm from. Can you send me c...@stfc.ac.uk (*not* to the ccp4bb, please) the output of echo $PATH which $MOSFLM_EXEC (1) before you source ccp4-6.3 (2) after you source ccp4-6.3 (3) after you source ccp4-6.4 So that we can get a clear idea of what is happening to your PATH when you do each of these three things. On 28 Apr 2014, at 14:38, sreetama das wrote: Dear Sir, If I sorce ccp4-6.3, and then change in the bashrc file source ccp4-6.4, (and source the modified .bashrc file in either case) but don't close the previous terminal, then opening imosflm gives the aforementioned error. After closing the imosflm GUI, if I type at the terminal, I get the following: sreetama@sreetama-laptop:~/data $ $MOSFLM_EXEC BFONT COLOR=#FF!--SUMMARY_BEGIN-- html !-- CCP4 HTML LOGFILE -- hr !--SUMMARY_END--/FONT/B Mosflm version 7.0.9 for Image plate and CCD data 14th May 2012 *** Andrew Leslie and Harry Powell, MRC Laboratory of Molecular Biology, Hills Road, Cambridge CB2 0QH, UK E-mails: and...@mrc-lmb.cam.ac.uk, ha...@mrc-lmb.cam.ac.uk References: Mosflm: A.G.W. Leslie and H.R. Powell (2007), Evolving Methods for Macromolecular Crystallography, 245, 41-51 ISBN 978-1-4020-6314-5 New auto-indexing based on DPS: I. Steller R. Bolotovsky and M.G. Rossmann (1997) J. Appl. Cryst. 30, 1036-1040 New iMosflm GUI: T.G.G. Battye, L. Kontogiannis, O. Johnson, H.R. Powell and A.G.W. Leslie.(2011) Acta Cryst. D67, 271-281) How much of this information is useful in diagnosing user problems? Mosflm run on Monday, April 28 2014 at 19:01 by sreetama Compiler command: gfortran Compiler version: GNU Fortran (GCC) 4.4.7 Copyright (C) 2010 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more informatio Executable type: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped This executable was built by ccb on Thursday, June 28 2012 at 09:33 MOSFLM = Also the terminal refuses to close if I type exit. Forcibly closing the terminal , and typing imosflm in a new terminal solves the problem. regards, sreetama On Monday, 28 April 2014 6:52 PM, Harry Powell ha...@mrc-lmb.cam.ac.uk wrote: Hi When you get this error, and everything has been closed, what do you get if you type (in the same terminal window that you tried to start iMosflm) - $MOSFLM_EXEC ? It's plain from the message that ipmosflm is not compatible' that iMosflm is trying to run with an incompatible MOSFLM_EXEC (maybe from the old ccp4 6.3 distribution, but there could be other reasons). On 28 Apr 2014, at 13:05, sreetama das wrote: Dear All, Whenever I open up imosflm GUI from the terminal, I get the following error: iMosflm version 7.1.1, 24th March 2014 ipmosflm is not compatible. Please configure iMosflm with the correct executable. clicking the Configure button at the bottom of the error message panel closes everything. the following is shown on the terminal: MOSFLM_EXEC set to ipmosflm testing MOSFLM_WISH (/home/*/Software/CCP4/ccp4-6.3.0/bin/wish) Tcl platform is unix i686 Linux 3.8.0-32-generic TclTk version from info patchlevel is 8.4.19 Tk windowing system is x11 I had run imosflm successfully just 2 hours before this instance. After that, I had enabled the older version of CCP4-6.3 (by sourcing it from the .bashrc file) for sometime to look at the options in molrep (in CCP4-6.3), and then re-enabled the newer CCP4-6.4. Enabling ccp4-6.3 from the .bashrc file typing imosflm opens up the older 7.0.1 version. The option settingsenvironment variables is not working in the newer imosflm version now, changing the value in the GUI of the older version of imosflm doesn't help either. I applied the latest CCP4 updates; that doesn't set things right. Please let me know how to re-configure iMosflm to run with ccp4-6.4. thanks regards, sreetama Harry -- ** note change
Re: [ccp4bb] Pilatus and Strategy wrt Radiation Damage
Hi Marcus Mueller (from Dectris, who develop and manufacture the Pilatus) did some work on this a couple of years ago and determined that an oscillation angle ~ 0.5x the mosaicity of the crystal (using the XDS value of mosaicity, which is not the same as Mosflm's); the abstract says - The results show that fine ’-slicing can substantially improve scaling statistics and anomalous signal provided that the rotation angle is comparable to half the crystal mosaicity. Acta Cryst. (2012). D68, 42-56[ doi:10.1107/S0907444911049833 ] Optimal fine -slicing for single-photon-counting pixel detectors M. Mueller, M. Wang and C. Schulze-Briese My reading of this is that there is still a place for strategy calculations. On 30 Apr 2014, at Wed30 Apr 15:06, Sanishvili, Ruslan wrote: Hi Jacob, I'll take a first crack as I am sure many will follow. It is true that with CCD detectors one has to be careful how small an oscillation range to use for a frame before read noise starts to eat into the data quality. Pilatus offers two major new features - is fast and is photon counting as opposed to integrating detector. The speed allows to collect data without a shutter and it is very important as it can dramatically improve data quality. Now there are fast CCD detectors as well on the market. Being a photon counter, Pilatus has no read noise which, as you have pointed out, allows you to collect as thin a frame as you want. However, it is if you consider the detector only. In reality, if you go very thin and very fast, you may not have enough flux to record the data. Also, even once we get rid of the shutter, there are still other sources of instabilities and they do affect the fast data collection adversely. One could try going (very) thin sliced and somewhat slow but there is another gotcha there. Most rotation stages used for rotating the sample crystal, do not like going extremely slow which would be the case with thin frames and long exposure times. In this case the speed may not remain as constant as we would like during data collection. I think there was a publication from Diamond Synchrotron discussing strategies of data collection with Pilatus. We've done a little bit of systematic studies as well and while things may well be sample- and facility-dependent, ~0.2 degree frames with ~0.2 sec exposure time seemed to make good compromise between above-mentioned issues. Here I would like to emphasize again - there certainly will be samples which will benefit from somewhat different parameters. Hope it helps, Cheers, N. Ruslan Sanishvili (Nukri) Macromolecular Crystallographer GM/CA@APS X-ray Science Division, ANL 9700 S. Cass Ave. Lemont, IL 60439 Tel: (630)252-0665 Fax: (630)252-0667 rsanishv...@anl.gov From: CCP4 bulletin board [CCP4BB@jiscmail.ac.uk] on behalf of Keller, Jacob [kell...@janelia.hhmi.org] Sent: Wednesday, April 30, 2014 7:49 AM To: CCP4BB@jiscmail.ac.uk Subject: [ccp4bb] Pilatus and Strategy wrt Radiation Damage Dear Pilatus/Radiation Damage Cognoscenti, I read a few years ago, before the advent of Pilatus detectors, that the best strategy was a sort of compromise between number of images and detector readout noise overhead. I have heard that Pilatus detectors, however, have essentially no readout noise, so I am wondering whether strategies have changed in light of this, i.e., is the best practice now to collect as many images as possible at lowest exposure possible? JPK *** Jacob Pearson Keller, PhD Looger Lab/HHMI Janelia Farms Research Campus 19700 Helix Dr, Ashburn, VA 20147 email: kell...@janelia.hhmi.org *** 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] report mosaicity
Hi I'm sure that a real HKL or Denzo/Scalepack expert will correct me, but my recollection is that you don't use any of the values from Denzo, but the value from Scalepack (see http://www.hkl-xray.com/sites/default/files/HKL2000manual/chapter3/step14-1.htm, for example). On 16 May 2014, at 00:26, hongshi WANG wrote: Hello everyone, I am gonna report the mosaicity of my data set as required by the journal. I processed the data using HKL2000. So I checked the denzo log file. I found many different mosaicity values. The first one is default input (0.3), the rest are corresponding to specific images. I think the mosaicity value required should be an overall value or averaged value. Could you please let me know how I can get it. Or some other software can determine it. I really appreciate your help and response! Hongshi 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] data processing with XDS
Hi Almudena Have you tried Mosflm (since this is the CCP4 BB...)? On 19 May 2014, at 17:18, Almudena Ponce Salvatierra wrote: Dear all, I am looking for some suggestions here. I have lately collected some datasets but the spots are very very weak... it is very difficult to process them. At times it looks like XDS is stalled or at times it just says that it can not interpret the lattice parameters... also while running integrate I have such a message after each range of images: !!! WARNING !!! REFINEMENT DID NOT CONVERGE LAST CORRECTION SHIFT WAS 9.1E-03 (should be 1.0E-03) I guess this is not good at all. And I wonder what to do? Is there any info that I can get out from these data at all? or rather not? I wonder if the problem is to find the spots, I have tried with HKL2000 and it can't even find enough of them for indexing. Any ideas are welcome. Best wishes, Almudena. -- Almudena Ponce-Salvatierra Macromolecular crystallography and Nucleic acid chemistry Max Planck Institute for Biophysical Chemistry Am Fassberg 11 37077 Göttingen Germany 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] baverage: no tables were found in this file
Hi Felix Couldn't agree more, particularly when non-native anglophones have to contend with limiting themselves to ASCII characters in their filenames anyway (e.g. Spanish users have to carefully rename the OSX unnamed folder (carpeta sin título) to something without an accent...) On 3 Jun 2014, at 12:58, Felix Frolow wrote: Possibility to have file names with the spaces is a curse put on the community by Microsoft, and it will be a big mistake to introduce this to CCP4 (my opinion). I guess there are much more important things new CCP4 GUI should deal with. If CCP4 GUI will start to go this way, file names with spaces will become file names with spaces and multilingual, in some these languages writing is going in the different direction. In my introduction to UNIX, I teach in the beginning of practical protein crystallography my first demand from student is to forget about spaces in the fie names and the life will be much easier. No fix is needed for that, concentrate on more important problems :-) Dr Felix Frolow Professor of Structural Biology and Biotechnology, Department of Molecular Microbiology and Biotechnology Tel Aviv University 69978, Israel Acta Crystallographica F, co-editor e-mail: mbfro...@post.tau.ac.il Tel: ++972-3640-8723 Fax: ++972-3640-9407 Cellular: 0547 459 608 On Jun 3, 2014, at 14:47 , Eugene Krissinel eugene.krissi...@stfc.ac.uk wrote: I take this chance to to confirm once more, as publicly as possible, that file paths with spaces are discouraged in today's CCP4. This inconvenience originates from ancient times in computing when good half of CCP4 was written and when spaces were disallowed on file system nodes. Please take a notice of this fact as CCP4 core still receives (albeit infrequent) bug reports, where surprising behaviour is due to using file paths with white spaces. Fixing this has proved to be a hard problem, purely because of technical choices made quite a number of years ago. But good news are that this limitation will be removed in new CCP4 Gui under development. Eugene On 3 Jun 2014, at 08:23, Mark J van Raaij wrote: This also occurred to me once where the file path had a space,(/Google Drive/), when I moved the file somewhere else it worked. I was using baverage from the CCP4i GUI. Mark J van Raaij Lab 20B Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 3 Jun 2014, at 09:20, Tim Gruene wrote: Dear Bing, can you post the exact command you were using, please? Also please check with a different PDB file. In case you are using baverage from the command line, can you make sure you are actually using the program from ccp4 by typing 'which baverage' at the command prompt? Regards. Tim On 06/02/2014 10:16 PM, Wang, Bing wrote: Hi CCP4, Recently when I input my pdb file and run the baverage in the ccp4 suit to check the temperature factor, it always tell me No tables were fund in this file. Could you tell me how to fix this problem? Or is there another software instead of baverage I could use to check the temperature factor? Thanks! Bing -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -- Scanned by iCritical. 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] baverage: no tables were found in this file
I'm wondering if GUI2 will cope with accents as well as spaces (e.g. in the Spanish carpeta sin título which is the default new folder on Macs)? Discipline. That's what we need... On 3 Jun 2014, at 13:03, Mark J van Raaij wrote: completely agree with avoiding spaces in paths and file names, but Google Drive is very handy for sharing files, so every once in a while I forget to move a file someone shares with me before running Unix programs on it and get strange errors. Depending on how awake one is at the time finding out the source can be time-consuming...Google should really remove the space! Mark J van Raaij Lab 20B Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 3 Jun 2014, at 13:47, Eugene Krissinel wrote: I take this chance to to confirm once more, as publicly as possible, that file paths with spaces are discouraged in today's CCP4. This inconvenience originates from ancient times in computing when good half of CCP4 was written and when spaces were disallowed on file system nodes. Please take a notice of this fact as CCP4 core still receives (albeit infrequent) bug reports, where surprising behaviour is due to using file paths with white spaces. Fixing this has proved to be a hard problem, purely because of technical choices made quite a number of years ago. But good news are that this limitation will be removed in new CCP4 Gui under development. Eugene On 3 Jun 2014, at 08:23, Mark J van Raaij wrote: This also occurred to me once where the file path had a space,(/Google Drive/), when I moved the file somewhere else it worked. I was using baverage from the CCP4i GUI. Mark J van Raaij Lab 20B Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 3 Jun 2014, at 09:20, Tim Gruene wrote: Dear Bing, can you post the exact command you were using, please? Also please check with a different PDB file. In case you are using baverage from the command line, can you make sure you are actually using the program from ccp4 by typing 'which baverage' at the command prompt? Regards. Tim On 06/02/2014 10:16 PM, Wang, Bing wrote: Hi CCP4, Recently when I input my pdb file and run the baverage in the ccp4 suit to check the temperature factor, it always tell me No tables were fund in this file. Could you tell me how to fix this problem? Or is there another software instead of baverage I could use to check the temperature factor? Thanks! Bing -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -- Scanned by iCritical. 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] Proper detwinning?
hi Chris Can you send the date-stamped log file (called something like mosflm_20140712_140235.lp, I.e. with the year, month, date, etc when you ran the program) to me directly (i.e. not to the BB, since it's likely to be of little interest to all the other subscribers...) so I can have a look at the results of indexing, and the processing that led up to the MASKIT error? 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) On 12 Jul 2014, at 00:33, Chris Fage cdf...@gmail.com wrote: Nat and Misha, Thank you for the suggestions. Xtriage does indeed detect twinning in P1, reporting similar values for |L|, L^2, and twin fraction as in P212121. The unit cell dimensions for the 2.0-A structure (P1) are: 72.050 105.987 201.142 89.97 89.98 89.94 P 1 The unit cell dimensions for the 2.8-A structure (P212121) are: 75.456 115.154 202.022 90.00 90.00 90.00 P 21 21 21 I have been processing in HKL2000, which only recognizes one set of unit cell parameters for each Bravais lattice (does anyone know how to change this?). Specifically, for a primitive monoclinic unit cell it estimates: 104.53 71.82 200.99 89.86 91.80 91.16 This is the unit cell which refined to Rwork/Rfree ~ 27%/34%. Indexing in mosflm gives three options for primitive monoclinic: 105.6 71.7 200.9 90.0 90.1 90.0 71.7 105.6 201.0 90.0 89.9 90.0 71.7 200.9 105.6 90.0 90.3 90.0 Attempting to integrate in any of these space groups leads to a fatal error in subroutine MASKIT. I can also use the index multiple lattices feature to get a whole slew of potential space group; however, integrating reflections leads to the same fatal error. Finally, Zanuda tells me that P212121 is the best space group, according to R-factors. However, I do not believe P212121 is the correct assignment. Best, Chris On 7/10/14, Isupov, Michail m.isu...@exeter.ac.uk wrote: I would recommend to run ZANUDA in the default mode from ccp4i or on CCP4 web server. ZANUDA has resolved several similar cases for me. Misha From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Chris Fage [cdf...@gmail.com] Sent: 10 July 2014 01:14 To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Proper detwinning? Hi Everyone, Despite modelling completely into great electron density, Rwork/Rfree stalled at ~38%/44% during refinement of my 2.0-angstrom structure (P212121, 4 monomers per asymmetric unit). Xtriage suggested twinning, with |L| = 0.419, L^2 = 0.245, and twin fraction = 0.415-0.447. However, there are no twin laws in this space group. I reprocessed the dataset in P21 (8 monomers/AU), which did not alter Rwork/Rfree, and in P1 (16 monomers/AU), which dropped Rwork/Rfree to ~27%/32%. Xtriage reported the pseudo-merohedral twin laws below. P21: h, -k, -l P1: h, -k, -l; -h, k, -l; -h, -k, l Performing intensity-based twin refinement in Refmac5 dropped Rwork/Rfree to ~27%/34% (P21) and ~18%/22% (P1). Would it be appropriate to continue with twin refinement in space group P1? How do I know I'm taking the right approach? Interestingly, I solved the structure of the same protein in P212121 at 2.8 angstroms from a different crystal. Rwork/Rfree bottomed out at ~21%/26%. One unit cell dimension is 9 angstroms greater in the twinned dataset than in the untwinned. Thank you for any suggestions! Regards, Chris
Re: [ccp4bb] Who is using 64-bit Linux?
Hi Roger CCP4 and Mosflm work fine in my testing - I do builds for Linux and Macs, both 32 and 64 bits. I wouldn't expect to see a difference in performance (and don't see anything significant in practice). One thing - I think you will need to install 32-bit compatibility libraries for some of the code that is dynamically linked and has been built as 32-bit, e.g. I think ActiveTcl distros might need them (for iMosflm). On 3 Apr 2012, at 20:57, Roger Rowlett wrote: The time has come for me to upgrade my Linux OS to something more recent for me and my student workstations. A 32-bit distro is certainly conservative and compatible with CCP4 and Coot, but it seems like that solution hobbles my hardware and puts some limitations on available memory, even with PAE enabled. So who is using a 64-bit distro these days, and are there lingering issues of compatibility and dependency hell with commonly used XRD software, like CCP4, Coot, iMOSFLM etc.? Ubuntu 12.04 LTS (beta) actually works OK with one simple workaround for the global menu for CCP4 and Coot, and wine compatibility is fine for running CrysalisPro in the same environment, so it's really comes down to whether or not the extra performance of a 64-bit OS is worth the pain of compatibility issues for XRD software. Any thoughts? 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 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Who is using 64-bit Linux?
Hi David I'm curious - do you mean running on a 32-bit Centos box or running the 32-bit Mosflm executable on a 64-bit Centos box? We did have one report of problems with the 32-bit exe on a 64-bit box, which (seemingly) randomly gave one of two different results (either the same failure or success) - but that was fixed in the beta we released in July last year, and didn't occur with the 64-bit exe at all. We really are grateful to people who tell us about the bugs they find rather than try to struggle on in silence! Funny enough I can't get iMosflm running reliably on 32 bit CentOS 5 or CentOS 6 and I can on 64 bits versions. We have all running (CCP4, Coot, iMosflm, XDS, phenix, best, etc, etc) running in 64 bit and intent to move all user computers to uniform 64 bit environment on the next shutdown as it is more difficult to support both 32 and 64 bit enviroment. David -- David Aragao, PhD | Research Fellow - MX | Australian Synchrotron p: (03) 8540 4121 | f: (03) 8540 4200 | m: 0467 775 203 david.ara...@synchrotron.org.au | www.synchrotron.org.au 800 Blackburn Road, Clayton, Victoria 3168, Australia Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Refmac executables - win vs linux in RHEL VM
Hi I suspect that this is more to do with the amount of memory required, size of arrays etc; refinement will (in general) be more demanding in terms of these than an integration program like Mosflm. The last time I compared the Mosflm performance (which was a few years ago), running the same batch job on OSX 10.4 (Tiger), and on Windows XP and Linux Feisty Fawn (so you can tell how long ago this was) - both the latter running under virtual machines on the same 32-bit Intel Mac that the OSX job ran on) there was essentially no difference in performance (though I have a vague memory of Ubuntu being a little faster, maybe ~3%). Some caveats - * I used a gfortran build for OSX and Linux, g77 build for Windows * I didn't spend too much time on this * I wasn't running a GUI - all three as foregrounded jobs, nothing else running on the machine (I tried to make sure only the OS and essential services were running). So this wasn't a batch job in the traditional sense... * gfortran builds these days are considerably faster (and compare well to ifort builds) On 7 Apr 2012, at 17:50, Roger Rowlett wrote: I don't know the state of current software, because I haven't tried recently, but when I set up my student crystallography workstations a few years back I noticed many packages (e.g. EPMR, Phaser) that had potentially long run times (where it is really noticeable) would run on the identical hardware about 2-3 times faster in Linux than in Windows XP. Memory swapping wasn't the issue. I was astounded there could be that much overhead in Windows. A Linux VM on a windows machine being faster than native Win7 is pretty weird, though. Cheers, On 4/7/2012 11:42 AM, Bernhard Rupp (Hofkristallrat a.D.) wrote: Something the developers might be interested in: The Refmac_5.6.0117 32-bit windows binaries run native on a win64 3-4x slower than those from the linux distribution run **in a RHEL6.2-64 VMware virtual machine hosted the same windows7/64 system.** VM/RHEL: Refmac_5.6.0117: End of Refmac_5.6.0117 Times: User:1015.3s System: 135.0s Elapsed:19:17 Win native Refmac_5.6.0117: End of Refmac_5.6.0117 Times: User: 0.0s System:0.0s Elapsed:67:49 Most peculiaralthough I think but I do not know whether the linux binaries are 64 bit I don't think that address space is the issue here if they are. Maybe the paranoia-checkers in windows slow everything down although I did not see any resources overwhelmed... Best regards, BR - Bernhard Rupp 001 (925) 209-7429 +43 (676) 571-0536 b...@ruppweb.org hofkristall...@gmail.com http://www.ruppweb.org/ - No animals were hurt or killed during the production of this email. - Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] .CBF raw images in iMOSFLM- error
Dear all The problem was indeed the distance being written in mm rather than m, so some of our internal maths gave surprising results. This will be fixed in the next versions of iMosflm and Mosflm - barring finding any killer bugs I hope this will be released next week. On 11 Apr 2012, at 16:43, Harry wrote: Hi Yuri If you can put some of the images on our ftp site (instructions sent separately) we'll have a look. There was a problem a while ago when some Pilatus detectors changed from writing the distance in metres to writing it in millimetres, but no-one told us until iMosflm started having problems. On 11 Apr 2012, at 16:08, Yuri Pompeu wrote: Hello everyone, I am trying to process ###.cbf raw images (BNL X25) using the iMOSFLM utility and I get the following error message: Distance has refined to an unreasonable value This causes the program to freeze and not open the rest of the frames. Also it is not picking up the X and Y beam positions. It looks to me like its just simply not reading the image file HEADER properly. Anyone has encountered this before and has any ideas on how to get around/fix this? Thanks a lot! Yuri Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] iMosflm version 1.0.6 Mosflm version 7.0.8
Dear all We are pleased to announce the public release of new versions of iMosflm and Mosflm. We have addressed many bugs and performance issues, and also tidied things up in some of the tasks. If you are using a previous version we strongly recommend that you upgrade. In brief - Improved processing for Pilatus images (both 6M and 2M) Faster processing for large datasets in iMosflm More reliability in indexing, refinement integration Better feedback Easier multi-crystal strategy Available from our website - http://www.mrc-lmb.cam.ac.uk/harry/mosflm == In more detail (see http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver708/Release_notes for more) - Mosflm == Non-Bragg spots (eg zingers and hot pixels) and ice spots are now automatically removed when forming the standard profiles. Improvements in mosaicity estimation and refinement. Improvements in standard deviation estimates. Improved spot finding parameters for in-house diffraction images and for the very small spots that can be obtained from room temperature (in situ screening) crystals. More robust integration of images with very small spot separation. iMosflm == The colour of the predicted reflections can be changed to improve visibility on weak diffraction images. Improved selection of the correct indexing solution in cases of pseudosymmetry. Scaling and merging now performed with AIMLESS rather than SCALA. Release Notes for iMosflm version 1.0.6 New features The speed of the interface has been much improved when processing a large number of images in the Integration pane. The largest speed-up came from not refreshing the profile displays afresh with every new image integrated. A greatly improved multi-crystal strategy option is available that makes it much simpler to calculate a data collection strategy when multiple crystals or multiple segments from one crystal are required (see below, and also see the new iMosflm tutorial for details). Bad spots identified during processing and whose numbers are plotted during integration can now be displayed in the Image display window. New mosaicity estimation will produce successive plots up to 8 degrees if required. Space group validation has been improved wherever a symbol can also be typed in editable, pull-down lists (Indexing and Strategy panes). The multi-sector, pull-down sectors list used in the Integration pane has been adopted in the Indexing and Cell refinement panes. Initial detector and crystal parameters are saved before refinement and checked that they have not refined to unreasonable values. Users may accept the warnings ( reset the parameters) or ignore them. New items added to the Advanced integration tab of Processing options includes provision for outliers affected by ice rings. The maximum number of images in an integration block has been increased from 20 to 200. The FindHKL function has been placed within the Image display window's toolbar. Smaller rotation increments have been added to the Rotation: setting in the Auto-complete menu in the Strategy pane. The editable 'pie' widget displayed at the bottom of the Strategy pane for any sector can now be adjusted in single degree steps (previously only 5 degree changes were possible). Individual images can now be deleted from the Images pane by selecting them (left-click) and then right-clicking on the selected image. This was previously only available for complete sectors. Scala has been replaced by Aimless as the default scaling program used by the QuickScale command button. Scala can be chosen from the Processing options-Advanced integration tab under the Pointless Aimless/Scala switches. Files containing lists of spots can be read into iMosflm and displayed on the appropriate image. Files can be read from the main Session menu item 'Read spots file...' and from the 'Read spots file...' button (with an open file icon) next to the 'Index' button in the Autoindexing pane. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] Fwd: Crystallographic Software Fayre (ECM27, Bergen)
Hi folks Any of you who are considering attending ECM27 in Bergen may be interested in some of the sessions that have been arranged at this Software Fayre. The full list of Microsymposia at ECM27 should be available in the next couple of days From: Martin Lutz m.l...@uu.nl Date: 10 May 2012 13:48:11 GMT+01:00 To: undisclosed-recipients:; Subject: Crystallographic Software Fayre (ECM27, Bergen) Dear all, thanks to the local organizers, there will be a Crystallographic Software Fayre at the ECM27 meeting in Bergen (Norway). Authors of of academic and/or open-source software can present their new developments. The presentations should have a tutorial character with one or more practical examples. The available time slots can be seen on the website: http://www.cryst.chem.uu.nl/lutz/software_fayre.html (This website will be updated regularly) If you are interested, please send an e-mail with your name and a preliminary title of the presentation to Martin Lutz, m.l...@uu.nl. The time slots will be filled according to the first-come first-served principle. For information about the ECM27 congress (August 6-11, 2012), see: http://ecm27.ecanews.org With kind regards, Martin (Please forward this e-mail to anyone, who might be interested.) -- Martin Lutz Crystal and Structural Chemistry Bijvoet Center for Biomolecular Research Faculty of Science Utrecht University Padualaan 8 3584 CH Utrecht The Netherlands Tel. [+31] 030-2533902 Fax [+31] 030-2533940 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] how to ignore spot overlap in imosflm?
Hi This is all good advice, but there is more that you could do if you're desperate to use these images. Having made sure that your spots on the images are not actually overlapping (i.e. by looking closely at the images), but just flagged as overlapping in iMosflm, you may be able (i.e. no guarantees) to persuade Mosflm to use them by - (i) go to Processing Options-Advanced Integration and increase the values for the Profiles-Tolerance. There's a tool-tip that becomes visible if you hover the mouse cursor over the entry boxes which gives more advice on values. (ii) if you're *really* desperate, and you have noticed that the overall box width and box height has increased to values much bigger than your spots (e.g. your spots are really only ~5-10 pixels across, but the box size has increased to ~30) you could try setting the overall box size to ~the separation distance in pixels and UNchecking the Optimise overall box size check box - this will fix the overall dimensions but allow the spot size within it to optimise. This might get you out of a hole... As Zhije says, the proper solution is to collect the data without overlaps, though. Either of the above steps will reduce the measurement quality, though (i) is better than (ii). A rule of thumb is to set the crystal to detector distance (in mm) to at least [maximum cell edge(Å)/wavelength(Å)] (pedants might want to multiply the RHS of that by 1mm. There are better methods than rules of thumb, though, e.g. the strategy options that are now widely available. On 14 May 2012, at 04:48, Zhijie Li wrote: Hi Xinghua, The total intensity of each reflection needs to be accurately quantitated in order to calculate the structure factors. Not only the dots need to be well separated in the 3D reciprocal space, but also a small area around the dots are often needed to calculate the background for subtraction. That is why when two dots are getting too close, the programs will reject both dots. The first thing you need to do is to inspect the images reported with large number of overlaps to see if the dots are really overlapping or just close to each other. If the dots are barely touching or just too close to each other, you can manipulate the SEPERATION parameter to force the program to take the closely spaced spots. But keep in mind that you may get less accurate integration by doing so. If many spots are really touching each other, normally we won't force the programs to use them. Then the proper remedy is to move the detector farther and collect the dataset again (also, try to optimize your freezing to get the mosaicity as low as possible). For how to play with the mosflm parameters, please read here: http://www.mrc-lmb.cam.ac.uk/harry/cgi-bin/keyword2.cgi?SEPARATION. What you need is probably CLOSE. The hazard of high percentage of overlaps: If the overlaps are only scattered in a whole dataset, it is OK, even if they make up 5-10% or even 20% of the whole dataset. It will only give you a lower completeness, which is not too detrimental to the structure solution. However, if large, continuous regions in the dataset are missing, that will cause you to have poorly defined regions in the calculated map, often seen as featureless stripes or layers in the map. Unfortunately, when you have closely spaced reflections, the latter is often the case. The proper solution is to collect the data at a greater detector distance to resolve the spots (after taking the test images, both imosflm and HKL2000 can simulate the collection run to help you to decide what distance you need). In cases that you have a long unit cell (200A), the first thing you need to do is to align the long edge of the Unix cell with the rotational axis of the pin. In the difficult cases, you probably even need to shoot multiple crystals and combine the datasets to get enough completeness. Zhijie From: Xinghua Qin Sent: Sunday, May 13, 2012 10:22 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] how to ignore spot overlap in imosflm? Dear CCP4ers, We collected a diffraction dataset with high percentage of spot overlaps, It would be so kind to tell me how to ignore spot overlap in imosflm and explain the hazard of high percentage of spot overlaps. Thanks in advance. Best wishes Xinghua Qin -- Xinghua Qin State Key Laboratory of Plant Physiology and biochemistry College of Biological Sciences China Agricultural University No.2, Yuan Ming Yuan West Road Haidian District, Beijing, China 100193 Tel: +86-10-62732672 E-mail: xinghua...@126.com Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] Fwd: Crystallographic Software Fayre (ECM27, Bergen)
Hi folks The list of microsymposia at ECM27 is now available, but the list of speakers has not yet been finalised. Bear in mind that earlybird registration closes on 31st May, when the cost jumps by 750 NOK (~€100) for full participants, 550NOK (~€72) for students. The meeting website is http://ecm27.ecanews.org/ On 11 May 2012, at 10:36, Harry Powell wrote: Hi folks Any of you who are considering attending ECM27 in Bergen may be interested in some of the sessions that have been arranged at this Software Fayre. The full list of Microsymposia at ECM27 should be available in the next couple of days From: Martin Lutz m.l...@uu.nl Date: 10 May 2012 13:48:11 GMT+01:00 To: undisclosed-recipients:; Subject: Crystallographic Software Fayre (ECM27, Bergen) Dear all, thanks to the local organizers, there will be a Crystallographic Software Fayre at the ECM27 meeting in Bergen (Norway). Authors of of academic and/or open-source software can present their new developments. The presentations should have a tutorial character with one or more practical examples. The available time slots can be seen on the website: http://www.cryst.chem.uu.nl/lutz/software_fayre.html (This website will be updated regularly) If you are interested, please send an e-mail with your name and a preliminary title of the presentation to Martin Lutz, m.l...@uu.nl. The time slots will be filled according to the first-come first-served principle. For information about the ECM27 congress (August 6-11, 2012), see: http://ecm27.ecanews.org With kind regards, Martin (Please forward this e-mail to anyone, who might be interested.) -- Martin Lutz Crystal and Structural Chemistry Bijvoet Center for Biomolecular Research Faculty of Science Utrecht University Padualaan 8 3584 CH Utrecht The Netherlands Tel. [+31] 030-2533902 Fax [+31] 030-2533940 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Fwd: Crystallographic Software Fayre (ECM27, Bergen)
Dear all The deadlines below have been extended to 15th June. Note that, since the deadline for abstracts is still open, there should still be the opportunity of having your work chosen to be an oral presentation (three of the five talks in MS are chosen from the abstracts). The lists of speakers have not yet been finalised (how can they be when the abstract submission process is still open?), but a taster of some of the talk titles and speakers in a few of the MS is listed at - http://sig9.ecanews.org/sig9_activities.html Students of history may be interested to learn that Bergen was apparently founded by the son of Harald Hardrada, the Norwegian king who was killed at the battle of Stamford Bridge in 1066, just over a fortnight before a seminal moment in English history. On 22 May 2012, at 15:08, Harry Powell wrote: Hi folks The list of microsymposia at ECM27 is now available, but the list of speakers has not yet been finalised. Bear in mind that earlybird registration closes on 31st May, when the cost jumps by 750 NOK (~€100) for full participants, 550NOK (~€72) for students. The meeting website is http://ecm27.ecanews.org/ On 11 May 2012, at 10:36, Harry Powell wrote: Hi folks Any of you who are considering attending ECM27 in Bergen may be interested in some of the sessions that have been arranged at this Software Fayre. The full list of Microsymposia at ECM27 should be available in the next couple of days From: Martin Lutz m.l...@uu.nl Date: 10 May 2012 13:48:11 GMT+01:00 To: undisclosed-recipients:; Subject: Crystallographic Software Fayre (ECM27, Bergen) Dear all, thanks to the local organizers, there will be a Crystallographic Software Fayre at the ECM27 meeting in Bergen (Norway). Authors of of academic and/or open-source software can present their new developments. The presentations should have a tutorial character with one or more practical examples. The available time slots can be seen on the website: http://www.cryst.chem.uu.nl/lutz/software_fayre.html (This website will be updated regularly) If you are interested, please send an e-mail with your name and a preliminary title of the presentation to Martin Lutz, m.l...@uu.nl. The time slots will be filled according to the first-come first-served principle. For information about the ECM27 congress (August 6-11, 2012), see: http://ecm27.ecanews.org With kind regards, Martin (Please forward this e-mail to anyone, who might be interested.) -- Martin Lutz Crystal and Structural Chemistry Bijvoet Center for Biomolecular Research Faculty of Science Utrecht University Padualaan 8 3584 CH Utrecht The Netherlands Tel. [+31] 030-2533902 Fax [+31] 030-2533940 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] error popup with imosflm 1.0.6 despite valid executable MOSFLM_EXEC for mosflm 7.0.8
Hi folks This problem arises because I inadvertently included the versions of MOSFLM_EXEC that require X11 libraries in the iMosflm distribution (for Linux only - Macs and Windows were okay) - iMosflm doesn't need these. I've put fixed binaries on the Mosflm download site for Linux - http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver708/pre-built/mosflm_linux_32_noX11.zip and http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver708/pre-built/mosflm_linux_64_noX11.zip If you haven't had this problem you don't need to download the new copies. On 15 Jun 2012, at 16:10, hari jayaram wrote: Hi, I just installed imosflm 1.0.6 and the associated mosflm 7.0.8. I can run the mosflm executable by itself . Yet when imosflm starts it gives me an error popup iMosflm cannot run /home/hari/imosflm_download/1.06/imosflm/bin/mosflm. And then gives me the output from the running of the mosflm executable BFONT COLOR=#FF000:/...etc I have chmod-ed +x the MOSFLM_EXEC mosflm and it runs quite well on the shell. I also have an older imosflm and mosflm that work..any ideas why I get the error popup . I have a feeling its something that bleeding through my .bashrc file because it complains that some Postgres library is not there in the path further down after it gives the header from the mosflm executable output. This postgres error msg may be coming from something else being sourced. Help in troubleshooting will be greatly appreciated I am attaching a screenshot. Thanks for your help Hari imosflm-1.0.6-wrror-popup.png Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] High Rfree values and using Bruker detector w/ iMosflm
Hi Annette Mosflm can only read Bruker images correctly after they have been converted with frm2frm (available from Bruker) - this program unwarps them and writes them in a format that Mosflm can understand. On 25 Jun 2012, at 17:25, Annette Medina Morales wrote: Also, I have recently tried using iMosflm to refine the data but using the .sfrm images from the Bruker detector is problematic since I get an Application error that reads invalid command name and an Image read error that reads Error reading image header. Message from Mosflm is error reading record 33: check image is correct size. Does anyone have any advice on how to correct this since I understand that iMosflm is supposed to be able to read Bruker .sfrm images? Thanks! Annette Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] Release of iMosflm 1.0.7 and Mosflm 7.0.9
Dear all We wish to announce the release of the latest versions of iMosflm and Mosflm, downloadable via our web-pages at http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ These address a number of bugs and inconveniences that have been brought to our notice following the release of iMosflm 1.0.6 and Mosflm 7.0.8, especially: • Fixed the solution picking code in autoindexing (broken in 1.0.6) • Improved rendering of Pilatus images in Image Display • Ensure the user's choice to use Scala in preference to Aimless for scaling persists between sessions • The addition of the image_template in the XML for the bad spots response now means iMosflm 1.0.7 requires iMosflm 7.0.9 • Ensure the 'Add images' menu can be resized to show a longer list of files directories by moving the 'Selected images' only checkbox down to final row. • Add traps to prevent 'Index' button being clicked if image number(s) are present but no spot finding has been done. • Ensure the MTZ filename is updated when toggling between sectors. • Add ROFF and TOFF to the refined parameter checking. • Fixed typographical error in the path to baubles when running Pointless. • Do not require the scaling programs to be in CBIN as CCP4_BIN is in the PATH. • Save the Strategy file as soon as the yellow, cross-hatched sector is plotted after the Auto-complete calculation. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] Master in Crystallography and Crystallisation?
Hi folks First off, apologies to all who are not members of the BCA, since this is a question for the BCA members amongst you - I asked BCA to send out an advert for this course, and their admin people say they have done so - but I haven't received it, so I was wondering if anyone had got it? If you are a member and either have or have not received it, could you let me know asap? PLEASE don't reply to the BB, reply to me directly! BTW, the URL for the course is http://lafactoria.lec.csic.es/mcc/ Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Process multiple data sets
Hi I'd process (i.e. index, refine, integrate) each data set individually, check that (at least) they all have the same crystal system, then combine the datasets using Pointless. Then scale with Aimless. Of course, I'd use Mosflm/Pointless/Aimless rather than HKL, but that's another question (pace, ZO, WM, MM!) On 1 Aug 2012, at 14:08, Uma Ratu wrote: The data sets were collected from the same crystal by scan collecting 40 frames from each section. The space group of this crystal is P2. My guess that I may have to index and integrate each set indivadually, and then scale them together. Thanks Uma On Wed, Aug 1, 2012 at 9:01 AM, Machius, Mischa Christian mischa_mach...@med.unc.edu wrote: Not much info to go by... Anyway, if the program 'goes crazy' you either have very different exposure levels, radiation damage leading to non-isomorphism, or you have a trigonal space group (P3xxx or P6xxx) and forgot to make sure all batches are indexed the same way. If you have translated your crystal between batches, HKL2000 won't of course be able to process all batches in one go. If you haven't touched the crystals at all, and alln-in-one processing doesn't work, the parameters at the end of one batch may not be accurate to start off a new batch, which is mostly due to inaccurate goniostats. In that case, you will need to process the batches individually and them combine them during scaling. Hope that helps. MM On Aug 1, 2012, at 8:50 AM, Uma Ratu wrote: Dear All: I collected 5 data sets from one crystal and would like to process them together. Here is how I did: In HKL2000, load the all data sets. Index each set. When I try Intergrate, the program automatically go through the whole data sets there, and do not go through. I then process data sets by loading one at each time. Index, intergrate and scale all go through very smoothly. But when I put them together, the program just goes crazy. Thank you for advice Uma Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Process multiple data sets
Hi I don't think Phil or I are saying that HKL is not a good tool to use in this case - but (*) I develop Mosflm, so I have a certain bias. (*) As far as Pointless and Aimless are concerned, to get the best out of them you need to have some geometrical information that the authors of HKL have not included in the reflection output files. Mosflm (and XDS Saint...) do give this information. So if you want to use Pointless and Aimless at any point, it may be better to use a different integration package than HKL (bearing in mind Phil's point about checking your symmetry with Pointless)... On 1 Aug 2012, at 16:16, Uma Ratu wrote: Please correct me if I am wrong: The HKL is not good to combine multiple data sets, even they are come from the same crystal? With HKL, I also tried this way: Index, integrate each data set individually, they all have the same space group. Then scale them together. Still, the graph from scale of the whole set look very wired compared with those of individuals. Uma On Wed, Aug 1, 2012 at 9:55 AM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Note that neither Aimless nor Scala will do a particularly good job at scaling data from Denzo or Scalepack, since the output files from Scalepack are missing essential geometrical information. They work well with data from Mosflm or XDS (or Saint) (although AFAIK the XDS Saint scaling programs work perfectly well) However, Pointless may still be useful to check that you have indexed them consistently Phil On 1 Aug 2012, at 14:36, Harry Powell wrote: Hi I'd process (i.e. index, refine, integrate) each data set individually, check that (at least) they all have the same crystal system, then combine the datasets using Pointless. Then scale with Aimless. Of course, I'd use Mosflm/Pointless/Aimless rather than HKL, but that's another question (pace, ZO, WM, MM!) On 1 Aug 2012, at 14:08, Uma Ratu wrote: The data sets were collected from the same crystal by scan collecting 40 frames from each section. The space group of this crystal is P2. My guess that I may have to index and integrate each set indivadually, and then scale them together. Thanks Uma On Wed, Aug 1, 2012 at 9:01 AM, Machius, Mischa Christian mischa_mach...@med.unc.edu wrote: Not much info to go by... Anyway, if the program 'goes crazy' you either have very different exposure levels, radiation damage leading to non- isomorphism, or you have a trigonal space group (P3xxx or P6xxx) and forgot to make sure all batches are indexed the same way. If you have translated your crystal between batches, HKL2000 won't of course be able to process all batches in one go. If you haven't touched the crystals at all, and alln-in-one processing doesn't work, the parameters at the end of one batch may not be accurate to start off a new batch, which is mostly due to inaccurate goniostats. In that case, you will need to process the batches individually and them combine them during scaling. Hope that helps. MM On Aug 1, 2012, at 8:50 AM, Uma Ratu wrote: Dear All: I collected 5 data sets from one crystal and would like to process them together. Here is how I did: In HKL2000, load the all data sets. Index each set. When I try Intergrate, the program automatically go through the whole data sets there, and do not go through. I then process data sets by loading one at each time. Index, intergrate and scale all go through very smoothly. But when I put them together, the program just goes crazy. Thank you for advice Uma Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] d*trek
Hi It should do. Jim will know for sure. On 23 Aug 2012, at 23:08, jlliu liu wrote: My real questions is: Does d*trek recognize the img file format collected at ALS or APS and process the data? Thanks! On Thu, Aug 23, 2012 at 6:00 PM, jlliu liu jlliu20022...@gmail.com wrote: Do anybody know if d*trek can process data collected from APS? Thanks a lot in advance. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] imosflm, bad predictions - solved!
Hi This was indeed the issue - on this beamline (I think it's 19-ID-D at APS, but I'm waiting on confirmation of this) the phi axis rotates the opposite way to usual, so Mosflm needs to be told. (As an aside, in the most recent release we automatically check the serial number of the detector to see if it's in a list where we know this is done - but our internal list is not comprehensive [and some detectors don't record this information in a useful way...]. We'll add the detector from Jan's dataset to our list) The best way to check if this is the problem is to - (1) index in the normal way using two images. If (a) the predictions don't look right and (b) the sigma(x,y) (the column to the right of the cell dimensions) is more than you would normally expect (say, for a good looking crystal if it's more than ~0.1mm) (c) the cell is not close to what you expect then this may be the issue. (2) Index from the first image chosen by Mosflm and see if the predictions match and sigma(x,y) is much smaller than in (1b) (3) Index from the second image chosen by Mosflm and check predictions (for this image) and sigma (x,y) If (2) and (3) look good but (1) is bad, there's a good chance the phi is rotating the opposite way to that which Mosflm expects. In this case, check the setting box in the Settings - Experiment Settings - Experiment window and try (1) again - remembering that if you do this you need to repeat the spot search. The orientation of the displayed image has no bearing on the beam centre used by Mosflm as read from the image header. Some beamlines record the beam centre in the Denzo frame, some in the Mosflm frame, some in both (and possibly some do in some other frame - there's a wide choice!). In iMosflm, the image is displayed with respect to the internal Mosflm frame - so it's consistent with how we treat the images computationally. Other programs (probably?) display the image as thee detector software displays it. On 18 Oct 2012, at 22:12, Ben wrote: I had a very similar problem with data collected on a particular beamline. The issue was that I had to reverse the spindle direction in imosflm settings. Also, when I load data from this beamline into imosflm the program rotates the images by 90 degrees for some reason (this does not happen in HKL2000). Because of this rotation, the beam center that I used in HKL2000 was different than the beam center position for imosflm. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] relations between groups and subgroups?
Hi The relations are in International Tables Vol A; in the 2006 edition you find them in section 9.2 by P.M. de Wolff, pp 750 - 755; the transformations for the 44 characteristic lattices (or lattice characters...) are in Table 9.2.5.1. In Mosflm, the autoindexing penalties are based on the differences between the result of the transformations applied to the real triclinic basis and what you would get if the result was perfect. On 13 Nov 2012, at 09:55, vincent Chaptal wrote: Dear all, I am not sure I understand point groups and relations between groups and subgroups anymore, and would appreciate some guidance. I was under the impression that all point groups were related to an original P1 cell, and that by applying specific lattice symmetries, one could get higher point groups. Thus, if one knows the symmetry operators, one could jump from one point group to another. Inspection of the reflections can then determine the real point group and space group. At least that's what I thought Mosflm was doing? Am I correct? P1 +(symm-opp)C2 + (symm-opp2)P3 same P1 +(symm-opp3) P2 + (symm-opp4)P222 If that's the case, could someone point to me where to find these symmetry opperators (International tables?), because it's not obvious to me. Or are these relations between groups and subgroups only true for certain crystals where the cell parameters are specific, and allows a symmetry operator to generate a higher symmetry point group? Thank you for your help. vincent Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] Yesterday (was) Today yesterday...
Hi all Since this is a discussion by protein crystallographers about a possible standard, I will expect a consensus (or several conflicting consensuses*) to be reached sometime after I have retired... I'll look forward to the discussions spilling out into the CCP4 Study Weekend. * Since consensus was originally a fourth (not second) declension Latin noun, the nominative and accusative plurals are also consensus (but with a long u). Consensi is just wrong... Have a nice break! On 21 Dec 2012, at 14:45, Bosch, Juergen wrote: Hi David, on a computer I agree 20121221 is the way to go (but even then you could still do ls -lta), but on Eppendorf tubes that is precious real estate for other important numbers or letters hence the 12d21 :-) And thanks for catching my double J this was just a test if somebody would actually read what I wrote :-) And the corrected values were indeed right, aka following the simple rule I mentioned. Jürgen On Dec 21, 2012, at 9:15 AM, David Schuller wrote: On neither case does an alphanumeric sort coincide with a chronological sort. The obvious solution is to petition to have the months renamed alphabetically. On 12/21/12 03:23, Tom Murray-Rust wrote: Hi Juergen, Your scheme as printed has two J's - so January and July are indistinguishable! I would suggest the letters should instead be JFMAYULGSOND. On 21 Dec 2012, at 01:52, Bosch, Juergen jubo...@jhsph.edu wrote: May I introduce you to another fool proof way: 12d12 ... J, F,M,A,Y,J,U,G,S,O,N,D for the months, simply first letter, but if taken move to the second letter etc. -- === All Things Serve the Beam === David J. Schuller modern man in a post-modern world MacCHESS, Cornell University schul...@cornell.edu .. Jürgen Bosch Johns Hopkins University Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research Institute 615 North Wolfe Street, W8708 Baltimore, MD 21205 Office: +1-410-614-4742 Lab: +1-410-614-4894 Fax: +1-410-955-2926 http://lupo.jhsph.edu Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
[ccp4bb] Coot's hidden talents!
Hi Just noticed this - http://www.bbc.co.uk/news/uk-20978904 do we know the artist? He has just moved to Cambridge... Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] need some suggestions for crystallization
Hi David try going back to the one that started it all,* myoglobin, a recipe is at http://www.rigaku.com/products/protein/recipes (* feel free to argue about this) On 4 Feb 2013, at Mon4 Feb 16:03, David Roberts wrote: So, I know I say this every time I post on this board, but here it goes again. I'm at an undergrad only school, and every 2 years I teach a class in protein crystallography. This year I'm being super ambitious, and I'm going to take a class of 16 to the synchrotron for data collection. It's just an 8 hour thing, to show them the entire process. I'm hoping that we can collect 5-6 good data sets while there. I would like them to grow their own crystals, and go collect data. Then we'd come back and actually do a molecular replacement (pretty easy/standard really). Just to get a feel for how it works. The protein I do research on is not one that I would push on this, as the crystals are hard to grow, they are very soft, and the data just isn't the best (resolution issues). I do have a few that will work on my proteins, but I was thinking of having others in the class grow up classic proteins for data collection. Obviously lysozyme is one, but I was wondering what other standard bulletproof conditions are out there. Can you all suggest some protein crystallization conditions (along with cryo conditions) for some commercially available proteins? I'm looking to get 6-8 different ones (and we'll just take them and see how it goes). I wouldn't mind knowing unit cell parameters as well (just a citation works, I can have them figure it out). I have about 7 weeks to get everything grown and frozen and ready to go. Any help would be greatly appreciated. It always amazes me how helpful this group is. Thank you very much. Dave Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] need some suggestions for crystallization
I don't know. Is there? On 4 Feb 2013, at Mon4 Feb 16:15, Jayashankar wrote: Dear Powell, Isn't it there a way to data mine the PDB or the other repository source for the time/duration/days of the crystals obtained. Dr. Jayashankar Selvadurai Hannover Germany On Mon, Feb 4, 2013 at 5:10 PM, Harry Powell harry@mrc- lmb.cam.ac.uk wrote: Hi David try going back to the one that started it all,* myoglobin, a recipe is at http://www.rigaku.com/products/protein/recipes (* feel free to argue about this) On 4 Feb 2013, at Mon4 Feb 16:03, David Roberts wrote: So, I know I say this every time I post on this board, but here it goes again. I'm at an undergrad only school, and every 2 years I teach a class in protein crystallography. This year I'm being super ambitious, and I'm going to take a class of 16 to the synchrotron for data collection. It's just an 8 hour thing, to show them the entire process. I'm hoping that we can collect 5-6 good data sets while there. I would like them to grow their own crystals, and go collect data. Then we'd come back and actually do a molecular replacement (pretty easy/standard really). Just to get a feel for how it works. The protein I do research on is not one that I would push on this, as the crystals are hard to grow, they are very soft, and the data just isn't the best (resolution issues). I do have a few that will work on my proteins, but I was thinking of having others in the class grow up classic proteins for data collection. Obviously lysozyme is one, but I was wondering what other standard bulletproof conditions are out there. Can you all suggest some protein crystallization conditions (along with cryo conditions) for some commercially available proteins? I'm looking to get 6-8 different ones (and we'll just take them and see how it goes). I wouldn't mind knowing unit cell parameters as well (just a citation works, I can have them figure it out). I have about 7 weeks to get everything grown and frozen and ready to go. Any help would be greatly appreciated. It always amazes me how helpful this group is. Thank you very much. Dave Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing) Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] Pilatus 300K CBF to Oxford Diffraction format convert
Hi Tim I've looked at these images and they differ from the normal 6M images (miniCBF) in that they are a stab at writing fullCBF, i.e. with imgCIF style data content - unfortunately, there are a few syntax errors which need fixing before programs that use the header information (like Crysalis Pro, inter alia;-)) can do much useful with them. XDS (and any other programs that ignore header information) should be able to process these provided the correct beamline values are supplied. On 6 Feb 2013, at Wed6 Feb 11:19, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Jose, it is odd the software should read 6M but not 0.3M Pilatus files - the format is probably the same, only the dimensions would differ - at least that's my guess. While you are waiting you might start processing your data with XDS, which is well suited also for small molecules crystals. If your cell is small, I recommend turning of refinement during the integration step (REFINE(INTEGRATE)=!) and only refine all parameters during the CORRECT step. You need to make sure the spots are correctly predicted on the FRAME.cbf, i.e. the cell from indexing is close enough to the correct one. Best wishes, Tim On 02/06/2013 11:35 AM, Jose Trincao wrote: Dear all, sorry for the semi-off-topic but I'm trying to help convert some diffraction images and this seemed like a good place to ask. We are trying to process some images collected on a Pilatus 300K with the Crysalis Pro software (small molecule) but it seems to only be able to read Pilatus 6M frames. Is there an easy way to convert the 300K dbf files to something readable by Crysalis? (Oxford Diffraction, marCCD, Rigaku or Bruker AXS-SAXI). Thanks! Jose This email and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorized recipient of the addressee, please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to this email. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Research Complex at Harwell. There is no guarantee that this email or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. We use an electronic filing system. Please send electronic versions of documents, unless paper is specifically requested. This email may have a protective marking, for an explanation, please see: http://www.mrc.ac.uk/About/informationandstandards/documentmarking/ index.htm. - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFREjxFUxlJ7aRr7hoRAnT6AJoCPwjWp5eDrIQ0JevYl/98Bh2ixQCglIQ+ 7e+OerAR3x+GVUejoXmVcQM= =ZDOJ -END PGP SIGNATURE- Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] Measure Cell option in imosflm
Hi Richard I'm afraid it doesn't exist at the moment. It could be added if there's sufficient demand for it. On 25 Feb 2013, at 12:57, Bayliss, Richard (Dr.) wrote: Does anyone know how to access the 'Measure Cell' function in iMosflm? This function in ipmosflm allowed you to click on a pair of spots, then input the number of diffraction orders, to output a rough measure of the cell length. Any help appreciated! Thanks Richard = Dr Richard Bayliss, Reader in Structural Biology Department of Biochemistry Henry Wellcome Building University of Leicester Lancaster Road, Leicester LE1 9HN Tel: 0116 2297100 Web: http://www2.le.ac.uk/departments/biochemistry/staff/richard-bayliss/research Elite Without Being Elitist Times Higher Awards Winner 2007, 2008, 2009, 2010, 2011 Follow us on Twitter http://twitter.com/uniofleicester Harry -- 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] compiling Fortran 77 code on a Linux box (using gfortran ?)
Hi Fred If you look very carefully at your Fortran code you will probably find a small error/inconsistency that g77 allowed but gfortran picked up on or compiled as written rather than as intended. My move from g77 to gfortran when building Mosflm (which is moderately large) was pretty painless, but I did find that when I got errors of this type the fault was when the code did not adhere to standards. Generally speaking, gfortran adheres to the current Fortran standards more strictly than g77. Recent versions give Mosflm executables that are within a few percent of the performance that I get with the Intel Fortran ifort compilers (actually, sometimes faster, sometimes slower)- I've checked this on both Mac and Linux. I use gfortran for development, ifort for checking things are still okay, and also run an old Linux box with g77 for further checking in case I've missed something earlier. My Windows executable of Mosflm still uses g77 (the mingw cross-compiler run on OSX). However, there are persistent reports out there of people who find their code runs much faster when compiled with ifort - so I guess this is very much code dependent. I can have a look at your code if it would help. HTH On 6 Mar 2013, at Wed6 Mar 09:48, vellieux wrote: Hello, For those who still know the Fortran language and its Fortran 77 variant, I used to have a g77 compiler here (Linux box), and now on the new box it's no longer g77 but gfortran. When compiling Fortran77 code (these are the flags used for compilation: -o ../bin/$1 -std=legacy -Wno-globals -w -O3 -malign- double -funroll-loops -ffast-math -fno-second-underscore $1.f , followed by the libraries on that same compile line) I get errors (at run time) of the type: At line 138 of file program.f (unit = 6, file = 'stdout') Fortran runtime error: Missing initial left parenthesis in format When looking at this code (which compiled perfectly well using g77 - I removed the flag -fno-globals which doesn't seem to exist any more in gfortran) the Fortran code that I see appears to have all parentheses in the correct places. Any idea of what must be done with existing Fortran 77 code in order to get it to compile and run with gfortran ? Otherwise any idea which compiler should be used to compile Fortran 77 code ? Thanks in advance, Fred. -- Fred. Vellieux (B.Sc., Ph.D., hdr) ouvrier de la recherche IBS / ELMA 41 rue Jules Horowitz F-38027 Grenoble Cedex 01 Tel: +33 438789605 Fax: +33 438785494 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] first use of synchrotron radiation in PX
Hi Not sure if this is strictly speaking the first protein *solved* on a synchrotron, but I think this is the first report of shooting protein crystals at a synchrotron in the widely available literature - http://www.pnas.org/content/73/1/128.full.pdf+html Phillips J C, Wlodawer A, Yevitz M M and Hodgson K 0 1976 Proc. Nat. Acad. Sci. USA 73 128-32 Applications of synchrotron radiation to protein crystallography: Preliminary results On 13 Mar 2013, at 14:38, Alan Cheung wrote: Hi all - i'm sure this many will know this : when and what was the first protein structure solved on a synchrotron? Thanks in advance Alan -- Alan Cheung Gene Center Ludwig-Maximilians-University Feodor-Lynen-Str. 25 81377 Munich Germany Phone: +49-89-2180-76845 Fax: +49-89-2180-76999 E-mail: che...@lmb.uni-muenchen.de Harry -- 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] How to calculate data collection strategy manually?
Hi Saleem I can strongly recommend reading and digesting this paper (open access from the IUCr website, so you don't need a subscription) - Dauter, Z., Acta Cryst. (1999). D55, 1703-1717 - Data-collection strategies http://journals.iucr.org/d/issues/1999/10/00/ba0020/ba0020.pdf Once you've read it, the issues that you should take into account when devising your strategy shuld be apparent. Of course, all the best integration programs also have strategy options built into them as well if you decide not to do it manually after all On 26 Mar 2013, at 12:25, saleem raza wrote: How to calculate data collection strategy manually. I was wondering if any one can answer this, if we have to calculate data collection strategy manually? regards Saleem 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] process data from two crystals in-house data
Hi I'd just integrate them individually with Mosflm, then merge the two MTZ files into one with Pointless(*), then scale with Aimless. (*) pointless hklin first.mtz second.mtz hklout pointless.mtz aimless hklin pointless.mtz hklout aimless.mtz should do the trick - pointless even works with a wild card if you have many mtz files to merge (not sure how many many can be, but it's certainly a lot more than 10), e.g. pointless hklin part_*.mtz hklout pointless.mtz Dead easy with normal CCP4 programs, RTM for pointless for further details. You can even do this in ccp4i *really easily*! On 28 Mar 2013, at Thu28 Mar 10:08, S. Thiyagarajan wrote: Dear all I have two data sets, 75 frames each from crystals of the same protein - same cell parameters/space group (P4). I could process them seperately each yielding 90% completeness but with poor multiplicity ( 2 ) If I merge the data sets using CAD, I loose the data reduction statistics of the combined data set. I do not have HKL2000. Which (free) tool can handle two different diffraction data sets, process them together to give a single final data statistics. Thanks and regards Thiyaga S. Thiyagarajan Centre of Excellence in Bioinformatics School of Biotechnology Madurai Kamaraj University Madurai - 625021 Ph: +91-9159224881 (cell) 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] 2Theta data set solving problem
Hi Navin I'll assume you are using iMosflm from the CCP4 suite. Have you tried increasing the resolution in the Processing Options window, under the Processing tab? The option to display resolution rings and change the resolution by dragging the ring does not work at present in iMosflm. On 9 Apr 2013, at Tue9 Apr 12:41, navin narayanan wrote: Hello everybody, We have a diffraction data set from home source with 2theta at 20deg. But we are not able to solve the data set using CCP4 suite. The software is picking up only the lower resolution data but not the higher resolution data points. Also we are not able to merge data two sets, one with 2theta at 0deg and the other with 2theta at 20deg. Is there anyway to solve the data. Any help will be truly appreciated. Thank you in advance. Navin V Narayanan 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] CCP4 Update victim of own success
Hi I'd second NX; you can install a free server for one or two (I think - I only use one at a time ;-)) concurrent connections and a local client, then it's almost like being there. On 11 Apr 2013, at 22:54, Dyda wrote: Or nx, which works very well, although the server has to be installed at the remote end and client on the local. www.nomachine.com Fred [32m*** Fred Dyda, Ph.D. Phone:301-402-4496 Laboratory of Molecular BiologyFax: 301-496-0201 DHHS/NIH/NIDDK e-mail:fred.d...@nih.gov Bldg. 5. Room 303 Bethesda, MD 20892-0560 URGENT message e-mail: 2022476...@mms.att.net Google maps coords: 39.000597, -77.102102 http://www2.niddk.nih.gov/NIDDKLabs/IntramuralFaculty/DydaFred ***[m 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] CCP4 GUI
Hi Maybe any parameter setting unchanged from the values in the $CCP4/ccp4i/tasks/*.def file should be internally flagged as being at the 'default value' - resulting in them _not_ being written to the com-file? This way any potential change in defaults inside the actual program would have immediate effect, even if the CCP4i hasn't been updated yet. This is a _really_ good idea for another reason. There are programs which determine processing parameter values dyamically, based on what they have actually been presented with - UNLESS those values have been input by the user, who is assumed to know better. If an interface (e.g. ccp4i) sets the value to a default, the program really has no way of knowing that it was the interface and not a user who knows their data which has input the value. Just my two ha'porth... Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] anomalous signal
Hi In the same way the Toyota MRD-2 doesn't sell in France? MRD would indeed be a poor name. For French scientists it might be difficult to get funding for an MRD experiment Regards Yves -- Prof. Yves Muller Phone: +49-(0)-9131-8523082, 8523081 Lehrstuhl fuer BiotechnikFAX: +49-(0)-9131-8523080 www.biologie.uni-erlangen.de/biotechnik Institut fuer Biologie Friedrich-Alexander-Universität, Erlangen-Nuernberg Im IZMP, Henkestrasse 91, D-91052 Erlangen Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] number of MTZ files input to scaleit
Hi folks silly question, I know, and I'm sure this must have been answered before, but I want to put 10+ datasets into the same file and get scaling statistics between them. I find that SCALEIT is happy to do the scaling once all the datasetsa re together (according to the man page it's okay with 20) but CAD will only let me put 9 datasets in an MTZ file. Do I have to run CAD twice (or more...) to get all my datasets together? Or is there some other way that I've missed? Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] Release of Mosflm version 7.0.1 iMosflm 0.5.3
Hi folks a sharp-eyed user has noticed a bug in the Windows version of iMosflm 0.5.3; this does not affect any other version. If you have already downloaded the Windows version, you should replace the file imosflm.tcl in the top-level imosflm folder with this file - http://www.mrc-lmb.cam.ac.uk/harry/imosflm/downloads/imosflm.tcl NOTE that this is _not_ the file of the same name in the src folder. I've fixed this in the imosflm.zip file so any further downloads will not display this bug. Sorry about this! Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] mosflm and APS BM17
Hi I'd guess from the input file that the beam centre may be defined in a different reference frame to that which Mosflm expects in the image header; other possibilities are that the distance, wavelength, or something else (!) is wrong. Indexing is critically dependent on having the beam centre, distance and wavelength all being pretty close to the true values, though some indexing routines allow more latitude than others. My understanding (IMWBW) is that other programs (such as XDS or HKL2000) don't use the information in the image headers, and expect the parameters to be supplied by the user. With Mosflm, we try to make the user's life easier by trusting this information, especially from images collected at synchrotron beamlines; sometimes this trust is not warranted, and the user has to intervene! processing data collected on APS beamline BM17 on a MAR165 detector causes unexpected troubles. Even though the crystals are well-diffracting and the spots are sharp and well-resolved, indexing only works with a certain selection of frames, the refinement the goes totally hairwire. Probalby just a parameter or so set wrong. My input file in the attachment. The last three lines do not make much of a difference. Any ideas? Thanks! Cheers Jan mosflm.in: detector marccd directory ../Images template Image_0###.img image 001 nullpix 1 separation 0.95 0.95 close !LIMITS XMIN 0 XMAX 165 YMIN 0 YMAX 165 xscan 2048 yscan 2048 !SIZE 2048 2048 !PIXEL 0.07934 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] diffraction images images/jpeg2000
Hi Lossy compression should be okay, provided that the errors introduced are smaller than those expected for counting statistics (assuming that the pixels are more-or-less independent) - i.e. less than the square-root of the individual pixel intensities (though I don't see why this can't be extended to the integrated reflection intensities). So it's more important to accurately retain your weak pixel values than your strong ones - an error of ±10 for a pixel in a background count where the background should be 40 is significant, but an error of ±10 for a saturated pixel on most detectors (say, about 64K for a CCD) wouldn't affect anything. On the question of lossy compression, I think we'd have to ask some data reduction guru's how much the noise would affect the data reduction. I suspect that the main problem is that the noise added would be correlated across the image and would therefore affect the background statistics in a non-trivial way. Although the intensity measurements may not be badly affected the error estimates on them could be... Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] diffraction images images/jpeg2000
Wow. I don't know about the rest of you, but I got told three times. Gerard is, of course, right about pixel non-independence (think point spread function, among other things), and I wouldn't care to argue statistics with him, but as far as I know (and I could well be wrong) most of the integration programs out there _do_ use counting statistics (i.e. Poisson statistics) at least as a first approximation for the random error in measurement; this may be modified by some detector inefficiency factor (See Borek, Minor Otwinowski, Acta Cryst (2003) D59 2031 - 2038), but it's still there and being used by everyone, nonetheless. Having said that, regarding the storage of images, my personal feeling is that there's no real point in using a lossy compression when there are good lossless systems out there. I also think that almost no-one would ever bother to reprocess deposited images anyway; my guess is that unusual structures would be detected by other means, and that examining the original images would rarely shed light on the problem. I think we need to stop and think right here. The errors in pixel values of images are neither Poisson (i.e. forget about taking square roots) nor independent. Our ideas about image statistics are already disastrously poor enough: the last thing we need is to make matters even worse by using compression methods based on those erroneous statistical arguments! With best wishes, Gerard. -- On Fri, Aug 24, 2007 at 01:20:29PM +0100, Harry Powell wrote: Hi Lossy compression should be okay, provided that the errors introduced are smaller than those expected for counting statistics (assuming that the pixels are more-or-less independent) - i.e. less than the square-root of the individual pixel intensities (though I don't see why this can't be extended to the integrated reflection intensities). So it's more important to accurately retain your weak pixel values than your strong ones - an error of ±10 for a pixel in a background count where the background should be 40 is significant, but an error of ±10 for a saturated pixel on most detectors (say, about 64K for a CCD) wouldn't affect anything. On the question of lossy compression, I think we'd have to ask some data reduction guru's how much the noise would affect the data reduction. I suspect that the main problem is that the noise added would be correlated across the image and would therefore affect the background statistics in a non-trivial way. Although the intensity measurements may not be badly affected the error estimates on them could be... Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH -- === * * * Gerard Bricogne [EMAIL PROTECTED] * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * === Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] Mosflm v 7.0.1 Mac Intel pre-built executable.
Hi folks If you've recently downloaded a pre-built copy of Mosflm version 7.0.1 for Intel Mac (including the universal binary) and been surprised by the need for libgfortran.1.dylib, read on. Otherwise, feel free to ignore this! It seems my attempts to produce a statically linked OS X executable with gfortran weren't as successful as I thought! Although the executable was (in a logical sense) statically linked, the linker put information in the header suggesting that it required the dynamic library. This is wrong and may be viewed as a linker bug. However, I've now sorted out the problem and produced executables which do link the libgfortran statically, and these replace the earlier copies. If you've managed to run Mosflm version 7.0.1 on an Intel Mac there is no need at all to download this executable, so you can ignore this. However, if you've been stymied in your attempt to run it by being told that /sw/lib//gcc4/lib/libgfortran.1.dylib doesn't exist, it is probably worthwhile downloading this new executable. have a nice weekend! Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] ipmosflm
Hi Eric You need to make sure g77 is properly installed on your system. For any FC system, if you install g77 from an RPM (e.g. see your FC install DVD/CD/website) you should get this file in the right place. If you don't want the whole compiler there, you should be able to get round this on an FC system by just installing the libg2c.so file explicitly, perhaps from an RPM. It may be that the correct file is on your system, but either called something else (similar, e.g. libg2c.so.0) and not linked correctly to libg2c.so, or it isn't in your LD_LIBRARY_PATH; on my systems it's in the directory /usr/lib (on others it's found in /usr/local/lib). I've put a copy on the Mosflm v 7.0.1 pre-built site (I haven't put a link on the page for it, but you can get it by following this - http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver701/pre-built/suse-libg2c.so Personally, I really hate shared objects and have tried (oh, how I've tried!) to eliminate them from Mosflm distributions, but they seem to sneak in when I'm not looking... Hi, I try to install the latest version of ipmosflm and the small display version on my laptop (fedora 7). I got the following error message when I try to run it: $./mosflm_linux_suse_SD mosflm_linux_suse_SD: error while loading shared libraries: libg2c.so.0: cannot open shared object file: No such file or directory It might not related to the program. However, please advise. Thx. Eric Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] pointless (1.2.0) and enantiomorphic SG's
Of course, you may need to re-index even if you have the right space group... Offering a selection of space groups compatible with a point group will not require reindexing. Some point groups of course permit reindexing, but one hope you have chosen a consistent set as you combine data sets into an MTZ file - pointless and the GUI both offer ways to check this. Phasing cannot be carried out till you have chosen a spacegroup, and any existing phase associated data should probably be weeded out as part of a Assign Spacegroup function. Eleanor Kevin Cowtan wrote: This is great! But before we all get carried away, a quick reality check is in order. This isn't an area I've thought about, but my limited understanding raises the following issues Given that an MTZ file contains a cell, an indexing of the data, and possibly phases involving a choice of origin, the use of an MTZ file immediately implies that some decision has been made about the spacegroup. Selecting a different spacegroup from a list of possibilities may involve reindexing, and/or changing origin/enantiomorph dependent properties such as phases and HLs. It would be possible for an MTZ file to say something like this: 'This file is generated assuming spacegroup X. Spacegroups X1, X2, X3, X4, X5 are also possible.'. It should also be possible to compute on the fly whether a particular column type needs to be modified for a different spacegroup. How will we present this in user interfaces? As a starting point, until a spacegroup has been settled upon, the user will need the option of picking the spacegroup after having selected the MTZ. This means potentially a reindexing step added to every single task - messy. As an intermediate, being able to change the 'currently selected' spacegroup as a separate task would be an improvement. Phil Evans wrote: I agree On 9 Nov 2007, at 13:50, Eleanor Dodson wrote: As I often say!!! The mtz format should carry point group and alternate SGs - then be upgraded when youknow the correct SG.. Eleanor Phil Evans wrote: It just picks the first in the list, to store in the output MTZ file, which can only handle one (92 96) Phil On 8 Nov 2007, at 22:26, Bryan W. Lepore wrote: when pointless (1.2.0) finds enantiomorphic SG's, what is the criterion for 'Selecting' one over the other? e.g. i ran pointless on some tetragonal data, and the enantiomorphs SG92/SG96 are selected as strong candidates Spacegroup TotProb SysAbsProb Reindex Conditions P 41 21 2 ( 92)0.956 0.956 00l: l=4n, h00: h=2n (zones 1,2) P 43 21 2 ( 96)0.956 0.956 00l: l=4n, h00: h=2n (zones 1,2) ... then pointless reports : Selecting space group P 41 21 2 as solutions are enantiomorphic Best Solution space group P 41 21 2 ... is that b/c pointless can only report one, and SG92 came up first? -bryan
[ccp4bb]
Hi I don't know about reviews, but there were a couple of papers a few years ago that might have clues in their references - Margiolaki et al, Acta Cryst D61, 423-432 (2005) Basso et al Acta Cryst D61, 1612-1625 (2005) On 13 Nov 2007, at 19:59, Marius Schmidt wrote: Somebody out there who could direct me to a nice review of protein powder diffractometry including the application of Rietveld refinement to such data. Any hint appreciated many thanks in advance Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood Blvd. Milwaukee, WI 53211 phone: +1-414-229-4338 email: [EMAIL PROTECTED] http://users.physik.tu-muenchen.de/marius/ Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] To bathe or not to bathe.
. These days scaling algorithms are good, the detectors are excellent, and very often it pays to employ a beam smaller than the x-tal. This, the non-uniformity of many synchrotron beams, and the systematic damage to crystals that we observe now with synchrotron sources cause serious systematic errors. We're forced to depend on good scaling and good detectors to get accurate measurements. Making the measurements in many different crystal orientations (redundancy) helps to smooth out these systematic errors. Nonetheless, it will always pay you to watch for EACH of these sources of error and to minimize them as best you can. Bob = Robert M. Sweet E-Dress: [EMAIL PROTECTED] Group Leader, PXRR: Macromolecular ^ (that's L Crystallography Research Resource at NSLS not 1) http://px.nsls.bnl.gov/ Biology Dept Brookhaven Nat'l Lab. Phones: Upton, NY 11973631 344 3401 (Office) U.S.A. 631 344 2741 (Facsimile) = Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] ccp4i integration task
Hi folks Can you reply directly to me rather than ccp4bb? I was wondering how many people out there actually use the integration task in ccp4i? We're trying to work out how much support it needs, and how it needs to be developed, so comments on usage, problems, etc. would all be gratefully received! Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] ccp4i integration task
Many thanks to everyone who took the time to reply! It will all be very helpful. On 27 Nov 2007, at 11:59, Harry Powell wrote: Hi folks Can you reply directly to me rather than ccp4bb? I was wondering how many people out there actually use the integration task in ccp4i? We're trying to work out how much support it needs, and how it needs to be developed, so comments on usage, problems, etc. would all be gratefully received! Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] scale data with multiple MTZ files
Hi There's a way to avoid having to do this - use the ADD sub-keyword when processing in Mosflm, so that the batch number for each image data is given an offset; see http://www.mrc-lmb.cam.ac.uk/harry/cgi-bin/keyword2.cgi?PROCESS Both the traditional X11 gui and the new iMosflm allow you to add an offset easily, allowing the subsequent CCP4 programs to work with multiple MTZ files produced by Mosflm. On 11 Jan 2008, at 09:49, Phil Evans wrote: There is an (possibly) easier way now in pre-release 1) Download install (manually) from the CCP4 pre-release site the program pointless and the ccp4i task interface 2) Use the Find or Match Laue Group option (under Data Reduction) to open the interface window to the program Pointless This will allow input of multiple MTZ files (or indeed files from XDS Scalepack), check them for consistent indexing if appropriate, and enforce unique batch numbers (a long-standing irritation). By default it will try to determine the Laue group space group, but it can also match space group indexing with a reference file, or just sort the files together (replacing sortmtz). 3) Put the output (HKLOUT) file into Scala (Scale and Merge intensities task) Note that Pointless ( Scala) are still (!) under development, and the versions in the next CCP4 release (or indeed pre-release) will be updates of these versions. Latest versions of Pointless Scala are also available from ftp://ftp.mrc-lmb.cam.ac.uk/pub/pre/ Phil On 11 Jan 2008, at 05:40, Roger Rowlett wrote: Huiying Li wrote: I tried to scale, using SCALA through CCP4i GUI, three blocks of data collected with one crystal (3 mtz files output from MOSFLM). The GUI has only one MTZ input slot. Which program can be used to combine the 3 unmerged mtz files together? CAD refused to handle these raw mtz files. Thanks in advance for any help. Huiying Using the CCP4 GUI, employ the following steps: 1. Open a Sort/Modify/Combine job and renumber your data sets (reset batch numbers option). A simple method is to add 1000 to the batch numbers for one data set and 2000 to the batch numbers for the second data set (assuming you have less than 999 frames of data output from MOSFLM.) 2. Open another Sort/Modify/Combine job and combine the renumbered MTZ files into one merged file. Click on Add File to add additional renumbered batches from step 1. Each batch of reflections will now have unique batch numbers. 3. Open a Scale and Merge Intensities task window. Select as your input the sorted and combined file output from step 2. In the Define Datasets section, choose Combine All Input Datasets into a Single Output Dataset. You can convert the scaled intensities to structure factors by checking the appropriate box. The combined datasets will not have monotonically varying R(merge) values across batches (1-1000, 1001-2000, 2001-3000) becuase of discontinuities in the data. However the merged datasets should have good overall statistics if appropriate for merging. Cheers, -- - --- Roger S. Rowlett Professor Colgate University Presidential Scholar Department of Chemistry Colgate University 13 Oak Drive Hamilton, NY 13346 tel: (315)-228-7245 ofc: (315)-228-7395 fax: (315)-228-7935 email: [EMAIL PROTECTED] Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] x ray data sets for teaching
Hi Jeremiah We (the Mosflm developers) use a mercury derivative HypF dataset collected on a Mar IP - there are things wrong with the crystal and the data collection, but it processes nicely (you can identify the problems easily), and you can solve the structure from the data; it's available at http://www.ccp4.ac.uk/autostruct/testdata/ - look for HypF, about half-way down the page. There are tutorials that go through the data with both the traditional X11 GUI and the new TclTk-based iMosflm on the Mosflm website. On 11 Jan 2008, at 14:58, Jeremiah Wagner wrote: Hello Everyone, I am going to be teaching a class this spring and protein structure and function. I would like to have my students see some diffraction data and integrate images with mosflm. Are there any free or available data sets (possibly lysozyme) out there that can be used? Thanks, Jeremiah Wagner --- Jeremiah Wagner Visiting Assistant Professor of Biology Beloit College 700 College Street phone: 608-363-2743 Beloit, WI 53511 FAX: 608-363-2052 --- Jeremiah Wagner Visiting Assistant Professor of Biology Beloit College 700 College Street phone: 608-363-2743 Beloit, WI 53511 FAX: 608-363-2052 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] Calculating volume of Ligands
Hi A simple trick that small molecule crystallographers have been using for decades is based on the average volume of non-hydrogen atoms being about 18 Å^3 (this is close to being more-or-less correct for C, N and O, and the presence of one or two S or P atoms usually makes little difference) - they simply multiply the number of non-H atoms in the ligand by 18 and - hey presto! If you've only got a few atoms in your ligand, this is dead easy and you don't need a program to do it. If you're in a hurry, use 20Å^3 instead for a slight overestimate... On 15 Jan 2008, at 21:39, Rajan Pillai wrote: Hi All, Can anyone tell me any program that calculates voume of a ligand? Moreover, is there also any program that can calculate the volume of a ligand from its coordinates? Thanks, Rajan. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] New versions of Mosflm and iMosflm
Hi folks We are pleased to announce updated versions of Mosflm (version 7.0.2) and iMosflm (0.6.0). If you upgrade iMosflm, you should certainly upgrade Mosflm at the same time; there are many changes which depend on both parts being in sync. The main change is that we have a new developer for iMosflm; Luke Kontogiannis ([EMAIL PROTECTED]) has been with us since October and has been very busy implementing improvements to iMosflm, so that it is now more robust and even easier to use. Most of the changes to Mosflm itself are involved with bug fixing and improved communications with iMosflm, so you shouldn't notice a lot of difference. Changes to Mosflm since 7.0.1 * New detectors - Mar555 Flat Panel. Pilatus miniCBF images added. * Better support for Bruker 100 Format images (converted with frm2frm). * Change IP address for communication with iMosflm to the loopback address (127.0.0.1 or localhost). * Rectangular non-square detectors added for output to iMosflm display. * Bug involving R-Axis detectors writing d*Trek style headers fixed. * Many small bugs fixed - many thanks to all those who gave us feedback, especially Clemens Vonrhein Jim Pflugrath. Changes to iMosflm since 0.5.3 * Resizeable image display by dragging the window edges * Ability to delete sectors in the image selection panel by right-clicking on selected sector * iMosflm correctly deals with datasets where the first image has an index of zero. The batch number is offset to 1000 and the processing and writing out of the mtz file proceed normally * The spotfinding summary pane in the indexing panel now shows the number of spots with an intensity greater than the I/sigI threshold * Ability to stop the log file view autoscrolling with Control-UpArrow key combination. Resume autoscrolling with Control-DownArrow * Search the log file by bringing up the search panel with Control-F key combination. Control-F searches forward and Control-G searches backwards Harry Luke -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] 3D Glasses - Vuzix HMD by eDimensional
Okay, I was wrong. On two points... What I'd forgotten is that LCD displays produce polarized light (and so do TFT displays, for that matter), so you don't need a sheet of Polaroid to polarize the light from the vertical display. The half-silvered mirror is there (of course, I hear the cries) to make sure you have enough light reflected from the horizontal monitor to be about the same as the light transmitted from the vertical one. On 4 Feb 2008, at 12:09, Harry Powell wrote: Hi Just looking at the diagrams, I don't think the glass is half-silvered - it looks like a large sheet of Polaroid™. It only needs to polarize the transmitted light from the vertically oriented monitor, since the reflected light from the interface between two materials (at least one of which has a refractive index) will be polarized in any case (that's why your Polaroid™ sunglasses let you see below the waves...). My physics is too rusty to remember, but I think the vertical monitor in this case needs to be polarized vertically, since the reflected polarized light will be horizontal. No idea where you can buy large sheets of Polaroid™ though. IMWBW, though... On 4 Feb 2008, at 11:30, P Hubbard wrote: Hi Andrew, Just like the commercial systems, the glass is the only special piece of kit (which can be bought separately). The LCD monitors are just set up to display either left or right channel. If you ask me, I think these companies are just a rip off! Paul Date: Mon, 4 Feb 2008 11:24:32 + From: [EMAIL PROTECTED] Subject: Re: [ccp4bb] 3D Glasses - Vuzix HMD by eDimensional To: CCP4BB@JISCMAIL.AC.UK P Hubbard wrote: Just an FYI you can build those yourself at a fraction of the price! You just need the special piece of glass, two identical LCD monitors, and an edited X config file. The clever bit of the Omnia system (and the similar one from Planar, which being from the US might be cheaper there...?) is the DVI reflector card that flips the image to be displayed on the screen seen in the half-silvered mirror. Are you implying that an appropriately written Xorg.conf can get the graphics card to do this instead? The prospect is very appealing! Regards, Andrew -- Dr. Andrew Raine, Head of IT, MRC Dunn Human Nutrition Unit, Wellcome Trust/MRC Building, Hills Road, Cambridge, CB2 2XY, UK phone: +44 (0)1223 252830 fax: +44 (0)1223 252835 web: www.mrc-dunn.cam.ac.uk email: [EMAIL PROTECTED] Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] 3D Glasses - Vuzix HMD by eDimensional
Hi Just looking at the diagrams, I don't think the glass is half-silvered - it looks like a large sheet of Polaroid™. It only needs to polarize the transmitted light from the vertically oriented monitor, since the reflected light from the interface between two materials (at least one of which has a refractive index) will be polarized in any case (that's why your Polaroid™ sunglasses let you see below the waves...). My physics is too rusty to remember, but I think the vertical monitor in this case needs to be polarized vertically, since the reflected polarized light will be horizontal. No idea where you can buy large sheets of Polaroid™ though. IMWBW, though... On 4 Feb 2008, at 11:30, P Hubbard wrote: Hi Andrew, Just like the commercial systems, the glass is the only special piece of kit (which can be bought separately). The LCD monitors are just set up to display either left or right channel. If you ask me, I think these companies are just a rip off! Paul Date: Mon, 4 Feb 2008 11:24:32 + From: [EMAIL PROTECTED] Subject: Re: [ccp4bb] 3D Glasses - Vuzix HMD by eDimensional To: CCP4BB@JISCMAIL.AC.UK P Hubbard wrote: Just an FYI you can build those yourself at a fraction of the price! You just need the special piece of glass, two identical LCD monitors, and an edited X config file. The clever bit of the Omnia system (and the similar one from Planar, which being from the US might be cheaper there...?) is the DVI reflector card that flips the image to be displayed on the screen seen in the half-silvered mirror. Are you implying that an appropriately written Xorg.conf can get the graphics card to do this instead? The prospect is very appealing! Regards, Andrew -- Dr. Andrew Raine, Head of IT, MRC Dunn Human Nutrition Unit, Wellcome Trust/MRC Building, Hills Road, Cambridge, CB2 2XY, UK phone: +44 (0)1223 252830 fax: +44 (0)1223 252835 web: www.mrc-dunn.cam.ac.uk email: [EMAIL PROTECTED] Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] new versions of Mosflm (7.0.3) and iMosflm (0.6.1)
Hi folks We are pleased to announce the release of Mosflm version 7.0.3 and iMosflm 0.6.1. These are bug-fix releases for versions 7.0.2 and 0.6.0, which affect the following detectors and circumstances only. If your detector is not listed, it isn't affected, so you shouldn't need to update your copies of Mosflm and/or iMosflm - but you may want to anyway. Many thanks to those people who brought these issues to our attention. Fixes to Mosflm: * Image display for R-Axis detectors was reversed in iMosflm (the new interface), not in the old interface. * The presence of extremely large pixel values (262128) for Mar IP scanners caused Mosflm to shut down. * Direct beam co-ordinates read from Mar CCD image headers not sited at ESRF had X and Y swapped. * Direct beam co-ordinates were not used from Ed Westbrook NOIR images by iMosflm (although they were used by Mosflm). * Reversephi check box in iMosflm did not function as intended. Fix to iMosflm: * Bruker .sfrm suffix included in list in image browser. Special thanks to Jan for reminding me that I should include the download sites when announcing new releases! Downloads are available through the normal web-pages and ftp sites - Everything Mosflm - http://www.mrc-lmb.cam.ac.uk/harry/mosflm specific places - Mosflm v.7.0.3 - http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver703 iMosflm v. 0.6.1 - http://www.mrc-lmb.cam.ac.uk/harry/imosflm/ Harry Luke -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
[ccp4bb] Missing fonts...
Hi folks I've had a couple of reports recently of people trying to run ipmosflm on Fedora Core 8 machines, and they get the following error - ** xdl_view error in routine xdl_open_view ** ** Unable to load *adobe-courier-medium-r*--8* font ** I'm assuming that the install for FC8 is not including all the Courier fonts; since I don't have an FC8 machine handy, could anyone here offer advice about the best way to install these? Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] problems about installation of mosflm701
Hi First off, you really shouldn't be installing mosflm version 7.0.1 - version 7.0.3 is the current one, and contains numerous bug fixes. The developers are likely to meet any problem queries relating to 7.0.1 with update to the current version first, then try again; if the problem persists, we will look at it... Your immediate problem is that you are trying to run a csh script as a bash script, without editing the file properly; e.g., you can't just change setenv (csh) to export (bash) - the syntax is not the same - you'd need to change it thus - setenv CCP4_LIB_FILES '-lccp4f -lccp4c -lxdl_view' would become something like export CCP4_LIB_FILES='-lccp4f -lccp4c -lxdl_view' You would also need to change the top line of the file so that it was something like #!/bin/bash -f, though I would be more inclined to use a proper traditional Bourne shell for this and use #!/bin/sh -f and use sets and exports throughout. If you really want to run the script, I would use tcsh or csh, rather than trying to modify it so that it is a bash script. BTW, the Intel compiler setup in that file is way out of date - you'd need to change that as well to point to current copies of the compilers. I would be very strongly inclined to install the mosflm_linux_suse pre-built executable - it should certainly work on FC5, and saves you the trouble of trying to build it. The speedup by using an executable compiled with the Intel compiler is probably not that great - recent g77s and gfortrans give excellent and stable optimization! On 27 Mar 2008, at 04:57, Lu Yongzhi wrote: - Original Message - From: Lu Yongzhi To: ccp4 bb Sent: Wednesday, March 26, 2008 7:41 PM Subject: problems about installation of mosflm701 Hi, My OS is fedoral core 5. I have installed ccp4-6.0.2 which include the mosflm 6, but I want to install mosflm7.0.1. I downloaded the program, but I can't install it properly. I source the file 'intel', the echo is (I have changed the 'setenv' to 'export'): bash: export: `-lccp4f -lccp4c -lxdl_view': not a valid identifier MOSROOT has been set to bash: export: `/index': not a valid identifier bash: export: `/src/dps/util': not a valid identifier bash: export: `/jpg': not a valid identifier bash: intel: line 65: syntax error: unexpected end of file could anyone can help me. the lines in the 'intel' file are: #!/bin/csh -fv # # setup shell script for the development copies of Mosflm for different # platforms. # # Common stuff first # export CCP4_LIB_FILES '-lccp4f -lccp4c -lxdl_view' set mosroot = ${cwd:h} export MOSROOT $mosroot echo MOSROOT has been set to $MOSROOT set moshome = ${cwd} export MOSHOME $moshome echo $MOSHOME export AR_FLAGS vru export DPS ${MOSHOME} export IND ${MOSHOME}/index export UTIL${MOSHOME}/src/dps/util export JPG ${MOSHOME}/jpg # intel compiler specifics - change this to your local installation if ( -e /opt/intel/compiler70/ia32/bin/ifcvars.csh )then source /opt/intel/compiler70/ia32/bin/ifcvars.csh else echo You must either edit the file called \intel\ to source the correct echo ifcvars.csh file or install both the Intel C++ and FORTRAN compilers exit endif if ( -e /opt/intel/compiler70/ia32/ifc_fudge.o )then export FUDGE /opt/intel/compiler70/ia32/ifc_fudge.o export NOFUDGE else export FUDGE export NOFUDGE -i_dynamic endif export DEBUG export F77 ifc ${DEBUG} export FCOMP ${F77} export FC ${F77} export CC icc ${DEBUG} export FLINK ${F77} ${DEBUG} export FFLAGS -O -align -w90 -cm export CFLAGS -O0 -O -DPROTOTYPE -DIFC -c -w # if no fudge.o vide infra export LFLAGS-Vaxlib -i_dynamic export LFLAGS-Vaxlib $NOFUDGE # # (2) Mosflm directory # export MOSFLAGS -O3 -align -w90 -cm # export MOSFLAGS -O3 -align -w90 -cm -prof_gen this line for profiling only # export MOSFLAGS -O3 -align -w90 -cm -prof_use change $F77 etc to include -ipo flag export MCFLAGS -O0 export MOSLIBS -L${CCP4_LIB} ${CCP4_LIB_FILES} -lncurses -L/ usr/X11R6/lib -lXt -lSM -lICE -lX11 -ldl -lpthread -lm ${FUDGE} # # (3) CBF directories # export CBFCFLAGS -O -DPROTOTYPE -DIFC # DPS export VERBOSE v export UTILFLAGS -O -DPROTOTYPE -DIFC -c -w export EXTRAFLAGS -I${UTIL} export STDCFLAGS exit Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] is it Ok to freeze
Hi If you mean organic small molecules, then the opinion for the last 15 years at least is probably yes, unless you know you'll have a phase change. Most small molecule crystals don't have the same problems with needing cryoprotectants as macromolecules, due in large part to not having a large proportion of water in the lattice, so the process is somewhat more straightforward. Also, most small molecule crystals can be handled quite happily in the absence of mother liquor, and you don't have to worry about them drying out while transferring to the fibre (rather than loop) which would normally be used for mounting them. Of course, there are numerous exceptions to the most I'm referring to here. In most cases you'll get a substantially better structure at cryo temperatures (of course, what better means may be open to debate). On 19 Jun 2008, at 09:47, Jayashankar wrote: Dear Scientists and Friends, I am not sure, whether organic crystals need to be in cryo stream necessarily during data collection from an in house xray machine . How most of the organic crystals have been solved mostly? -- S.Jayashankar (A bit confused new generation researcher). Research Student Institute for Biophysical Chemistry Hannover Medical School Germany Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] is it Ok to freeze
Hi Colin yes, both of those. Plus freezing out multiple conformations so you can model them properly - bear in mind that a small molecule structure at a resolution worse than 1Å would be challenging to get past the normal criteria of referees, so you should be able to see them at least some of the time (depending on how distinct the multiple conformations are). It may be easier to distinguish the atom type (C,N,O?) if you have a lower temperature dataset - at least 50% of the small molecule structures I did when I was working in that field were _not_ of the compound the chemist thought they had, so working out the atom type was rather important. However, I'm not sure this is a strong reason for doing cryo work on its own - any half decent modern automated small molecule structure solution program could do it with most room temperature datasets. Also, if you have an air-sensitive crystal (chemists say this as a shorthand when they mean more specific things like the chemical is oxygen or moisture-sensitive) you can slow the reactions down enough so that your crystal doesn't decompose because of those. But that's more of a problem with organometallics than organics, except with some of the more exotic organic species... And if your crystal loses solvent (e.g. I used to use CH2Cl2 (methylene chloride to the old hacks here) as a solvent, and that will just evaporate at room temp, leaving you with a powder rather than a beautiful single crystal. Although you can get round air-sensitivity and solvent loss by mounting in a capillary, there are good reasons to avoid that and cryo-cool with a naked (or semi-naked, dressed only in a gossamer- like film of perfluoropolyether oil) crystal if you can, as those of us who have done both regularly know. I'm sure there are other reasons why it would be substantially better, but I also know that there is considerable effort going into high-temperature devices, which will be used to help collect substantially better datasets for the crystals that their developers are interested in. does this help? On 19 Jun 2008, at 10:25, Nave, C (Colin) wrote: Harry Can you clarify why you get a substantially better structure at cryo temperatures e.g higher intensity at high resolution due to reduction in B factors, reduction in radiation damage, anything else? Colin -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of harry powell Sent: 19 June 2008 10:12 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] is it Ok to freeze Hi If you mean organic small molecules, then the opinion for the last 15 years at least is probably yes, unless you know you'll have a phase change. Most small molecule crystals don't have the same problems with needing cryoprotectants as macromolecules, due in large part to not having a large proportion of water in the lattice, so the process is somewhat more straightforward. Also, most small molecule crystals can be handled quite happily in the absence of mother liquor, and you don't have to worry about them drying out while transferring to the fibre (rather than loop) which would normally be used for mounting them. Of course, there are numerous exceptions to the most I'm referring to here. In most cases you'll get a substantially better structure at cryo temperatures (of course, what better means may be open to debate). On 19 Jun 2008, at 09:47, Jayashankar wrote: Dear Scientists and Friends, I am not sure, whether organic crystals need to be in cryo stream necessarily during data collection from an in house xray machine . How most of the organic crystals have been solved mostly? -- S.Jayashankar (A bit confused new generation researcher). Research Student Institute for Biophysical Chemistry Hannover Medical School Germany Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Re: [ccp4bb] is it Ok to freeze
Hi I just noticed I scrambled that first paragraph. I didn't intend to imply you should be able to see your referees (or their criteria) at least some of the time. It should have read something more like- yes, both of those. Plus freezing out multiple conformations so that you can model them properly; you should be able to see them at least some of the time (depending on how distinct the multiple conformations are). Bear in mind that a small molecule structure at a resolution worse than 1Å would be challenging to get past the normal criteria of referees. On 19 Jun 2008, at 11:05, harry powell wrote: Hi Colin yes, both of those. Plus freezing out multiple conformations so you can model them properly - bear in mind that a small molecule structure at a resolution worse than 1Å would be challenging to get past the normal criteria of referees, so you should be able to see them at least some of the time (depending on how distinct the multiple conformations are). Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] is it Ok to freeze
Hi Without wishing to start an argument, I've been checking with some of my colleagues who are chemical crystallographers - the reply I get is that, for routine structural analysis, pretty well all datasets are collected at 100K unless the crystals fall apart at low T, or if the cryostream is broken. I should point out that the first production Cryostream that I came across (serial number 2, which I think may have been the first one sold!) was in the Cambridge Department of Chemistry in about 1985. They didn't become common until the mid-1990's in PX labs, when they were already well-established as a bit of pretty well essential kit for small molecule work. So although what Remy says is true, the practice is to cryocool most of the time. On 19 Jun 2008, at 12:08, Remy Loris wrote: Typically crystals of small organic compounds do not require freezing as there are no solvent channels. They do in general not suffer from radiation damage at room temperature the way protein crystals do. Occasionally they are mounted in a capillary instead of simply glueing them to a goniometer if they are air sensitive. In principle freezing should not damage the crystals, but one still may have to be carefull if the crystals are large. I think you risk increasing mosiacity, and any manipulation that is not needed will on average only reduce the quality of the specimen rather than improve it Remy Loris Vrije Univesiteit Brussel Jayashankar wrote: Dear Scientists and Friends, I am not sure, whether organic crystals need to be in cryo stream necessarily during data collection from an in house xray machine . How most of the organic crystals have been solved mostly? -- S.Jayashankar (A bit confused new generation researcher). Research Student Institute for Biophysical Chemistry Hannover Medical School Germany Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] program for distribution of distances
Hi SHELX should be able to do this if you convert your co-ordinates into the appropriate format... On 24 Jun 2008, at 12:30, Eleanor Dodson wrote: It sounds like something the CCDC software might do? Eleanor DISTANG will do it for pdb input Kristof Van Hecke wrote: Dear all, I apologize for the off-topic question. I'm looking for some software that is able to read in (small molecule) structure files (e.g. .pdb, .cif,..) and subsequently outputs a listing of bond lengths AND 'environment' distances for each atom within a certain radius. Additionally, the listing should allow to construct a distribution diagram for each atom-atom distance. I already played a bit with Vista en Mercury (CCDC), but to my knowledge it's not possible to include such 'environment' distances... Thanks a lot Kristof -- Kristof Van Hecke, PhD Biomoleculaire Architectuur Celestijnenlaan 200 F B-3001 Heverlee (Leuven) Tel: +32(0)16327477 -- Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] Question re: ice rings in diffraction data
Hi You can exclude the ice rings easily in Mosflm - from the command line - (a) Autoindexing - AUTOINDEX EXCLUDE ICE (but see user guide for more on this) (b) Processing - RESOLUTION EXCLUDE ICE Or if you try iMosflm, just check the button that says exclude ice rings (Indexing pane) or Do not integrate near ice rings (Processing pane). These are good for hexagonal ice (what you probably have), but if you've got cubic (or other) ice, you need to exclude the rings by their explicit resolution. On 15 Jul 2008, at 15:14, Mona Rahman wrote: Hello all, I have a query re: processing data. I have some lovely diffraction data that has been marred by ice rings (so...not as lovely as it could be). I was told it may be possible to mask the regions of the ice rings (obviously sacrificing completeness) during processing. I have been using HKL2000 to process data. Is this feature available with this program? Otherwise, we also have Mosfilm. Any advice would be greatly appreciated. Thank you. Sincerely in anticipation Mona Rahman --- Mona N. Rahman, Ph.D. Dept. of Biochemistry/Pharmacology Toxicology Botterell Hall, Rooms 623 and 634 (lab) Queen's University, Kingston, ON, K7L 3N6 Phone: 613-533-2993, 613-533-6293 (lab) E-mail: [EMAIL PROTECTED] Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] Crystallographic computing platform recommendations?
Hi I would tend to go with a system type that you're familiar and happy with, rather than buying into someone else's idea of the best system. So if you are used to running any particular type (Windows, OSX, Linux), I'd spend a little time setting it up on what you've currently got and see if you can do what you want, and where you want it to perform better. Of course, you get a much wider range of available hardware if you go for Linux or Windows (unless you really want to build a Hackintosh). Most (or at least enough to be able to process data solve structures) of the software out there has been ported to the popular platforms, and it's likely that in the short term at least, that you'd be more productive in not having to learn a new environment, with all its idiosyncrasies... Dear list, I haven't seen the crystallographic computing platform thread come up for a while, and I've got a chance to upgrade my desktop to a workstation, so I thought I'd ask the CCP4BB for advice on: 1. Mac vs. Linux (which flavor?) vs. Windows 2. Graphics cards 3. Displays 4. Processors - multiple processors, multiple cores? Speed? About half of what I do involves ~1.0 A X-ray structures - data processing, rebuilding in Coot, refinement, and so forth - so my current desktop (Optiplex GX745, Radeon X1300) machine drags on graphics sometimes. I don't seem to need stereo these days, for what it's worth. Anybody have suggestions or specs they'd like to share? Thanks in anticipation of your advice. Regards, Anna Gardberg Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] iMosflm in 6.1 under OS X
Hi I should say, while this subject has been brought up, that Luke and I are working hard to remove many of these dependencies, so iMosflm should work with a more plain vanilla version of TclTk (but you will still need iTcl and iTk. On 17 Dec 2008, at 16:34, William G. Scott wrote: More specifically, issue fink selfupdate-cvs (or fink selfupdate-rsync) fink install itcl itk iwidgets tdom tkimg tktreectrl On Dec 17, 2008, at 7:56 AM, Andrzej Lyskowski wrote: Hi, I've just upgraded my fink distro and was wondering what else has to be done concerning configuration in order to make the iMosflm run on Mac OS. So far I'm getting the following error: Error in startup script: unknown namespace in import pattern itcl::* while executing namespace import itcl::* (file /sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/src/imosflm.tcl line 91) invoked from within source $env(IMOSFLM) (file /sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl line 111) Regards, Andrzej Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] Mosflm cover was: CCP4 cover over the Yuletide and Study Weekend periods
Hi folks Just to let you all know - there will be no Mosflm cover during this period either. However, Luke, Andrew and I will all be at the CCP4 Study Weekend in Nottingham; we will be ready, willing and able to deal with any enquiries you may wish to bring. On 23 Dec 2008, at 13:01, Ballard, CC (Charles) wrote: Dear All I am afraid that there will be no cover from the CCP4 droids at Daresbury from 24 December until 2 January, with limited cover until 6 January. Here's wishing you all a Happy New Year Charles CCP4 core team Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
[ccp4bb] information for study weekend attendees...
Hi folks I found some tourist advice for visitors to Nottingham in the New Year... http://news.bbc.co.uk/1/hi/england/nottinghamshire/7798194.stm Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] Mac pro
Hi I use Parallels on my Mac at home for both Windows XP and Ubuntu - it works fine for me when running the more number-crunching parts of CCP4 - haven't really looked at graphics programs like Coot MG. At work I'm running VMWare (Workstation 6.0.0) on a Linux box for Vista, and that, too, is fine. If anyone from Redmond is reading this, both my Windows licenses are legit. On 6 Jan 2009, at 17:55, Nathaniel Echols wrote: There are also options for virtualization of Windoze and Linux via the software Parallels although I have yet to test this out. Parallels is okay; I only use it for testing GUI code on Linux. It doesn't support multiple processors, which probably isn't necessary for most people. The graphics support was somewhat flaky in the past, but it now emulates 3D acceleration well enough to run Coot or PyMOL. I've heard anecdotal evidence that VMWare Fusion is better, but I've only used the Linux version. Unrelated advice: try iWork before spending a massive amount of money on MS Office. It's only about $40-$50 with the academic discount, and much less bloated. It'll still read and export Office documents, although I don't know how robust this is. -Nat Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] imosflm in ccp4 6.1.0 in linux problems
Hi folks We have had a good look at this at Mosflm HQ now on Linux. The CCP4 TclTk++ distribution seems to work okay, and there's no need to install the ActiveTcl version to run iMosflm. It seems that if you use the CCP4 instructions on the wiki (http://ccp4wiki.org/~ccp4wiki/wiki/index.php?title=CCP4_installation ) things work okay. Bear in mind that there are now *two* include files you need to source when setting up ccp4 - both ccp4.setup (as before) and ccp4- others.setup (new). I strongly recommend downloading ipmosflm from the Mosflm website (http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver704/pre-built/index.html ), since it's built without the (unnecessary) libtermcap dependency - if you download the noX11 version you can avoid some rare bugs that only show up with iMosflm. Also, take care to heed Ronan's point about having the ccp4i project set up *before* running iMosflm from ccp4i, so that the directories are properly assigned. On 7 Jan 2009, at 08:32, Winter, G (Graeme) wrote: Dear Paula, The tcltk++ binary either from the downloads pages or ftp://ftp.ccp4.ac.uk/ccp4/current/extras should work fine - if you unpack this somewhere, export CCP4I_TCLTK appropriately and add the lib directory to the LD_LIBRARY_PATH it should solve your problem. If you would like more detail please don't hesitate to get in touch. This works fine on all the 32 and 64 linux systems I have tested. Best wishes, Graeme -Original Message- From: CCP4 bulletin board on behalf of Salgado, Paula Sent: Tue 1/6/2009 11:03 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] imosflm in ccp4 6.1.0 in linux problems Hi everyone I've been trying to run the new imosflm version from ccp4i 6.1.0 gui on ubuntu 8.0.4, but keep having problems. After struggling with it to search for the correct MOSDIR directory path, it then complained it was missing several packages from wish8.4. I did manage to find some of them, but after searching the web I still can't find: treectrl 2.1 img::png 1.3 img::gif 1.3 img::jpeg 1.3 can anyone tell me where I can download them or what other solutions to get imosflm to run properly? Thanks a lot Paula Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] imosflm in ccp4 6.1.0 in linux problems
Hi Sorry - just noticed that ccp4-others.setup doesn't seem to be in the source distribution, just in the binary distro. My assumption is that if you build from source (or install the Mac OS X binary installation) , it's not necessary. On 7 Jan 2009, at 11:54, Phil Evans wrote: What is this ccp4-others.setup? I don't have it in my working 6.1.0 installation (built from source) Phil On 7 Jan 2009, at 11:50, Harry Powell wrote: Hi folks We have had a good look at this at Mosflm HQ now on Linux. The CCP4 TclTk++ distribution seems to work okay, and there's no need to install the ActiveTcl version to run iMosflm. It seems that if you use the CCP4 instructions on the wiki (http://ccp4wiki.org/~ccp4wiki/wiki/index.php?title=CCP4_installation ) things work okay. Bear in mind that there are now *two* include files you need to source when setting up ccp4 - both ccp4.setup (as before) and ccp4- others.setup (new). I strongly recommend downloading ipmosflm from the Mosflm website (http://www.mrc-lmb.cam.ac.uk/harry/mosflm/ver704/pre-built/index.html ), since it's built without the (unnecessary) libtermcap dependency - if you download the noX11 version you can avoid some rare bugs that only show up with iMosflm. Also, take care to heed Ronan's point about having the ccp4i project set up *before* running iMosflm from ccp4i, so that the directories are properly assigned. On 7 Jan 2009, at 08:32, Winter, G (Graeme) wrote: Dear Paula, The tcltk++ binary either from the downloads pages or ftp://ftp.ccp4.ac.uk/ccp4/current/extras should work fine - if you unpack this somewhere, export CCP4I_TCLTK appropriately and add the lib directory to the LD_LIBRARY_PATH it should solve your problem. If you would like more detail please don't hesitate to get in touch. This works fine on all the 32 and 64 linux systems I have tested. Best wishes, Graeme -Original Message- From: CCP4 bulletin board on behalf of Salgado, Paula Sent: Tue 1/6/2009 11:03 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] imosflm in ccp4 6.1.0 in linux problems Hi everyone I've been trying to run the new imosflm version from ccp4i 6.1.0 gui on ubuntu 8.0.4, but keep having problems. After struggling with it to search for the correct MOSDIR directory path, it then complained it was missing several packages from wish8.4. I did manage to find some of them, but after searching the web I still can't find: treectrl 2.1 img::png 1.3 img::gif 1.3 img::jpeg 1.3 can anyone tell me where I can download them or what other solutions to get imosflm to run properly? Thanks a lot Paula Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] Issue on MOSFLM 7.0.4 with image collected on NOIR detector
hi folks I've had a look at Quentin's images, and have found out that some of the information that we are using in Mosflm to determine the pixel size and the beam centre is missing. For the record, if anyone else wants to process NOIR images with Mosflm and notices this problem, you should (for the present) tell Mosflm that the pixel size is 0.07767mm (same in both X Y) and also convert the beam centre from the image header from pixels to mm - while noting that the beam co-ordinates in the header are swapped in X Y compared to the Mosflm definition. Sorry for any inconvenience - we'll get this fixed for the next release! On 12 Feb 2009, at 21:08, Quentin Vicens wrote: Dear All, I used MOSFLM 7.0.4 to open some images originally collected on a NOIR-1 detector at the HHMI beamline at ALS. Problem #1: the resolution is not displayed accurately, even tough the reader seems to be read correctly (instead of being 1.28 in the attached example, it should be around 8 angstroems). Problem #2: autoindexing fails, which I now think may be related to problem #1. Thanks if you have any input! Quentin -- Quentin Vicens, Ph.D. University of Colorado Department of Chemistry and Biochemistry UCB 215 Boulder, CO 80309 USA tel: + 1 (303) 735-6338 fax: + 1 (303) 492-6194 e-mail: quentin.vic...@colorado.edu screen.tiff Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 2QH
Re: [ccp4bb] images
Hi I'm afraid the adoption of imgCIF (or CBF, its useful binary equivalent) doesn't help a lot - I know of three different manufacturers of detectors who, between them, write out four different image formats, all of which apparently conform to the agreed IUCr imgCIF standard. Each manufacturer has its own good and valid reasons for doing this. It's actually less work for me as a developer of integration software to write new code to incorporate a new format than to make sure I can read all the different imgCIFs properly. On 16 Mar 2009, at 09:32, Eleanor Dodson wrote: The deposition of images would be possible providing some consistent imagecif format was agreed. This would of course be of great use to developers for certain pathological cases, but not I suspect much value to the user community - I down load structure factors all the time for test purposes but I probably would not bother to go through the data processing, and unless there were extensive notes associated with each set of images I suspect it would be hard to reproduce sensible results. The research council policy in the UK is that original data is meant to be archived for publicly funded projects. Maybe someone should test the reality of this by asking the PI for the data sets? Eleanor Garib Murshudov wrote: Dear Gerard and all MX crystallographers As I see there are two problems. 1) Minor problem: Sanity, semantic and other checks for currently available data. It should not be difficult to do. Things like I/ sigma, some statistical analysis expected vs observed statistical behaviour should sort out many of these problems (Eleanor mentioned some and they can be used). I do not think that depositors should be blamed for mistakes. They are doing their best to produce and deposit. There should be a proper mechanism to reduce the number of mistakes. You should agree that situation is now much better than few years. 2) A fundamental problem: What are observed data? I agree with you (Gerard) that images are only true observations. All others (intensities, amplitudes etc) have undergone some processing using some assumptions and they cannot be considered as true observations. The dataprocessing is irreversible process. I hope your effort will be supported by community. I personally get excited with the idea that images may be available. There are exciting possibilities. For example modular crystals, OD, twin in general, space group uncertaintly cannot be truly modeled without images (it does not mean refinement against images). Radiation damage is another example where after processing and merging information is lost and cannot be recovered fully. You can extend the list where images would be very helpful. I do not know any reason (apart from technical one - size of files) why images should not be deposited and archived. I think this problem is very important. regards Garib On 12 Mar 2009, at 14:03, Gerard Bricogne wrote: Dear Eleanor, That is a useful suggestion, but in the case of 3ftt it would not have helped: the amplitudes would have looked as healthy as can be (they were calculated!), and it was the associated Sigmas that had absurd values, being in fact phases in degrees. A sanity check on some (recalculated) I/ sig(I) statistics could have detected that something was fishy. Looking forward to the archiving of the REAL data ... i.e. the images. Using any other form of data is like having to eat out of someone else's dirty plate! With best wishes, Gerard. -- On Thu, Mar 12, 2009 at 09:22:26AM +, Eleanor Dodson wrote: It would be possible for the deposition sites to run a few simple tests to at least find cases where intensities are labelled as amplitudes or vice versa - the truncate plots of moments and cumulative intensities at least would show something was wrong. Eleanor -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * === Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] images
Hi I've heard of a tool from the Golden State which could (potentially) be used for forging diffraction images... I believe it's called mlfsom. On 18 Mar 2009, at 17:50, Felix Frolow wrote: One convincing argument I have: We will be able to catch fraud ultimately. Fraud is a devastation for structural biology. ...Unless they will be smart enough to forge diffraction data images, not a big deal. The second one - in the case of a controversy of the deposited results (possible thing) we can try to re-interpret the space group and Bravais lattice And one more, when we have time we can show that we know better to process and to refine ;-) Dr Felix Frolow Professor of Structural Biology and Biotechnology Department of Molecular Microbiology and Biotechnology Tel Aviv University 69978, Israel Acta Crystallographica D, co-editor e-mail: mbfro...@post.tau.ac.il Tel: ++972 3640 8723 Fax: ++972 3640 9407 Cellular: ++972 547 459 608 On Mar 18, 2009, at 6:41 PM, Garib Murshudov wrote: Dear all Before going into and trying to find a technical solution to the problem it would be good if decide if we need images. As far as I know if we face with a problem to solve and we know that it is necessary to solve then we find technical solution to the problem (either from other fields or we find our own solution with some elements of reinvention of new MX wheels). Do we need images to store? What kind of information we can extract from images that we cannot from amplitudes, intensities (even unmerged)? Does anybody have a convincing argument for favour of images? regards Garib On 18 Mar 2009, at 16:32, Herbert J. Bernstein wrote: Actually the radiologists who manage CT and PET scans of brains do have a solution, called DICOM, see http://medical.nema.org/. If we work together as a community we should be able to do as well as the rocket scientists and the brain surgeons' radiologists, perhaps even better. -- Herbert = Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 y...@dowling.edu = On Wed, 18 Mar 2009, Jacob Keller wrote: Apparently it DOES take a rocket scientist to solve this problem. Maybe the brain surgeons also have a solution? JPK *** Jacob Pearson Keller Northwestern University Medical Scientist Training Program Dallos Laboratory F. Searle 1-240 2240 Campus Drive Evanston IL 60208 lab: 847.491.2438 cel: 773.608.9185 email: j-kell...@northwestern.edu *** - Original Message - From: Klaas Decanniere klaas.decanni...@vub.ac.be To: CCP4BB@JISCMAIL.AC.UK Sent: Wednesday, March 18, 2009 5:36 AM Subject: Re: [ccp4bb] images Herbert J. Bernstein wrote: Other sciences have struggled with this and seem to have found an answer. Have e.g. a look at http://heasarc.nasa.gov/docs/heasarc/fits.html kind regards, Klaas This is a good time to start a major crystallogrpahic image archiving effort. Money may well be available now that will not be avialable six month from now, and we have good, if not perfect, solutions available for many, if not all, of the technical issues involved. Is it really wise to let this opportunity pass us by? The deposition of images would be possible providing some consistent imagecif format was agreed. This would of course be of great use to developers for certain pathological cases, but not I suspect much value to the user community - I down load structure factors all the time for test purposes but I probably would not bother to go through the data processing, and unless there were extensive notes associated with each set of images I suspect it would be hard to reproduce sensible results. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] imosflm STARTDIR
Hi folks The real problem here is that the imosflm you run by default after installing the latest CCP4 is a shell script in $CBIN (i.e. where all the compiled programs are), which doesn't actually set things up properly. This has been addressed by the guys in Daresbury and the fix will appear in the next release (after which you should be able to ignore the rest of this message). If, on the other hand, you run the imosflm in the directory $CCP4/ ccp4i/imosflm/src, everything should be hunky-dory - you can do this by setting your PATH environment variable so it finds this script first, e.g. in tcsh - setenv PATH $CCP4/ccp4i/imosflm/src:$PATH _after_ doing the normal source'ing ccp4.setup; then imosflm on the command line should work. The other option would be to install imosflm from our web-pages and run that, but since this is currently the one that ccp4 distribute there's no obvious advantage to that, other than removing the ambiguity. HTH On 19 Mar 2009, at 10:03, Williams, MA (Mark) wrote: imosflm also takes the command line switch --startdir so you could try an alias of alias imosflm='imosflm --startdir $PWD' Mark -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of William G. Scott Sent: 18 March 2009 17:17 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] imosflm STARTDIR You could try something like this (bash/zsh/sh): alias imosflm='MOSDIR=${PWD} imosflm' The single quotes are required for it to do the right thing. Bill On Mar 18, 2009, at 6:49 AM, James Foadi wrote: Dear MOSFLM/IMOSFLM people, when I start the new version of imosflm I expect it to dump files and to search all files starting from the current directory. This doesn't seem to be the case. It appears it always starts from MOSDIR. I my imosflm.tcl the line related to STARTDIR is: set STARTDIR [pwd] Perhaps somebody else has written about this, but if this is the case, I have missed the thread. Can somebody help me with this? J Dr James Foadi PhD Membrane Protein Laboratory Diamond Light Source Ltd. Diamond House Harwell Science and Innovation Campus Didcot Oxfordshire OX11 0DE United Kingdom office email: james.fo...@diamond.ac.uk alternative email: j.fo...@imperial.ac.uk DIVFONT size=1 color=grayThis e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom /FONT/DIV -- Scanned by iCritical. Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] mosflm in script mode
Hi Jan The IMAGE command turns the old gui on - always has done, as far as I know. With Strategy auto you shouldn't need to give an image number. HTH On 28 May 2010, at 14:35, Jan Abendroth wrote: Hi all, I have been trying to use mosflm in script mode, in a quick-n-dirty effort to pipe some information from labelit.index into a simple data collection strategy. While doing that, I run into the following issue. I have not been able to find a way to read in image information without starting the old gui. Is there a command in the current mosflm versions to run it in shell mode only? Below the script that I have been using. Any ideas? Thanks Jan --- ipmosflm summary integrate02.sum eof DIRECTORY ../images TEMPLATE image_###.img IMAGE 1 HKLOUT integration02.mtz GENFILE integration02.gen #detector-take defaults #UIS_PIXEL 0.102400 #UIS_SIZE 3072 NUSPOT OFF BEAM 155.400500 158.807700 DISTANCE 299.775600 TWOTHETA 0.0 WAVE 0.977400 #beam SYNCHROTRON POLARIZATION 0.9 DIVERGENCE 0.100 0.020 DISPERSION 0.0001 MOSAICITY 0.60 SYMMETRY p2 RESOLUTION 3.5 MATRIX integration02.mat PROFILE OVERLOAD PARTIALS RASTER 19 19 9 4 4 SEPARATION 1.80 1.80 CLOSE REFINEMENT RESID 7.5 REFINEMENT INCLUDE PARTIALS RESID 10.0 #High s/n scanner adsc strategy auto stats on go end exit eof -- Jan Abendroth Emerald BioStructures Seattle / Bainbridge Island WA, USA home: Jan.Abendroth_at_gmail.com work: JAbendroth_at_embios.com http://www.emeraldbiostructures.com Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH