Refine pixel size of map (for EM data)?
Hello, I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement. Although we try to calibrate this as best as we are able at the time of data collection, it is never perfect - for example, in one case I have dealt with, our nominal pixel size out of the scope is 1.19 Å, but the pixel size calibrated based on a crystal structure of a fragment of the protein is 1.25 Å. This is not a huge difference, but it is sufficient I think to have a substantial impact on refinement, particularly as regards clash assessment and H-bond/sec struc restraints. In cases where one does not have a solved crystal structure to use for calibration, perhaps refining the pixel size in conjunction with the geometry might be of some use? Cheers, Oli
Hi Oliver,
Out of curiosity:
1. what kind of R-factors and CC-values do you get when refining against the two different pixel size?
2. how different are your refined pixel sizes from one reconstruction to another?
?3. how much of an affect does the wrong pixel size have on your downstream structure analysis (e.g. BDA, ASA, electrostatic...)?
Best wishes,
Reza
Reza Khayat, PhD
Assistant Professor
City College of New York
Department of Chemistry
New York, NY 10031
________________________________
From: [email protected]
Hi Reza,
Second question first - not much (I can't detect any), assuming same scope
and mag (which is relieving for multiple reasons). However, I don't know
how close the pixel size I obtain by real space correlation with a crystal
structure is to the "true" pixel size, and whether it is wrong in any
systematic way.
Re the other questions, I have not compared rigorously (I only refined
against the map with the correct pixel size), but I undertook steps to
correct it when I noticed during initial building in Coot that known
(solved) domains were not quite fitting the density as well as expected. I
would expect some consequences from this, particularly in terms of clash
analysis and the use of reference restraints (not sure about electrostatics
etc).
Where it does make a big difference is in comparing structures of the same
or related proteins solved by different groups - if the pixel size varies
by even 1-2%, this really messes up structural superposition for large
structures (if the structure is 300Å, this could be a 6 Å difference in
size). In my experience many groups don't seem to do this - there are quite
a lot of recent maps in the EMDB in which the nominal pixel size has been
taken as correct, and calibration with a crystal structure shows that it is
a ways off (this also affects the estimated resolution, sometimes
substantially).
Cheers,
Oli
On Mon, Feb 8, 2016 at 11:38 AM, Reza Khayat
Hi Oliver,
Out of curiosity:
1. what kind of R-factors and CC-values do you get when refining against the two different pixel size?
2. how different are your refined pixel sizes from one reconstruction to another?
3. how much of an affect does the wrong pixel size have on your downstream structure analysis (e.g. BDA, ASA, electrostatic...)?
Best wishes, Reza
Reza Khayat, PhD Assistant Professor City College of New York Department of Chemistry New York, NY 10031 ------------------------------ *From:* [email protected] < [email protected]> on behalf of Oliver Clarke < [email protected]> *Sent:* Monday, February 8, 2016 4:28 AM *To:* [email protected] *Subject:* [phenixbb] Refine pixel size of map (for EM data)?
Hello,
I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement.
Although we try to calibrate this as best as we are able at the time of data collection, it is never perfect - for example, in one case I have dealt with, our nominal pixel size out of the scope is 1.19 Å, but the pixel size calibrated based on a crystal structure of a fragment of the protein is 1.25 Å. This is not a huge difference, but it is sufficient I think to have a substantial impact on refinement, particularly as regards clash assessment and H-bond/sec struc restraints.
In cases where one does not have a solved crystal structure to use for calibration, perhaps refining the pixel size in conjunction with the geometry might be of some use?
Cheers, Oli
Hi Oli,
Yes, this is a problem that has always plagued EM. Unfortunately it was never really dealt with because it's not much of an issue for lower resolution image reconstructions unless you're doing very detailed difference maps from the X-ray model. The problem is more pronounced now because atoms are finally being modelled into the reconstructions. This is something that most microscopists are not familiar with and thus do no go through the rigour of pixel correction. Most magnification/pixel size calibrations involve using diffraction from a 2D crystal with known cell parameters. This, in my opinion, is insufficient given that protein isomorphous x-tals are not all that common. Moreover, we know from our x-ray crystallography experiments that the final lattice constants of a x-tal are calculated during the scaling stage not just the indexing stage.
I would imaging that the rmsd values for your bonds and angles are a bit messed up as well. Your fastest way of dealing with the situation is to write scripts that modify the pixel size and calculate CC-values or R/Rfree factors between your model and the image reconstruction.
Reza
Reza Khayat, PhD
Assistant Professor
City College of New York
Department of Chemistry
New York, NY 10031
________________________________
From: Oliver Clarke
Hi Reza, geometry of refined model may be severely distorted if your target map on a wrong scale (magnification). Some relevant reading: 1) Automatic estimation and correction of anisotropic magnification,distortion in electron microscopes,Timothy Grant, Nikolaus Grigorieff Journal of Structural Biology 192 (2015) 204–208 2) Electron cryomicroscopy observation of rotational states in a eukaryotic V-ATPase, Jianhua Zhao, Samir Benlekbir & John L. Rubinstein Nature 521, 241–245 (14 May 2015) 3) Description and comparison of algorithms for correcting anisotropic magnification in cryo-EM images. Jianhua Zhao, Marcus A. Brubaker, Samir Benlekbir, John L. Rubinstein Pavel On 2/8/16 02:38, Reza Khayat wrote:
Hi Oliver,
Out of curiosity:
1. what kind of R-factors and CC-values do you get when refining against the two different pixel size?
2. how different are your refined pixel sizes from one reconstruction to another?
3. how much of an affect does the wrong pixel size have on your downstream structure analysis (e.g. BDA, ASA, electrostatic...)?
Best wishes, Reza
Reza Khayat, PhD Assistant Professor City College of New York Department of Chemistry New York, NY 10031 ------------------------------------------------------------------------ *From:* [email protected]
on behalf of Oliver Clarke *Sent:* Monday, February 8, 2016 4:28 AM *To:* [email protected] *Subject:* [phenixbb] Refine pixel size of map (for EM data)? Hello, I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement.
Although we try to calibrate this as best as we are able at the time of data collection, it is never perfect - for example, in one case I have dealt with, our nominal pixel size out of the scope is 1.19 Å, but the pixel size calibrated based on a crystal structure of a fragment of the protein is 1.25 Å. This is not a huge difference, but it is sufficient I think to have a substantial impact on refinement, particularly as regards clash assessment and H-bond/sec struc restraints.
In cases where one does not have a solved crystal structure to use for calibration, perhaps refining the pixel size in conjunction with the geometry might be of some use?
Cheers, Oli
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb Unsubscribe: [email protected]
Hi Pavel,
Thanks, it’s as I anticipated.
Best wishes,
Reza
Reza Khayat, PhD
Assistant Professor
Department of Chemistry
City College of New York
85 Saint Nicholas Terrace, CDI 2.318
New York, NY 10031
http://www.khayatlab.org/
212-650-6070
From: Pavel Afonine [mailto:[email protected]]
Sent: Monday, February 08, 2016 11:08 AM
To: Reza Khayat
Hi,
Is it possible to visualize the NCS axis identified with phenix.autosol? Thanks.
Best wishes,
Reza
Reza Khayat, PhD
Assistant Professor
City College of New York
Department of Chemistry
New York, NY 10031
________________________________
From: Pavel Afonine
Hi Reza,
It's a great idea to have a tool in Phenix to visualize NCS. We don't have one yet but I'll see what it would take to make one... We do have methods to identify symmetry axes from NCS operators that could be use in such a tool.
All the best,
Tom T
________________________________
From: [email protected]
I think the option to refine cell would be useful for x-ray structures as well. One of the checks in whatcheck is (or at least was) to suggest corrections to cell based on bond length deviations along the direction of each axis. Unfortunately it seems the ideal bond lengths in whatcheck were slightly different from those in CNS which we used for refinement, so after refining with the corrected cell and running whatcheck again, it would suggest another correction of about the same magnitude in the same direction. Cycling several times we ended up with quite different cell parameters with relatively little change in R (I didn't look at bond deviations, and this was a low-resolution, high R structure). Of course the camera length and xray wvelength should be known to high precision, in which case this would be just a fudge factor, but with only 3-6 parameters it shouldn't affect the refinement much. After all it is fairly standard during spot integration to refine camera length (at least for HKL users), and if that is in doubt then so are the cell parameters. Ed On 02/08/2016 04:28 AM, Oliver Clarke wrote:
Hello,
I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement.
Although we try to calibrate this as best as we are able at the time of data collection, it is never perfect - for example, in one case I have dealt with, our nominal pixel size out of the scope is 1.19 Å, but the pixel size calibrated based on a crystal structure of a fragment of the protein is 1.25 Å. This is not a huge difference, but it is sufficient I think to have a substantial impact on refinement, particularly as regards clash assessment and H-bond/sec struc restraints.
In cases where one does not have a solved crystal structure to use for calibration, perhaps refining the pixel size in conjunction with the geometry might be of some use?
Cheers, Oli
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb Unsubscribe: [email protected]
Hi Oliver,
I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement.
we are working on this. Once implemented it will be done always by default as extra step. When? Perhaps 1-2 months from now. Pavel
Wonderful, thanks Pavel. Oli
On Feb 8, 2016, at 4:02 PM, Pavel Afonine
wrote: Hi Oliver,
I wonder whether it would be possible to add an option for phenix.real_space_refine to allow refinement of the pixel size of the map (or the unit cell dimensions - just an overall size scale factor), and write out the altered map at the end of refinement.
we are working on this. Once implemented it will be done always by default as extra step. When? Perhaps 1-2 months from now.
Pavel
participants (5)
-
Edward A. Berry
-
Oliver Clarke
-
Pavel Afonine
-
Reza Khayat
-
Terwilliger, Thomas Charles