[ccp4bb] Fwd: [ccp4bb] crystallisation robot
One thing that people often overlook is that quite a lot of protein can be lost by denaturation on the surface of the drop. This is more significant for smaller drops. Two suggestions: (1) increase the proportion of protein in the - technical term - teeny drop to say two thirds and (2) cover the drops with oil eg Al's oils (silicone/paraffin). You still get vapor diffusion though the oil , and you'd like to slow up equilibration. of course (2) slows up the robotics a little, but both should be trivial to set up.. On 1/17/08, Oganesyan, Vaheh [EMAIL PROTECTED] wrote: Mark, What was the state of the larger drops when tiny counterparts had crystals? My guess - they all precipitated. I'm trying to understand why some proteins or some conditions require change in protein concentration while others do not when migrating from smaller drops to larger ones. If it is protein dependent then I'm afraid there might be no one answer; if it is not then there should be a trend and explanation of phenomena. Vaheh From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 8:31 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] crystallisation robot Once upon a time I worked in a group that was interested in developing crystallization in microfluidics. This was before the time that Fluidigm existed and we had not heard of crystallization with the aid of microfluidics at the time. We had good reason to try to make a system that was as small and light as possible - it had something to do with the cost of shipping proteins and precipitants - less was better. And we also wanted all protein drops to be fully enclosed, out of safety considerations. Like Tassos, we were very worried what would happen if you scaled back drops along the lines of this discussion - several uL downto tens of nanoliters. If the stochastic process had a major influence over this process, we thought that we would never get any crystals. So we set up side-by-side experiments at larger volumes and smaller volumes - basically scanning several orders of magnitude - expecting a decrease of the number of crystals when volumes decrease. To our great surprise the outcome was that smaller volumes almost always gave MORE (I almost want to say 'dramatically more') crystals, more nucleation, and indeed in various cases the crystals grew much faster also. Indeed, it was trivial to observe that the surface-to-volume ratio was the primary driver for the nucleation process. We had control over geometry to some extent and were able to observe surfaces while crystals grow. The crystals would most commonly nucleate on a surface. So although there probably is something to stochastic aspects, it is clear that other aspects can be more important and overrule the stochastic considerations. The somewhat unpleasant consquence is of course that results acquired in very small volumes (with larger surface-to-volume ratio) cannot necessarily be repeated in larger volumes (smaller surface-to-volume ratio). This is not a flame, even if heat might be a good thing on a night with temperatures predicted far below 0F. :-) Mark -Original Message- From: Anastassis Perrakis [EMAIL PROTECTED] To: CCP4BB@JISCMAIL.AC.UK Sent: Wed, 16 Jan 2008 6:17 am Subject: Re: [ccp4bb] crystallisation robot Oryxnano 50+50 nL Demetres Which, indirectly, brings up an interesting (but not relevant to the Oryx) question. Nucleation is a process that does have a stochastic aspect. Thus, one could argue that compromising to 200-300 nl might be better than either extremes of 50nl (too small volume and less chance for nucleation) or 1000 nl (too much sample). any comments ? (let the flames begin). A. PS1 another interesting issue that has has been hardly touched in these emails is the real sample loss: left in wells and not easy to recover, lost because of contamination with system liquid, etc ... PS2 I see lots of people with new robots. please do have a look at the www.BIOXHIT.org page and if you have a few minutes to assemble a table we will be happy to add your specs to our pages. it can be a nice resource and it has already enough things and already one response to my last email ;-) To make life easier to potential contributors we can provide an Excel sheet to fill up with your specs - just ask. On Jan 16, 2008, at 12:46, Demetres D. Leonidas wrote: David Briggs wrote: I'll defend the honour of the phoenix... (again) Bernhard Rupp 100+100 nl Dave Briggs (and all users at Univ of Manchester, UK) 100+100nl Others.. Only time we have ANY problems is when the nano dispensing tip gets clogged. Often a good wash whilst still on the machine will clear the blockage. Dave -- David C.
Re: [ccp4bb] combine incomplete data sets
Oops. My link terminology were a little wayward... I knew what I meant, but the incorrect link may have proven misleading. But the answer essentially remains the same: 1) Integrate everything in MOSFLM 2) Enforce consistent indexing using POINTLESS (unless I am mistaken, there are alternative indexing possibilities(s) in p321) http://www.ccp4.ac.uk/dist/html/alternate_origins.html http://www.ccp4.ac.uk/dist/html/reindexing.html ^^ ftp://ftp.ccp4.ac.uk/ccp4/6.0.2/prerelease/pointless.html 3) Bundle ALL integrated datasets into one .mtz file (being such to make sure all the batch number do not conflict)(POINTLESS may do this for you now) 4) Push through SCALA/Truncate in one giant run - selecting your 'best' dataset as a reference. I hope this is clear now. Apologies if this has confused anyone. Dave -- David C. Briggs PhD Father Crystallographer http://www.dbriggs.talktalk.net AIM ID: dbassophile
Re: [ccp4bb] differences between Rsym and Rmerge
I seem to recall hearing Rsym first when I used the Xuong-Hamlin detector, since there were a substantial number of redundancies. There were two Rsyms, one called Rrms for the sqrt over the sum of weighted squared differences and and Rav for the linear summation of unweighted differences. This was for protein work. I do recall Rmerge being more popular with the small molecule crystallographers. However, I also recall a difference between averaging over pairs of reflections that were or were not Bijvoet pairs, for even small differences in the anomalous scattering contributions. Bernie On Fri, January 18, 2008 9:29 am, R.M. Garavito wrote: Kay, I beg to differ, but only in a pedantic way. Historically, Rsym would refer to the agreement in symmetry-related reflections within a single data set and Rmerge would be the agreement between 2 or more data sets that were merged. This was the way we did it back in the old day of precession photography and early oscillation photography. While the terms seem synonymous today, the recent thread [ccp4bb] combine incomplete data sets illustrates where such a distinction is still relevant, where the merging is between data collected under different experimental conditions (i.e., a different crystal in a different orientation). Michael R. Michael Garavito, Ph.D. Professor of Biochemistry Molecular Biology 513 Biochemistry Bldg. Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: [EMAIL PROTECTED] On Jan 18, 2008, at 10:15 AM, Kay Diederichs wrote: Salameh, Mohd A., Ph.D. schrieb: Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M there is no difference - unfortunately there are two words for the same thing. Rmerge currently appears to be more in fashion. just my 2 cents, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: [EMAIL PROTECTED]Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
[ccp4bb] differences between Rsym and Rmerge
Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED]
Re: [ccp4bb] differences between Rsym and Rmerge
I had learned that Rsym compared symmetry-related reflections within an image or film (in the context of a rotation exposure), and Rmerge compared symmetry-related reflections on different images or films with one another. Is that wrong? Bill Manfred S. Weiss wrote: Dear Mohd and all others, Well, I guess it is time again to define and talk about R-factors. The term R_sym goes back to the times, when X-ray data were recorded by precession photography on film. Except for the central cone, each reflection was observed only once and R_sym described the agreement strictly between symetry-related reflections, hence R_sym. In diffractometer times, when reflections were measured one by one, only for a subset of reflections (typically a plane in reciprocal space) were symmetry-related reflections measured two times. R_sym became R_int, where int stands for internal agreement. These additional reflections were just measured to calculate R_int, later on they were discarded. Nowadays, where a diffraction data set typically consists of dozens or hundreds of images recorded from some sort of an area detector, multiple measurements of the same reflection AND symmetry-related reflections are merged together to calculate the mean intensity for a given reflection. Hence, the agreement factor becomes R_merge or merging R-factor. As you can see, R_merge is more general than R_sym, and is (as Kay pointed out) the preferred term. However, when talking about R-factor I can never refrain from mentioning that R_merge should actually NEVER EVER be used, because it is inherently flawed. As the redundancy or the multiplicity of the data increases, R_merge will also increase, although the mean intensity will be more precisely determined. As was postulated by Kay and myself about 10 years ago, R_merge should be replaced by a redundancy-independent merging R-factor (termed R_rim or R_meas). Unfortunately, only SCALA and XDS produce this R-factor, SCALEPACK does not (not yet, I hope -- pun to Dallas). If you want to calculate R_rim or R_meas based on scaled but unmerged data, I have my own program, which you can download from my web site, as does Kay. I hope this clarifies things. Cheers, Manfred. * * *Dr. Manfred S. Weiss * * * * Team Leader * * * * EMBL Hamburg OutstationFon: +49-40-89902-170 * * c/o DESY, Notkestr. 85 Fax: +49-40-89902-149 * * D-22603 Hamburg Email: [EMAIL PROTECTED] * * GERMANY Web: www.embl-hamburg.de/~msweiss/ * * * On Fri, 18 Jan 2008, Salameh, Mohd A., Ph.D. wrote: Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED]
Re: [ccp4bb] Fwd: [ccp4bb] crystallisation robot
Al's Oil on the plates: What a nightmare!!! The oil creeps up the plate and over the sides. It dissolves adhesives. It makes me say bad words in multiple languages. Bigger drops + no oil = fewer bad words. Lisa -- Lisa A. Nagy, Ph.D. University of Alabama-Birmingham [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Shaw Stewart Sent: Friday, January 18, 2008 2:20 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Fwd: [ccp4bb] crystallisation robot One thing that people often overlook is that quite a lot of protein can be lost by denaturation on the surface of the drop. This is more significant for smaller drops. Two suggestions: (1) increase the proportion of protein in the - technical term - teeny drop to say two thirds and (2) cover the drops with oil eg Al's oils (silicone/paraffin). You still get vapor diffusion though the oil , and you'd like to slow up equilibration. of course (2) slows up the robotics a little, but both should be trivial to set up..
Re: [ccp4bb] differences between Rsym and Rmerge
Dear Mohd and all others, Well, I guess it is time again to define and talk about R-factors. The term R_sym goes back to the times, when X-ray data were recorded by precession photography on film. Except for the central cone, each reflection was observed only once and R_sym described the agreement strictly between symetry-related reflections, hence R_sym. In diffractometer times, when reflections were measured one by one, only for a subset of reflections (typically a plane in reciprocal space) were symmetry-related reflections measured two times. R_sym became R_int, where int stands for internal agreement. These additional reflections were just measured to calculate R_int, later on they were discarded. Nowadays, where a diffraction data set typically consists of dozens or hundreds of images recorded from some sort of an area detector, multiple measurements of the same reflection AND symmetry-related reflections are merged together to calculate the mean intensity for a given reflection. Hence, the agreement factor becomes R_merge or merging R-factor. As you can see, R_merge is more general than R_sym, and is (as Kay pointed out) the preferred term. However, when talking about R-factor I can never refrain from mentioning that R_merge should actually NEVER EVER be used, because it is inherently flawed. As the redundancy or the multiplicity of the data increases, R_merge will also increase, although the mean intensity will be more precisely determined. As was postulated by Kay and myself about 10 years ago, R_merge should be replaced by a redundancy-independent merging R-factor (termed R_rim or R_meas). Unfortunately, only SCALA and XDS produce this R-factor, SCALEPACK does not (not yet, I hope -- pun to Dallas). If you want to calculate R_rim or R_meas based on scaled but unmerged data, I have my own program, which you can download from my web site, as does Kay. I hope this clarifies things. Cheers, Manfred. * * *Dr. Manfred S. Weiss * * * * Team Leader * * * * EMBL Hamburg OutstationFon: +49-40-89902-170 * * c/o DESY, Notkestr. 85 Fax: +49-40-89902-149 * * D-22603 Hamburg Email: [EMAIL PROTECTED] * * GERMANY Web: www.embl-hamburg.de/~msweiss/ * * * On Fri, 18 Jan 2008, Salameh, Mohd A., Ph.D. wrote: Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED]
Re: [ccp4bb] differences between Rsym and Rmerge
On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new set of terms with clearly defined meanings (and whose names would be used explicitly by new releases of MOSFLM, HKL2000, etc. and changes for new entries in the PDB). If new terms were to be adopted, they ought to specifically distinguish between single crystal and multi-crystal merging. I see three such R values that might be useful (I've arbitrarily chosen names to distinguish them from each other and the older terms): Rhkl - R of identical hkl's Rrot - R of symmetry-related hkls, but not Bijvoet pairs (rot coming from the concept that all symmetry-related reflections can be found via rotations in reciprocal space and the fact that sym has already been used) RBijvoet - R of symmetry-related and Bijvoet-related hkls (including reflections related by both rotations and an inversion center in reciprocal space) Rhkl,multi - multi-crystal version of Rhkl Rrot,multi - muti-crystal version of Rrot RBijvoet,multi - multi-crystal version of RBijvoet The downside of adopting new names is that it makes the previous literature obsolete, but I wonder if the older terms were ambiguous enough that that's not such a problem. -- Christopher Putnam, Ph.D. Assistant Investigator Ludwig Institute For Cancer Research
Re: [ccp4bb] differences between Rsym and Rmerge
Kay, I beg to differ, but only in a pedantic way. Historically, Rsym would refer to the agreement in symmetry-related reflections within a single data set and Rmerge would be the agreement between 2 or more data sets that were merged. This was the way we did it back in the old day of precession photography and early oscillation photography. While the terms seem synonymous today, the recent thread [ccp4bb] combine incomplete data sets illustrates where such a distinction is still relevant, where the merging is between data collected under different experimental conditions (i.e., a different crystal in a different orientation). Michael R. Michael Garavito, Ph.D. Professor of Biochemistry Molecular Biology 513 Biochemistry Bldg. Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: [EMAIL PROTECTED] On Jan 18, 2008, at 10:15 AM, Kay Diederichs wrote: Salameh, Mohd A., Ph.D. schrieb: Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M there is no difference - unfortunately there are two words for the same thing. Rmerge currently appears to be more in fashion. just my 2 cents, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: [EMAIL PROTECTED]Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
Re: [ccp4bb] How to refine a structure with ATP and AMP and pyrophosphate sharing the same density in CCP4i?
Hello Sun, Roman Hillig and I refined a mixture of ADP+PO4 and ATP in the active site of ARL2 - it is enough to exclude all contacts of the superposing ligands and let the occupancies refine. The protocol we followed is described in: Hanzal-Bayer M, Renault L, Roversi P, Wittinghofer A, Hillig RC. Free in PMC The complex of Arl2-GTP and PDE delta: from structure to function. EMBO J. 2002 May 1;21(9):2095-106. Best of luck! Pietro [EMAIL PROTECTED] writes: Hello everyone, I have a structure of intermediate state in which about half amount of ATP decomposed to AMP and pyrophosphate. The ATP and AMP + pyrophosphate have little difference in conformation, sharing the same electron density. I just gave them different residue ID and did the TLS and restrained refinement in CCP4i. It is hard to tell from the R-factor because they are only a very small part of the whole structure. Can anyone tell whether it is the correct way to do? Any suggestions are greatly appreciated. Thank you very much! Sincerely, Sun Tang - Never miss a thing. Make Yahoo your homepage.
Re: [ccp4bb] differences between Rsym and Rmerge
Truncate reports I/sigI for reflections in the 30deg cones around the reciprocal cell axes. Dead handy... [EMAIL PROTECTED] wrote: High R merges with no reasonable excuse can certainly be a useful red flag during data processing (along with the % of observations rejected, which I've never had a reviewer request). Which brings up the point that one reasonable excuse is anisotropy - high Rs for merging random observations in the imaginary direction will be combined with lower Rs for merging decent data in the real direction. Is there any extant software that will calculate directionally-binned Rmerges? It would be useful both for re-assuring users that there isn't anything worse with their data, and for arguing with referees who don't read CCP4BB. Phoebe At 01:18 PM 1/18/2008, Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new set of terms with clearly defined meanings (and whose names would be used explicitly by new releases of MOSFLM, HKL2000, etc. and changes for new entries in the PDB). If new terms were to be adopted, they ought to specifically distinguish between single crystal and multi-crystal merging. I see three such R values that might be useful (I've arbitrarily chosen names to distinguish them from each other and the older terms): Rhkl - R of identical hkl's Rrot - R of symmetry-related hkls, but not Bijvoet pairs (rot coming from the concept that all symmetry-related reflections can be found via rotations in reciprocal space and the fact that sym has already been used) RBijvoet - R of symmetry-related and Bijvoet-related hkls (including reflections related by both rotations and an inversion center in reciprocal space) Rhkl,multi - multi-crystal version of Rhkl Rrot,multi - muti-crystal version of Rrot RBijvoet,multi - multi-crystal version of RBijvoet The downside of adopting new names is that it makes the previous literature obsolete, but I wonder if the older terms were ambiguous enough that that's not such a problem. -- Christopher Putnam, Ph.D. Assistant Investigator Ludwig Institute For Cancer Research Mischa Machius, PhD
Re: [ccp4bb] differences between Rsym and Rmerge
High R merges with no reasonable excuse can certainly be a useful red flag during data processing (along with the % of observations rejected, which I've never had a reviewer request). Which brings up the point that one reasonable excuse is anisotropy - high Rs for merging random observations in the imaginary direction will be combined with lower Rs for merging decent data in the real direction. Is there any extant software that will calculate directionally-binned Rmerges? It would be useful both for re-assuring users that there isn't anything worse with their data, and for arguing with referees who don't read CCP4BB. Phoebe At 01:18 PM 1/18/2008, Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new set of terms with clearly defined meanings (and whose names would be used explicitly by new releases of MOSFLM, HKL2000, etc. and changes for new entries in the PDB). If new terms were to be adopted, they ought to specifically distinguish between single crystal and multi-crystal merging. I see three such R values that might be useful (I've arbitrarily chosen names to distinguish them from each other and the older terms): Rhkl - R of identical hkl's Rrot - R of symmetry-related hkls, but not Bijvoet pairs (rot coming from the concept that all symmetry-related reflections can be found via rotations in reciprocal space and the fact that sym has already been used) RBijvoet - R of symmetry-related and Bijvoet-related hkls (including reflections related by both rotations and an inversion center in reciprocal space) Rhkl,multi - multi-crystal version of Rhkl Rrot,multi - muti-crystal version of Rrot RBijvoet,multi - multi-crystal version of RBijvoet The downside of adopting new names is that it makes the previous literature obsolete, but I wonder if the older terms were ambiguous enough that that's not such a problem. -- Christopher Putnam, Ph.D. Assistant Investigator Ludwig Institute For Cancer Research Mischa Machius, PhD Associate Professor UT Southwestern Medical Center at Dallas 5323 Harry Hines Blvd.; ND10.214A Dallas, TX 75390-8816; U.S.A. Tel: +1 214
Re: [ccp4bb] differences between Rsym and Rmerge
You know there is that other funny column with chi^2's. I like to quote both. Half of the reviewers will know which column to look at, but you will satisfy the other half. Bernie On Fri, January 18, 2008 1:39 pm, Edwin Pozharski wrote: There are two opposing views on this. First: Rmerge doesn't matter. Don't even look into that column in scalepack output, you will be upset over nothing. If you collect twice as much data (360 sweep instead of 180) from the same crystal, your Rmerge will go up due to higher redundancy, but the dataset will actually get better because you measuring every reflection twice more and your I/sigma will increase by ~40%. Second: Rmerge is very important, because if it is, say, 100% (oh, those zeros in the scalepack output) it means that symmetry-related reflections vary by about 100%, so your data is a pile of garbage (at least in that resolution shell). Cut your data at the resolution where Rmerge is 30% and you will be rewarded by really low Rfactors for your final model. Plus, if you keep all the data to where I/sigma~1, your Rmerge is guaranteed to be 0.00 in the output, and what are you going to tell reviewers of your paper? Of course, truth is somewhere in the middle. If I collect on two crystals of the same type (assuming everything else is the same, such as redundancy), and one has much higher Rmerge, then I should probably choose the other one. If you cut resolution at I/sigma~1, and your overall Rmerge is about 10%, I think it's normal. But if it's 30%, you may have some unusually high level of noise in your data (satellite crystal? twinning? evil xray fairy messing with you?). So Rmerge does tell you something, but only in context with all the other information. After all, the only thing that matters is if your electron density map is interpretable. I dare to say that the quality of the map you get does correlate with Rmerge, but would I discard a dataset just because Rmerge is high without trying to solve the structure and take a look at the density? Never. Cheers, Ed. Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new
Re: [ccp4bb] differences between Rsym and Rmerge
Chris Putnam wrote: I won't belabor this point (or defend this view) any further, though I will repeat my surprise at the lack of a clear consensus for what Rsym and Rmerge actually mean, as opposed to things like I/sigma, for example. I/sigma is also open to interpretation. Is it I/sigma or I/sigma (averaged over all the reflection in a given resolution shell)? -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
[ccp4bb] How to refine a structure with ATP and AMP and pyrophosphate sharing the same density in CCP4i?
Hello everyone, I have a structure of intermediate state in which about half amount of ATP decomposed to AMP and pyrophosphate. The ATP and AMP + pyrophosphate have little difference in conformation, sharing the same electron density. I just gave them different residue ID and did the TLS and restrained refinement in CCP4i. It is hard to tell from the R-factor because they are only a very small part of the whole structure. Can anyone tell whether it is the correct way to do? Any suggestions are greatly appreciated. Thank you very much! Sincerely, Sun Tang - Never miss a thing. Make Yahoo your homepage.
Re: [ccp4bb] differences between Rsym and Rmerge
There are two opposing views on this. First: Rmerge doesn't matter. Don't even look into that column in scalepack output, you will be upset over nothing. If you collect twice as much data (360 sweep instead of 180) from the same crystal, your Rmerge will go up due to higher redundancy, but the dataset will actually get better because you measuring every reflection twice more and your I/sigma will increase by ~40%. Second: Rmerge is very important, because if it is, say, 100% (oh, those zeros in the scalepack output) it means that symmetry-related reflections vary by about 100%, so your data is a pile of garbage (at least in that resolution shell). Cut your data at the resolution where Rmerge is 30% and you will be rewarded by really low Rfactors for your final model. Plus, if you keep all the data to where I/sigma~1, your Rmerge is guaranteed to be 0.00 in the output, and what are you going to tell reviewers of your paper? Of course, truth is somewhere in the middle. If I collect on two crystals of the same type (assuming everything else is the same, such as redundancy), and one has much higher Rmerge, then I should probably choose the other one. If you cut resolution at I/sigma~1, and your overall Rmerge is about 10%, I think it's normal. But if it's 30%, you may have some unusually high level of noise in your data (satellite crystal? twinning? evil xray fairy messing with you?). So Rmerge does tell you something, but only in context with all the other information. After all, the only thing that matters is if your electron density map is interpretable. I dare to say that the quality of the map you get does correlate with Rmerge, but would I discard a dataset just because Rmerge is high without trying to solve the structure and take a look at the density? Never. Cheers, Ed. Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new set of terms with clearly defined meanings (and whose names would be used explicitly by new releases of MOSFLM, HKL2000, etc. and changes for new entries in the PDB). If new terms were to be adopted, they ought to specifically distinguish between single crystal and multi-crystal
Re: [ccp4bb] differences between Rsym and Rmerge
Salameh, Mohd A., Ph.D. schrieb: Hi everybody! I will appreciate it if anybody can clarify to me the differences between Rmerge and Rsym. Many thanks, M there is no difference - unfortunately there are two words for the same thing. Rmerge currently appears to be more in fashion. just my 2 cents, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: [EMAIL PROTECTED]Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz smime.p7s Description: S/MIME Cryptographic Signature
Re: [ccp4bb] differences between Rsym and Rmerge
Ed, You don't need to adjust them in XDS. In scalepack, I don't adjust the individual chi^2's (the additive terms, by shell), but I do adjust the multiplier to get the chi^2's in the highest resolution shell, usually with I/sig (or I/sig) ~ 1, to be near and greater than 1.0. Then the overall chi^2's are what they are. My rationale is that the weakest shell will be dominated most by random errors, and should approach 1.0, whereas the lower resolution shells typically have chi^2's greater than 1, and are dominated by systematic (absorption, misalignment, integration) errors. If they aren't close to 1, then that's telling you something, whether or not the R(sym) is. I report the overall chi^2 and the value in the highest resolution shell, and they're in the pdb/cif file. Bernie On Fri, January 18, 2008 2:28 pm, Edwin Pozharski wrote: Bernie, but my chi-squares are always near 1.0, so why would I report it? How close they should be to 1 is open to discussion, of course. The point is, it is assumed (at least in scalepack) that you adjust your error model until chi-square~1. I have never seen a statistics table in a paper which would report chi-suqares. I am afraid I may be misinterpreting what you were trying to say - I apologize if that is the case. Cheers, Ed. Santarsiero, Bernard D. wrote: You know there is that other funny column with chi^2's. I like to quote both. Half of the reviewers will know which column to look at, but you will satisfy the other half. Bernie On Fri, January 18, 2008 1:39 pm, Edwin Pozharski wrote: There are two opposing views on this. First: Rmerge doesn't matter. Don't even look into that column in scalepack output, you will be upset over nothing. If you collect twice as much data (360 sweep instead of 180) from the same crystal, your Rmerge will go up due to higher redundancy, but the dataset will actually get better because you measuring every reflection twice more and your I/sigma will increase by ~40%. Second: Rmerge is very important, because if it is, say, 100% (oh, those zeros in the scalepack output) it means that symmetry-related reflections vary by about 100%, so your data is a pile of garbage (at least in that resolution shell). Cut your data at the resolution where Rmerge is 30% and you will be rewarded by really low Rfactors for your final model. Plus, if you keep all the data to where I/sigma~1, your Rmerge is guaranteed to be 0.00 in the output, and what are you going to tell reviewers of your paper? Of course, truth is somewhere in the middle. If I collect on two crystals of the same type (assuming everything else is the same, such as redundancy), and one has much higher Rmerge, then I should probably choose the other one. If you cut resolution at I/sigma~1, and your overall Rmerge is about 10%, I think it's normal. But if it's 30%, you may have some unusually high level of noise in your data (satellite crystal? twinning? evil xray fairy messing with you?). So Rmerge does tell you something, but only in context with all the other information. After all, the only thing that matters is if your electron density map is interpretable. I dare to say that the quality of the map you get does correlate with Rmerge, but would I discard a dataset just because Rmerge is high without trying to solve the structure and take a look at the density? Never. Cheers, Ed. Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl].
Re: [ccp4bb] differences between Rsym and Rmerge
On Friday 18 January 2008 07:50, Santarsiero, Bernard D. wrote: I do recall Rmerge being more popular with the small molecule crystallographers. However, I also recall a difference between averaging over pairs of reflections that were or were not Bijvoet pairs, for even small differences in the anomalous scattering contributions. That matches my understanding. Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. Although the data processing programs are happy to make this distinction (e.g. the Anomalous and Scale Anomalous tick-boxes in HKL2000), the separate values obtained are rarely seen in a published Table 1. I seem to recall hearing Rsym first when I used the Xuong-Hamlin detector. Same for me. Before that, as a neophyte graduate student, I used a diffractometer and foolishly programmed it to collect only the minimal set of data corresponding to one asymmetric unit of reciprocal space. This demonstrated my understanding of space group symmetry, but also my ignorance of statistics and good experimental practice. Since the resulting data sets contained no symmetry equivalents, there was no Rsym to be calculated. There was still an Rmerge if multiple crystals were used for the collection, however. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742
Re: [ccp4bb] differences between Rsym and Rmerge
My understanding is(was) that Rsym refers to the merging of symmetry-related reflections during scaling whereas Rmerge refers, broadly, to any data merging process, but originally means merging of reflection with the same (hkl). Rcryst then should refer to the merging of data from different crystals. The final number reported by, say, scalepack will thus be both Rsym and Rmerge, but is referred to as Rmerge because Rsym is also an instance of Rmerge, at least semantically. I understand the usefulness of Rsym is limited to the process of space group identification, whereas overall Rmerge reflects (somewhat and in clearly relative fashion) upon the quality of your data. At risk of injecting more controversy to this fairly benign discussion, let me quote Daniel Gewirth: In practice, there are two ways of assessing the high resolution limit of diffraction. The first is the ratio of the intensity to the error of the intensity, i.e. I/σ. The second way, which is traditional but inferior, is the agreement between symmetry related reflections, i.e. Rmerge. So Rmerge is Rsym? What makes this question somewhat irrelevant, however, is this: One of the drawbacks of using Rmerge as a measure of the quality of a data set is that it can be intentionally and unintentionally manipulated. Cheers, Ed. -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
[ccp4bb] Crystallization by pH changes
Hi all! Does anybody have experience with crystallization of proteins by slow drifting of the pH? Let's say, for example, going from pH 7 to pH 5 over 1 week or 1 month. This is supposed to happen by diffusion of volatile molecules like ammonia or acetic acid but I am having a hard time finding any details or protocols. I bet that there is a lot of anecdotal experience out there. Maybe even references? Thanks, Jose. ** Jose Antonio Cuesta-Seijo Cancer Genomics and Proteomics Ontario Cancer Institute, UHN MaRS TMDT Room 4-902M 101 College Street M5G 1L7 Toronto, ON, Canada Phone: (416)581-7544 Fax: (416)581-7562 email: [EMAIL PROTECTED] **
Re: [ccp4bb] differences between Rsym and Rmerge
OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from single crystals have used Rsym rather than Rmerge.) I wonder if the problem here is that the terms have become overloaded (and hence non-specific). In that sense Rmerge is a particularly unfortunate name as every R that we're discussing is a really a merge of some sort or another. (In the most naive sense, Rmerge might be thought to be the R for whatever variation of reflection merging the experimenter chooses to do.) One possible solution would be to push the community towards a new set of terms with clearly defined meanings (and whose names would be used explicitly by new releases of MOSFLM, HKL2000, etc. and changes for new entries in the PDB). If new terms were to be adopted, they ought to specifically distinguish between single crystal and multi-crystal merging. I see three such R values that might be useful (I've arbitrarily chosen names to distinguish them from each other and the older terms): Rhkl - R of identical hkl's Rrot - R of symmetry-related hkls, but not Bijvoet pairs (rot coming from the concept that all symmetry-related reflections can be found via rotations in reciprocal space and the fact that sym has already been used) RBijvoet - R of symmetry-related and Bijvoet-related hkls (including reflections related by both rotations and an inversion center in reciprocal space) Rhkl,multi - multi-crystal version of Rhkl Rrot,multi - muti-crystal version of Rrot RBijvoet,multi - multi-crystal version of RBijvoet The downside of adopting new names is that it makes the previous literature obsolete, but I wonder if the older terms were ambiguous enough that that's not such a problem. -- Christopher Putnam, Ph.D. Assistant Investigator Ludwig Institute For Cancer Research Mischa Machius, PhD Associate Professor UT Southwestern Medical Center at Dallas 5323 Harry Hines Blvd.; ND10.214A Dallas, TX 75390-8816; U.S.A. Tel: +1 214 645 6381 Fax: +1 214 645 6353
Re: [ccp4bb] differences between Rsym and Rmerge
On Fri, 18 Jan 2008, Edwin Pozharski wrote: So Rmerge does tell you something, but only in context with all the other information. this is what Whewell termed the consilience of inductions in the 19th century (which others have expanded since). -bryan
Re: [ccp4bb] differences between Rsym and Rmerge
Bernie, but my chi-squares are always near 1.0, so why would I report it? How close they should be to 1 is open to discussion, of course. The point is, it is assumed (at least in scalepack) that you adjust your error model until chi-square~1. I have never seen a statistics table in a paper which would report chi-suqares. I am afraid I may be misinterpreting what you were trying to say - I apologize if that is the case. Cheers, Ed. Santarsiero, Bernard D. wrote: You know there is that other funny column with chi^2's. I like to quote both. Half of the reviewers will know which column to look at, but you will satisfy the other half. Bernie On Fri, January 18, 2008 1:39 pm, Edwin Pozharski wrote: There are two opposing views on this. First: Rmerge doesn't matter. Don't even look into that column in scalepack output, you will be upset over nothing. If you collect twice as much data (360 sweep instead of 180) from the same crystal, your Rmerge will go up due to higher redundancy, but the dataset will actually get better because you measuring every reflection twice more and your I/sigma will increase by ~40%. Second: Rmerge is very important, because if it is, say, 100% (oh, those zeros in the scalepack output) it means that symmetry-related reflections vary by about 100%, so your data is a pile of garbage (at least in that resolution shell). Cut your data at the resolution where Rmerge is 30% and you will be rewarded by really low Rfactors for your final model. Plus, if you keep all the data to where I/sigma~1, your Rmerge is guaranteed to be 0.00 in the output, and what are you going to tell reviewers of your paper? Of course, truth is somewhere in the middle. If I collect on two crystals of the same type (assuming everything else is the same, such as redundancy), and one has much higher Rmerge, then I should probably choose the other one. If you cut resolution at I/sigma~1, and your overall Rmerge is about 10%, I think it's normal. But if it's 30%, you may have some unusually high level of noise in your data (satellite crystal? twinning? evil xray fairy messing with you?). So Rmerge does tell you something, but only in context with all the other information. After all, the only thing that matters is if your electron density map is interpretable. I dare to say that the quality of the map you get does correlate with Rmerge, but would I discard a dataset just because Rmerge is high without trying to solve the structure and take a look at the density? Never. Cheers, Ed. Mischa Machius wrote: OK, that brings us back to a more substantial question: is any of these R values actually suitable to judge the quality of a given dataset? Instead of introducing novel R factors, one could also simply ignore them altogether, make sure that the error models have been properly chosen and look at I/sigma(I) as the main criterion. [QUOTE ]If anyone then still wants to present low R factors, one can always divide by 2, if necessary. [/QUOTE] Best - MM On Jan 18, 2008, at 1:02 PM, Salameh, Mohd A., Ph.D. wrote: Thank you all, it was very, very helpful discussion. However, I collected crystal data and the Rmerge overall was very high around 0.17 at 2.6A resolution and I'm wondering what is the acceptable value (range) of R-merge that worth the time to continue processing! Very anxious to hear your thoughts. Thanks, M Mohammed A. Salameh, Ph.D. Mayo Clinic Cancer Center Griffin Cancer Research Building 4500 San Pablo Road Jacksonville, FL 32224 Tel:(904) 953-0046 Fax:(904) 953-0277 [EMAIL PROTECTED] -Original Message- From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf Of Chris Putnam Sent: Friday, January 18, 2008 1:21 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] differences between Rsym and Rmerge On Friday 18 January 2008 09:30:06 am Ethan A Merritt wrote: Rmerge is an average over replicate measurements of the intensity for identical [hkl]. Rsym is an average over the measurements for all symmetry equivalent reflections. In the presence of anomalous scattering, Rsym will be higher than Rmerge because the Bijvoet pairs, although symmetry related, do not have identical intensities. One might logically report two values for Rsym, one which averages over the Bijvoet-paired reflections and one which does not. This has been an eye-opening discussion for me. I've been really surprised that there's been such a diversity of opinion about what these common terms ought to refer to, and the fact that my understanding was wrong. I always thought that Rsym was an average over all symmetry equivalent reflections from the same crystal (including Bijvoet pairs) and Rmerge was properly restricted to cases of multi-crystal averaging. (My versions of Table 1's from
Re: [ccp4bb] How to refine a structure with ATP and AMP and pyrophosphate sharing the same density in CCP4i?
In the best case, you would know something about the enzyme bound equilibrium constant between the two ligand mixtures (see, for example, TM Larsen et al Biochemistry 35, 4349). That would give you a good sense of how to model the occupancies of the active site ligands. Unfortunately, in many cases, the on-enzyme equilibrium constant is not known and we are left with mixtures of ligands in the active site. I believe that there is no single correct way to then model your structure and (as with many topics) you¹ll get multiple opinions: You can refine the ³predominant² ligand and acknowledge extra difference density that is likely due to other ligands, you can refine a 50/50 mixture and allow the B-values to accommodate some of the differences, or you can refine some other mixture (although I personally am less comfortable with claiming a 35/65 % mixture of your ligands). As you note, the addition of an extra oxygen is not really going to dramatically alter your R-factors so you cannot rely on that to determine the ³correct² model. I think that what you have described is appropriate. It is now important to provide enough information so that your readers can judge any biochemical interpretations that you make. Best wishes, Andy -- Andrew M. Gulick, Ph.D. Hauptman-Woodward Institute On 1/18/08 3:09 PM, Sun Tang [EMAIL PROTECTED] wrote: Hello everyone, I have a structure of intermediate state in which about half amount of ATP decomposed to AMP and pyrophosphate. The ATP and AMP + pyrophosphate have little difference in conformation, sharing the same electron density. I just gave them different residue ID and did the TLS and restrained refinement in CCP4i. It is hard to tell from the R-factor because they are only a very small part of the whole structure. Can anyone tell whether it is the correct way to do? Any suggestions are greatly appreciated. Thank you very much! Sincerely, Sun Tang
