[ccp4bb] frm2frm
Hello, Does anyone know where I could download frm2frm utility from Bruker? Is it even possible to do so?
Re: [ccp4bb] IUCr committees, depositing images
On Tue, Oct 25, 2011 at 3:20 PM, Pete Meyer wrote: > This is probably an idea that has already been tried (or discarded as > unsuitable for reasons that don't occur to me at the moment) - but why not > start with good crystals (such as lysozyme) and deliberately make them > worse? Exactly how would depend on what kind of methods you were trying to > develop - but I'd imaging "titrating in" organic solvents/detergents would > be able to turn a well-diffracting crystal into a poor one (with a known, or > at least knowable, answer). Deliberately causing radiation damage, or using > known poor cryo-conditions would also work - probably the type of "badness" > in the data would be different. > > I don't think you'd be able to tune solvent content or number of anomalous > scatterers by damaging good crystals. This would also require a decent > number of crystals (but lysozyme is reasonably inexpensive). But making good > crystals from bad ones is difficult - making bad ones from good ones > shouldn't be. > > Any ideas why this wouldn't work (or citations where it did)? It probably depends on what kind of methods you are trying to develop, but there are any number of reasons why it wouldn't be a complete substitute for bad data found in the wild (you've already listed a couple), all of them essentially coming down to the same problem: you're limiting what kind of imperfections and pathologies you'll see. How do you get a crystal that is just slightly split, for instance? Or one that diffracts to high resolution but has a mosaicity of 2.5 degrees? I can think of plenty of other special cases, and the data processing people probably have dozens of ideas. We could spend a month abusing lysozyme crystals and still not come up with anywhere near the diversity that the community can generate with their membrane proteins, glycoproteins, RNA, etc. This is true for everything from data processing to refinement. (Fortunately, for refinement we already have most of what we need in the PDB.) That doesn't mean it's not a good idea anyway; I've considered doing something similar to generate pairs of realistic high-resolution and low-resolution data. (Probably not using lysozyme - it's much too small to be representative of the average 4A structure.) It's a good summer project for a capable undergraduate student, if you have synchrotron time to burn. -Nat
Re: [ccp4bb] IUCr committees, depositing images
James Holton wrote: I go to a lot of methods meetings, and it pains me to see the most brilliant minds in the field starved for "interesting" data sets. The problem is that it is very easy to get people to send you data that is so bad that it can't be solved by any software imaginable (I've got piles of that!). As a developer, what you really need is a "right answer" so you can come up with better metrics for how close you are to it. Ironically, bad, unsolvable data that is connected to a right answer (aka a PDB ID) is very difficult to obtain. The explanations This is probably an idea that has already been tried (or discarded as unsuitable for reasons that don't occur to me at the moment) - but why not start with good crystals (such as lysozyme) and deliberately make them worse? Exactly how would depend on what kind of methods you were trying to develop - but I'd imaging "titrating in" organic solvents/detergents would be able to turn a well-diffracting crystal into a poor one (with a known, or at least knowable, answer). Deliberately causing radiation damage, or using known poor cryo-conditions would also work - probably the type of "badness" in the data would be different. I don't think you'd be able to tune solvent content or number of anomalous scatterers by damaging good crystals. This would also require a decent number of crystals (but lysozyme is reasonably inexpensive). But making good crystals from bad ones is difficult - making bad ones from good ones shouldn't be. Any ideas why this wouldn't work (or citations where it did)? Pete usually involve protestations about being in the middle of writing up the paper, the student graduated and we don't understand how he/she labeled the tapes, or the RAID crashed and we lost it all, etc. etc. Then again, just finding someone who has a data set with the kind of problem you are interested in is a lot of work! So is figuring out which problem affects the most people, and is therefore "interesting". Is this not exactly the kind of thing that publicly-accessible centralized scientific databases are created to address? -James Holton MAD Scientist On 10/16/2011 11:38 AM, Frank von Delft wrote: On the deposition of raw data: I recommend to the committee that before it convenes again, every member should go collect some data on a beamline with a Pilatus detector [feel free to join us at Diamond]. Because by the probable time any recommendations actually emerge, most beamlines will have one of those (or similar), we'll be generating more data than the LHC, and users will be happy just to have it integrated, never mind worry about its fate. That's not an endorsement, btw, just an observation/prediction. phx. On 14/10/2011 23:56, Thomas C. Terwilliger wrote: For those who have strong opinions on what data should be deposited... The IUCR is just starting a serious discussion of this subject. Two committees, the "Data Deposition Working Group", led by John Helliwell, and the Commission on Biological Macromolecules (chaired by Xiao-Dong Su) are working on this. Two key issues are (1) feasibility and importance of deposition of raw images and (2) deposition of sufficient information to fully reproduce the crystallographic analysis. I am on both committees and would be happy to hear your ideas (off-list). I am sure the other members of the committees would welcome your thoughts as well. -Tom T Tom Terwilliger terwilli...@lanl.gov This is a follow up (or a digression) to James comparing test set to missing reflections. I also heard this issue mentioned before but was always too lazy to actually pursue it. So. The role of the test set is to prevent overfitting. Let's say I have the final model and I monitored the Rfree every step of the way and can conclude that there is no overfitting. Should I do the final refinement against complete dataset? IMCO, I absolutely should. The test set reflections contain information, and the "final" model is actually biased towards the working set. Refining using all the data can only improve the accuracy of the model, if only slightly. The second question is practical. Let's say I want to deposit the results of the refinement against the full dataset as my final model. Should I not report the Rfree and instead insert a remark explaining the situation? If I report the Rfree prior to the test set removal, it is certain that every validation tool will report a mismatch. It does not seem that the PDB has a mechanism to deal with this. Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] COOT not "connected" to PHENIX
FYI, from version 0.7, I will not distribute binaries without python. Paul. On 25/10/11 17:02, Yuri wrote: I installed the version with python embedded in coot And it works!! Thanks a lot!! On Tue, 25 Oct 2011 11:41:38 -0700, Nathaniel Echols wrote: On Tue, Oct 25, 2011 at 11:40 AM, Yuri wrote: Now here comes the stupid question... How do I fix it? Install a different coot version or is it something in my architecture? Install a different Coot. If you're downloading from Paul Emsley's page, you need a package with "python" in the file name. I have no idea whether the Linux binaries distributed by CCP4 have Python or not (the Mac version definitely does). -Nat
Re: [ccp4bb] COOT not "connected" to PHENIX
I installed the version with python embedded in coot And it works!! Thanks a lot!! On Tue, 25 Oct 2011 11:41:38 -0700, Nathaniel Echols wrote: On Tue, Oct 25, 2011 at 11:40 AM, Yuri wrote: Now here comes the stupid question... How do I fix it? Install a different coot version or is it something in my architecture? Install a different Coot. If you're downloading from Paul Emsley's page, you need a package with "python" in the file name. I have no idea whether the Linux binaries distributed by CCP4 have Python or not (the Mac version definitely does). -Nat -- Yuri Pompeu
Re: [ccp4bb] IUCr committees, depositing images
To be fair to those concerned about cost, a more conservative estimate from the NSF RDLM workshop last summer in Princeton is $1,000 to $3,000 per terabyte per year for long term storage allowing for overhead in moderate-sized institutions such as the PDB. Larger entities, such as Google are able to do it for much lower annual costs in the range of $100 to $300 per terabyte per year. Indeed, if this becomes a serious effort, one might wish to consider involving the large storage farm businesses such as Google and Amazon. They might be willing to help support science partially in exchange for eyeballs going to their sites. Regards, H. J. Bernstein At 1:56 PM -0600 10/25/11, James Stroud wrote: On Oct 24, 2011, at 3:56 PM, James Holton wrote: The PDB only gets about 8000 depositions per year Just to put this into dollars. If each dataset is about 17 GB in size, then that's about 14 TB of storage that needs to come online every year to store the raw data for every structure. A two second search reveals that Newegg has a 3GB hitachi for $200. So that's about $1000 / year of storage for the raw data behind PDB deposits. James -- = Herbert J. Bernstein, Professor of Computer Science Dowling College, Brookhaven Campus, B111B 1300 William Floyd Parkway, Shirley, NY, 11967 +1-631-244-1328 Lab: +1-631-244-1935 Cell: +1-631-428-1397 y...@dowling.edu =
Re: [ccp4bb] IUCr committees, depositing images
On Oct 24, 2011, at 3:56 PM, James Holton wrote: > The PDB only gets about 8000 depositions per year Just to put this into dollars. If each dataset is about 17 GB in size, then that's about 14 TB of storage that needs to come online every year to store the raw data for every structure. A two second search reveals that Newegg has a 3GB hitachi for $200. So that's about $1000 / year of storage for the raw data behind PDB deposits. James
Re: [ccp4bb] IUCr committees, depositing images
Dear James, This is technically ingenious stuff. Perhaps it could be applied to help the 'full archive challenge' ie containing many data sets that will never lead to publication/ database deposition? However for the latter,publication/deposition, subset you would surely not 'tamper' with the raw measurements? The 'grey area' between the two clearcut cases ie where eventually publication/deposition MAY result then becomes the challenge as to whether to compress or not? (I would still prefer no tampering.) Greetings, John Prof John R Helliwell DSc On 24 Oct 2011, at 22:56, James Holton wrote: > The Pilatus is fast, but or decades now we have had detectors that can read > out in ~1s. This means that you can collect a typical ~100 image dataset in > a few minutes (if flux is not limiting). Since there are ~150 beamlines > currently operating around the world and they are open about 200 days/year, > we should be collecting ~20,000,000 datasets each year. > > We're not. > > The PDB only gets about 8000 depositions per year, which means either we > throw away 99.96% of our images, or we don't actually collect images anywhere > near the ultimate capacity of the equipment we have. In my estimation, both > of these play about equal roles, with ~50-fold attrition between ultimate > data collection capacity and actual collected data, and another ~50 fold > attrition between collected data sets and published structures. > > Personally, I think this means that the time it takes to collect the final > dataset is not rate-limiting in a "typical" structural biology project/paper. > This does not mean that the dataset is of little value. Quite the opposite! > About 3000x more time and energy is expended preparing for the final dataset > than is spent collecting it, and these efforts require experimental feedback. > The trick is figuring out how best to compress the "data used to solve a > structure" for archival storage. Do the "previous data sets" count? Or > should the compression be "lossy" about such historical details? Does the > stuff between the spots matter? After all, h,k,l,F,sigF is really just a > form of data compression. In fact, there is no such thing as "raw" data. > Even "raw" diffraction images are a simplification of the signals that came > out of the detector electronics. But we round-off and average over a lot of > things to remove "noise". Largely because "noise" is difficult to compress. > The question of how much compression is too much compression depends on which > information (aka noise) you think could be important in the future. > > When it comes to fine-sliced data, such as that from Pilatus, the main reason > why it doesn't compress very well is not because of the spots, but the > background. It occupies thousands of times more pixels than the spots. Yes, > there is diffuse scattering information in the background pixels, but this > kind of data is MUCH smoother than the spot data (by definition), and > therefore is optimally stored in larger pixels. Last year, I messed around a > bit with applying different compression protocols to the spots and the > background, and found that ~30 fold compression can be easily achieved if you > apply h264 to the background and store the "spots" with lossless png > compression: > > http://bl831.als.lbl.gov/~jamesh/lossy_compression/ > > I think these results "speak" to the relative information content of the > spots and the pixels between them. Perhaps at least the "online version" of > archived images could be in some sort of lossy-background format? With the > "real images" in some sort of slower storage (like a room full of tapes that > are available upon request)? Would 30-fold compression make the storage of > image data tractable enough for some entity like the PDB to be able to afford > it? > > > I go to a lot of methods meetings, and it pains me to see the most brilliant > minds in the field starved for "interesting" data sets. The problem is that > it is very easy to get people to send you data that is so bad that it can't > be solved by any software imaginable (I've got piles of that!). As a > developer, what you really need is a "right answer" so you can come up with > better metrics for how close you are to it. Ironically, bad, unsolvable data > that is connected to a right answer (aka a PDB ID) is very difficult to > obtain. The explanations usually involve protestations about being in the > middle of writing up the paper, the student graduated and we don't understand > how he/she labeled the tapes, or the RAID crashed and we lost it all, etc. > etc. Then again, just finding someone who has a data set with the kind of > problem you are interested in is a lot of work! So is figuring out which > problem affects the most people, and is therefore "interesting". > > Is this not exactly the kind of thing that publicly-accessible centralized > scie
[ccp4bb] Postdoctoral position at York
Dear all, Applications are invited for a Postdoctoral Research Fellow position working with Prof Gideon Davies within the York Structural Biology Laboratory (YSBL), Department of Chemistry. Applicants should have a Ph.D level qualification in biochemistry and structural biology, preferably with experience of carbohydrate-active enzymes. You will be working primarily on enzymes involved in xyloglucan degradation and modification. The work involves bioinformatics, basic molecular biology, gene expression and protein purification, enzyme kinetics and structure solution by X-ray crystallography. Salary will be £29,099 a year and this is a fixed term post for 24 months on a full time basis. Closing date: Midnight on Monday 14 November 2011. For further information and to apply on-line, please visit our website: _https://jobs.york.ac.uk_Alternatively contact HR Services on 01904 324835 quoting reference number 2073. /The University of York is committed to promoting equality and diversity./
