[ccp4bb] Crystal handling
Hi all. I have small and fragile membrane protein crystals with size 40 micron. They like to break when I try take them out with regular loops for freezing. Is there any special tricks to handle them for data collection? Thank you. Theresa
Re: [ccp4bb] very informative - Trends in Data Fabrication
Dear Ron, Quite so, and who cannot laugh at the Yes Minister perfect hospital ward operating theatre sketch ( Thankyou James W). Anyway:- Let's not get too hung up on one detail of your point 3. Your various points, including point 3, added several missing elements in this CCp4bb thread. Overall what I am saying is that to me it is good that my University at least is gearing up to provide a local Data Archive service which, since I wish to link my raw data sets in future to my publications via doi registrations, this will give a longevity to them that I cannot guarantee with a 'my raw data are in my desk drawer' approach. These could be useful in future reuse ie:- I see various improvements to understanding diffuse scattering and, secondly, to squeezing more diffraction resolution out of the Bragg data as computer hardware and software both improve. Once in my career I nearly made a mistake on a space group choice ( I wrote it up as an educational story in 1996 in Acta D); if I had made that mistake the literature would finally have caught up i suppose and said :- where are the raw data, let's check that space group choice. This latter type of challenge of course is catchable via depositing processed Bragg data as triclinic; it probably doesn't need raw images. Finally I have a project that I have worked for some years on now to solve the structure; there are two, possibly several , crystal lattices and diffuse streaks. If I have to finally give up I will make them available via doi on my a university raw data archive; meanwhile of course we make new protein and recrystallise etc, the other approach! Greetings, John Prof John R Helliwell DSc FInstP CPhys FRSC CChem F Soc Biol. Chair School of Chemistry, University of Manchester, Athena Swan Team. http://www.chemistry.manchester.ac.uk/aboutus/athena/index.html On 6 Apr 2012, at 17:23, Ronald E Stenkamp stenk...@u.washington.edu wrote: Dear John, Your points are well taken and they're consistent with policies and practices in the US as well. I wonder about the nature of the employer's responsibility though. I sit on some university committees, and the impression I get is that much of the time, the employers are interested in reducing their legal liabilities, not protecting the integrity of science. The end result is the same though in that the employers get involved and oversee the handling of scientific misconduct. What is unclear to me is whether the system for dealing with misconduct is broken. It seems to work pretty well from my viewpoint. No system is perfect for identifying fraud, errors, etc, and I understand the idea that improvements might be possible. However, too many improvements might break the system as well. Ron On Fri, 6 Apr 2012, John R Helliwell wrote: Dear Ron, Re (3):- Yes of course the investigator has that responsibility. The additional point I would make is that the employer has a share in that responsibility. Indeed in such cases the employer university convenes a research fraud investigating committee to form the final judgement on continued employment. A research fraud policy, at least ours, also includes the need for avoding inadvertent loss of raw data, which is also deemed to be research malpractice. Thus the local data repository, with doi registration for data sets that underpin publication, seems to me and many others, ie in other research fields, a practical way forward for these data sets. It also allows the employer to properly serve the research investigations of its employees and be duely diligent to the research sponsors whose grants it accepts. That said there is a variation of funding that at least our UK agencies will commit to 'Data management plans'. Greetings, John 2012/4/5 Ronald E Stenkamp stenk...@u.washington.edu: This discussion has been interesting, and it's provided an interesting forum for those interested in dealing with fraud in science. I've not contributed anything to this thread, but the message from Alexander Aleshin prodded me to say some things that I haven't heard expressed before. 1. The sky is not falling! The errors in the birch pollen antigen pointed out by Bernhard are interesting, and the reasons behind them might be troubling. However, the self-correcting functions of scientific research found the errors, and current publication methods permitted an airing of the problem. It took some effort, but the scientific method prevailed. 2. Depositing raw data frames will make little difference in identifying and correcting structural problems like this one. Nor will new requirements for deposition of this or that detail. What's needed for finding the problems is time and interest on the part of someone who's able to look at a structure critically. Deposition of additional information could be important for that critical look, but deposition alone (at
[ccp4bb] Refmac executables - win vs linux in RHEL VM
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. -
Re: [ccp4bb] Refmac executables - win vs linux in RHEL VM
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. -
Re: [ccp4bb] Refmac executables - win vs linux in RHEL VM
On Sat, Apr 7, 2012 at 9:50 AM, Roger Rowlett rrowl...@colgate.edu 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. Different compiler implementations will often have a huge effect on runtimes. I recently spent some time trying to get a large amount of C++ code (converted from F77) to compile under Visual C++ 9.0, and I had to disable optimization of at least ten different functions to prevent cl.exe from crashing. This was not especially complex code (and g++ never complains) - just nested 'for' loops over three dimensions. I did not attempt to compare runtimes since I was running Windows in a virtual machine on a Mac, but I would be surprised if the resulting Windows binaries were not slower on identical hardware. And even if the compiler isn't broken, the math libraries may be; one of my colleagues found (on Linux) that the exp() function provided by g77 was 20-fold slower than the equivalent in the Intel math library. So I suspect it is related to the compilers (and optimization flags) used by CCP4 for these platforms. Another good reason to avoid Windows! -Nat
Re: [ccp4bb] very informative - Trends in Data Fabrication
I doubt many people completely fail to archive data but maintaining data archives can be a pain so I'm not sure what the useful age of the average archive is. Do people who archived to tape keep their tapes in a format that can be read by modern tape drives? Do people who archived data to a hard drive 10 years ago have something that can still read an Irix EFS-formatted SCSI hard drive today and, if not, did they bother to move the data to some other storage medium? -Eric On Apr 5, 2012, at 9:08 AM, Roger Rowlett wrote: FYI, every NSF grant proposal now must have a data management plan that describes how all experimental data will be archived and in what formats. I'm not sure how seriously these plans are monitored, but a plan must be provided nevertheless. Is anyone NOT archiving their original data in some way? Roger Rowlett
Re: [ccp4bb] A little perspective (Re: Trends in Data Fabrication)
along those lines one should also look at this NRDD paper: http://www.nature.com/nrd/journal/v11/n3/full/nrd3681.html Rather long but has lots of very useful citations. If you ask industry people it's a know problem that 50% of their own experiments can't be reproduced but it's even worse if you go to academia. I would be careful though saying that this is due to fraud. Jürgen On Apr 7, 2012, at 6:31 PM, Dima Klenchin wrote: Just came across it and thought it's quite relevant with regard to the latest furor over fraud in crystallography: http://www.nature.com/nature/journal/v483/n7391/pdf/483531a.pdf 53 papers were deemed 'landmark' studies ... scientific findings were confirmed in only 6 (11%) cases. Mean number of citations: non-reproduced articles* 169 (range 6–1,909) reproduced articles* 13 (range 3–24) And yet, cell biology is steadily marching on with quite remarkable progress each year... - Dima .. 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://web.mac.com/bosch_lab/
Re: [ccp4bb] Crystal handling
Have you tried the MiTeGen Micromesh? They're my favorite for handling tiny crystals. Ho Ho Leung Ng University of Hawaii at Manoa Assistant Professor, Department of Chemistry h...@hawaii.edu On Sat, Apr 7, 2012 at 1:00 PM, CCP4BB automatic digest system lists...@jiscmail.ac.uk wrote: Hi all. I have small and fragile membrane protein crystals with size 40 micron. They like to break when I try take them out with regular loops for freezing. Is there any special tricks to handle them for data collection? Thank you. Theresa
Re: [ccp4bb] Crystal handling (Summary)
Thank you for all the on and off-board replies. The suggestion is to use meshed loops from Molecular Dimensions or Mitegen. I presume both works well to collect data. Theresa
