Last week I asked a question about geometry restraints at low resolution. I would like to thank you all that took the time to answer, specially Pavel for looking at the data. First, here is the original question: __________________________________________ I am refining a low resolution structure (2.9A) using phenix.refine. As I continue the refinement Rwork/Rfree are dropping but my geometry statistics in general are very bad. My clashscore is getting worst and the RMS(angle) is really high. I have tried to play with the "wxc_scale" parameter and also ran phenix selecting the "Optimize X-ray/ADP weight" option. All attempts end with a RMS(angle) of ~3.8 and a Clashscore of ~190. Is there a known procedure to deal with this? I feel that my geometry weighing term is too loose but I don't know exactly how to tighten it other than decreasing the wxc_scale parameter. I have gone and manually corrected bad positions before but given the low resolution nature of the structure the clashes tend to be reestablished during refinement. Thank you in advance for your help, __________________________________________ It turns out that the reason to my nightmares was a highly anisotropic dataset. When I tried to fix geometry related problems in coot, phenix.refine was twisting the geometry back again, probably because it was trying to fit a lot of noise due to the anisotropy. Everything was getting worst, geometry, clashscore, and Ramachandran. Pavel finally corrected it by using this server: http://services.mbi.ucla.edu/anisoscale/ I should have been more diligent regarding that, since I could clearly see that my data was anisotropic from the diffraction images. I just didn't know how important this parameter could be. Anyways, phenix.xtriage will tell you if your data is anisotropic. The lesson is to pay attention to it. In my case, the quality of the electron density improved considerably, the geometry improved massively (manual intervention in coot was absolutely necessary, but now it stays correct after I manually fix the problems), clashscore lowered, etc. As a side note, it worked better without hydrogens in my case than with. It is certainly a parameter to try if you are having problems. Thank you all again for the tips. Mario Sanches -- Mario Sanches Postdoctoral Researcher Samuel Lunenfeld Research Institute Mount Sinai Hospital 600 University Ave Toronto - Ontario Canada M5G 1X5 http://ca.linkedin.com/in/mariosanches
1. If you take the final refined structure and refine against the original anisotropic data, does the geometry go bad again? It would be interesting to know if fixing the anisotropy fixed the problem, or fixing the anisotropy improved the maps so you could see the problem and fix it in coot. 2. When you deposit the structure in the PDB, will you supply the anisotropy-corrected data, or the original raw data? eab Mario Sanches wrote:
Last week I asked a question about geometry restraints at low resolution. I would like to thank you all that took the time to answer, specially Pavel for looking at the data. First, here is the original question:
__________________________________________ I am refining a low resolution structure (2.9A) using phenix.refine. As I continue the refinement Rwork/Rfree are dropping but my geometry statistics in general are very bad. My clashscore is getting worst and the RMS(angle) is really high. I have tried to play with the "wxc_scale" parameter and also ran phenix selecting the "Optimize X-ray/ADP weight" option. All attempts end with a RMS(angle) of ~3.8 and a Clashscore of ~190.
Is there a known procedure to deal with this? I feel that my geometry weighing term is too loose but I don't know exactly how to tighten it other than decreasing the wxc_scale parameter. I have gone and manually corrected bad positions before but given the low resolution nature of the structure the clashes tend to be reestablished during refinement.
Thank you in advance for your help, __________________________________________
It turns out that the reason to my nightmares was a highly anisotropic dataset. When I tried to fix geometry related problems in coot, phenix.refine was twisting the geometry back again, probably because it was trying to fit a lot of noise due to the anisotropy. Everything was getting worst, geometry, clashscore, and Ramachandran.
Pavel finally corrected it by using this server: http://services.mbi.ucla.edu/anisoscale/ I should have been more diligent regarding that, since I could clearly see that my data was anisotropic from the diffraction images. I just didn't know how important this parameter could be. Anyways, phenix.xtriage will tell you if your data is anisotropic. The lesson is to pay attention to it.
In my case, the quality of the electron density improved considerably, the geometry improved massively (manual intervention in coot was absolutely necessary, but now it stays correct after I manually fix the problems), clashscore lowered, etc.
As a side note, it worked better without hydrogens in my case than with. It is certainly a parameter to try if you are having problems.
Thank you all again for the tips.
Mario Sanches
-- Mario Sanches Postdoctoral Researcher Samuel Lunenfeld Research Institute Mount Sinai Hospital 600 University Ave Toronto - Ontario Canada M5G 1X5 http://ca.linkedin.com/in/mariosanches
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On Wed, Apr 25, 2012 at 9:36 AM, Edward A. Berry
1. If you take the final refined structure and refine against the original anisotropic data, does the geometry go bad again? It would be interesting to know if fixing the anisotropy fixed the problem, or fixing the anisotropy improved the maps so you could see the problem and fix it in coot.
I didn't do this test, but it is simple enough. I will run it latter.
2. When you deposit the structure in the PDB, will you supply the anisotropy-corrected data, or the original raw data?
That is a really good question. Is there any recommendation from the PDB regarding that? I tend to think that both should be available, since one is the raw data, and the other is the data the structure was refined against.
eab
Mario Sanches wrote:
Last week I asked a question about geometry restraints at low resolution. I would like to thank you all that took the time to answer, specially Pavel for looking at the data. First, here is the original question:
______________________________**____________ I am refining a low resolution structure (2.9A) using phenix.refine. As I continue the refinement Rwork/Rfree are dropping but my geometry statistics in general are very bad. My clashscore is getting worst and the RMS(angle) is really high. I have tried to play with the "wxc_scale" parameter and also ran phenix selecting the "Optimize X-ray/ADP weight" option. All attempts end with a RMS(angle) of ~3.8 and a Clashscore of ~190.
Is there a known procedure to deal with this? I feel that my geometry weighing term is too loose but I don't know exactly how to tighten it other than decreasing the wxc_scale parameter. I have gone and manually corrected bad positions before but given the low resolution nature of the structure the clashes tend to be reestablished during refinement.
Thank you in advance for your help, ______________________________**____________
It turns out that the reason to my nightmares was a highly anisotropic dataset. When I tried to fix geometry related problems in coot, phenix.refine was twisting the geometry back again, probably because it was trying to fit a lot of noise due to the anisotropy. Everything was getting worst, geometry, clashscore, and Ramachandran.
Pavel finally corrected it by using this server: http://services.mbi.ucla.edu/**anisoscale/http://services.mbi.ucla.edu/anisoscale/ I should have been more diligent regarding that, since I could clearly see that my data was anisotropic from the diffraction images. I just didn't know how important this parameter could be. Anyways, phenix.xtriage will tell you if your data is anisotropic. The lesson is to pay attention to it.
In my case, the quality of the electron density improved considerably, the geometry improved massively (manual intervention in coot was absolutely necessary, but now it stays correct after I manually fix the problems), clashscore lowered, etc.
As a side note, it worked better without hydrogens in my case than with. It is certainly a parameter to try if you are having problems.
Thank you all again for the tips.
Mario Sanches
-- Mario Sanches Postdoctoral Researcher Samuel Lunenfeld Research Institute Mount Sinai Hospital 600 University Ave Toronto - Ontario Canada M5G 1X5 http://ca.linkedin.com/in/**mariosancheshttp://ca.linkedin.com/in/mariosanches
______________________________**_________________ phenixbb mailing list [email protected] http://phenix-online.org/**mailman/listinfo/phenixbbhttp://phenix-online.org/mailman/listinfo/phenixbb
-- Mario Sanches Postdoctoral Researcher Samuel Lunenfeld Research Institute Mount Sinai Hospital 600 University Ave Toronto - Ontario Canada M5G 1X5 http://ca.linkedin.com/in/mariosanches
On Wed, Apr 25, 2012 at 9:05 AM, Mario Sanches
Pavel finally corrected it by using this server: http://services.mbi.ucla.edu/anisoscale/
wondering about a number of things on the topic of anisotropic diffraction vis-a-vis phenix : * what does any phenix subprogram do lately in this regard - truncate or scale, etc? i.e. why use the UCLA server at this point if it uses phaser anyways - just to truncate? is anisodisp.f a phaser subroutine? it is not clear to me what is going on in phenix - phaser applies aniso scaling all the time - does phenix.refine do this? what about with unmerged data as in autosol/autobuild? why? I also note that the Sawaya powerpoint shows over 30% of the original (merged?) data in the example is rejected. (not-so phenix-related): * would not anisotropic scaling/truncation be more appropriate to apply to unmerged data - although they have a program downloadable, the server does not run this. * mosflm has been able to run anisotropic scaling for a while (see below - worthwhile CCP4 thread). * does aimless (previously scala) run anisotropic scaling? (i'll ask on ccp4) ref: http://www.mail-archive.com/[email protected]/msg12316.html -Bryan
On Wed, Apr 25, 2012 at 11:56 AM, Bryan Lepore
* mosflm has been able to run anisotropic *********** for a while (see below - worthwhile CCP4 thread).
major error, sorry : this should be "anisotropic RESOLUTION LIMITS*.
ref: http://www.mail-archive.com/[email protected]/msg12316.html
participants (3)
-
Bryan Lepore -
Edward A. Berry -
Mario Sanches