Dear Matt, There are great responses in this thread already. There are several points and questions from my side: 1) I did not get clearly what exactly was done. Where did you start your paired refinement? What were the statistics for your starting resolution? 2) Did it improve all the way to the higher and higher resolution? 3) There is usually a little improvement in the electron density. Yet detectable. And in some cases, important. 4) PAIREF currently works in "isotropic" mode. We are not yet ready to work with diffraction anistropy. However, we are almost ready to submit an article on how to do it in future. If you were interested, you could contact me off the list. 5) I do not like the values of your Rmerge. Although using this statistic is already obsolete, I see a potential danger there. You have high values already in the LOWEST resolution shell. And it continuously grows up. Are you sure with your space group? Is it possible that you use higher than real symmetry? This would be my guess, but I may be wrong. Strong diffraction anisotropy may also play a role. Feel free to ask further questions. Best regards, Petr
-----Original Message----- From: CCP4 bulletin board <[email protected]> On Behalf Of Matt McLeod Sent: Saturday, October 1, 2022 2:02 PM To: [email protected] Subject: Re: [ccp4bb] PAIREF - Warning - not enough free reflections in resolution bin Hey everyone, Thanks for all the suggestions there are a few different things I can try now. The data is very aniosotropic (STARANISO might help) in regards to how the crystal diffracts and I think changing the bin size will help specifically with PAIREF (its an warning so it completes the run). I collected the data using oil and at room temperature using a vector scan so there are also differences in data quality through the collection (not too severe based on data processing), radiation damage, a changing background from oil, etc. However, diagnosing the problem further it seems that merging with AIMLESS throws a lot of my high resolution reflections out...like alot. This explains why truncating the data doesnt change the maps and explains why my table 1 statistics for high resolution bin are dismal. I can supply log files when I find them. Now I have to determine if the outlier rejections are useful or not and why DIALS processing didn't flag these as rejections. I have yet to look into AIMLESS rejection outlier protocol but I would guess that the reflections are real at high resolution but there are not that many of them and they are not that redundant and therefore are being tossed. Matt ######################################################################## 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/ ######################################################################## 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/
