Hi, I think the point about an R-factor of 42% is a bit more subtle than it comes across in Martin’s reply. For random data without measurement errors (i.e. coming from a Wilson distribution of intensities), the expected R-factor for acentric data is something like 59%. The 42% in Evans & Murshudov comes about when the intensities have such large errors that the measurements don’t contribute any information to the amplitudes, so after running the French/Wilson algorithm in truncate, they all have the same value, i.e. the expected value of an amplitude before making a measurement. So 42% is the R-factor expected for data that are all equal to the average of the structure factor amplitudes they’re being compared to.
In this data set, with I/sig(I) dropping to about 0.1 in the high resolution shells, an R of 42% or so would be expected, because all the “measured” amplitudes (produced by truncate) will have almost the same value. Best wishes, Randy Read > On 23 Jan 2024, at 14:49, Martin Malý <martin.maly...@email.cz> wrote: > > Dear all, > > I am sorry for a late reply. R-values should not exceed 0.42 which happened > in your case for shells 1.91-1.83 and 1.83-1.77. It is because theoretically > (under some assumptions), a perfect model gives an R value of 0.42 against > random data (Evans & Murshudov 2013 https://doi.org/10.1107/S0907444913000061 > ). So as David wrote, your data are not better than 1.9 A. I would refine the > structure against data at resolution of 2.2 A (including modelling of water > molecules), then run paired refinement to add resolution shells 2.2-2.1, > 2.1-2.0 and 2.0-1.9A and choose an optimal high-resolution cutoff according > results. Feel free to ask. > > "the actual reflections used in calculations and reported statistics may be > different (in phenix.refine)" > Thank for this comment, this was new for me, good to know! I can imagine it > can cause misleading situations/interpretations... > > Nowadays, I quite often hear an opinion "You do not have to cut your data at > high-resolution, refinement program will put low weights for noisy > high-resolution reflections so they will not harm your model." I just would > like to ask Pavel and other refinement experts - would you dis/agree? Such an > approach should be possible by principle but R-values etc. look quite ugly > then. > > Best wishes, > Martin > > On Wed, 2024-01-17 at 18:15 -0800, Pavel Afonine wrote: >> >> >> Hi Liliana, >> >> a few things to consider: >> >> 0) There is a Phenix mailing list for Phenix specific questions (phenixbb); >> >> 1) Bin completeness depends on (obviously) how binning is done (number of >> reflections per bin or number of bins or binning in d^2 or d^3 spacing or >> log-binning etc etc etc) -- all of this will affect the number of >> reflections in the "highest resolution bin" and corresponding statistics. >> And..."how binning is done" wildly differs by the program used or even >> within the same program! >> >> 2) Refinement (in Phenix) as well as many other Phenix tools apply temporary >> reflection omission according to the Read (1999) paper (Acta Cryst. (1999). >> D55, 1759-1764). This means while you have so many reflections in your input >> reflection file, the actual reflections used in calculations and reported >> statistics may be different. Most logs files keep a good record of this, >> meaning you can track this down by inspecting logs files carefully. >> >> Let me know if you need more assistance with this issue. >> >> Cheers, >> Pavel >> >> On Wed, Jan 17, 2024 at 1:43 PM David Briggs <david.bri...@crick.ac.uk> >> wrote: >>> Hi Liliana, >>> >>> Two things leap out at me when I look at your data summary. >>> >>> (1) Your data probably do not go to 1.77Å. The CC1/2 in your outer shell is >>> below any of the usual thresholds. There are discussions to be had about >>> what the threshold is, but normally CC1/2 values of 0.5 or sometimes 0.3 >>> are used. You should also consider I/sigI. >>> >>> (2) I believe that by default Phenix.refine excludes weaker reflections >>> from refinement, which leads to the discrepancy in completeness statistics. >>> As your data do not extend as far as what is contained in your mtz file, >>> Phenix excludes those essentially "empty" reflections. Judging by the >>> Phenix refine output, I would estimate your data goes to somewhere around >>> 1.9Å >>> >>> The program Pairef can help inform your choice of high-resolution cutoff. >>> >>> This can be run from CCP4cloud, but is also available for Phenix, I believe. >>> >>> See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8248825/ >>> >>> Hope this helps, >>> >>> Dave >>> >>> >>> Dr David C. Briggs CSci MRSB >>> Principal Laboratory Research Scientist >>> Signalling and Structural Biology Lab >>> The Francis Crick Institute >>> London, UK >>> == >>> about.me/david_briggsFrom: CCP4 bulletin board <CCP4BB@JISCMAIL.AC.UK> on >>> behalf of Liliana Margent <lmarg...@gradcenter.cuny.edu> >>> Sent: Wednesday, January 17, 2024 9:19:36 PM >>> To: CCP4BB@JISCMAIL.AC.UK <CCP4BB@JISCMAIL.AC.UK> >>> Subject: [ccp4bb] Resolution Discrepancy in Data Set >>> >>> External Sender: Use caution. >>> >>> >>> Hello all, >>> >>> I hope this message finds you well. >>> >>> In my current data set, I’ve encountered a discrepancy between the >>> completeness in the high-resolution shells in merged statistics vs the >>> refinement statistics. For example, when I look at my merged statistics >>> file, output by Xia2 dials, the completeness in the high-resolution shells >>> are 97.6%. When I take this data and subsequently refine it in PHENIX I get >>> extremely different completeness ranges in the high-resolution shells, but >>> I cannot figure out why this large difference is occurring. I’m reaching >>> out to you, our esteemed community, for any insights or advice you might >>> have. Has anyone else faced a similar challenge? If so, how did you >>> navigate through it? Your experiences and suggestions could be invaluable >>> in helping me understand and resolve this issue. >>> >>> Thank you in advance for your time and expertise. >>> >>> Best regards, >>> Liliana >>> >>> see a side-by-side image of the files I mention in the message in >>> https://drive.google.com/file/d/1Y783MzlnqVwXRCtiLeV0Y2EpmkeDL2nd/view?usp=sharing >>> >>> ######################################################################## >>> >>> To unsubscribe from the CCP4BB list, click the following link: >>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 >>> >>> This message was issued to members of http://www.jiscmail.ac.uk/CCP4BB, a >>> mailing list hosted by http://www.jiscmail.ac.uk/, terms & conditions are >>> available at https://www.jiscmail.ac.uk/policyandsecurity/ >>> The Francis Crick Institute Limited is a registered charity in England and >>> Wales no. 1140062 and a company registered in England and Wales no. >>> 06885462, with its registered office at 1 Midland Road London NW1 1AT >>> >>> To unsubscribe from the CCP4BB list, click the following link: >>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 >> >> >> To unsubscribe from the CCP4BB list, click the following link: >> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 > > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 ----- Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: +44 1223 336500 The Keith Peters Building Hills Road E-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk ######################################################################## To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
