Difference Map positive peaks in release dev-798
I was wondering if anything changed (weights or something) in the way the difference maps are calculated? I just ran refinement on a 1.3 structure and a hexacoordinated Mg2+ ion has significant positive density peak even at occupancy 1.0. I had not noticed that before. My ligand also does have positive peaks, but refine gives it a .91 occupancy. I wonder if I am missing some parameter cif file or some definition that would make the positive peaks decrease? Thank you -- Yuri Pompeu
Hi Yuri,
I was wondering if anything changed (weights or something) in the way the difference maps are calculated?
no, I did not change anything recently that would affect the mFo-DFc map.
I just ran refinement on a 1.3 structure and a hexacoordinated Mg2+ ion has significant positive density peak even at occupancy 1.0. I had not noticed that before.
When the change occurred (between which version numbers)? Does the peak disappear if you do the same calculation using an older version?
My ligand also does have positive peaks, but refine gives it a .91 occupancy. I wonder if I am missing some parameter cif file or some definition that would make the positive peaks decrease?
There is no general remedy - it's all case-dependent. Does its B-factor differ significantly from surrounding atoms? Pavel.
Hi Yuri,
I was wondering if anything changed (weights or something) in the way the difference maps are calculated? I just ran refinement on a 1.3 structure and a hexacoordinated Mg2+ ion has significant positive density peak even at occupancy 1.0. I had not noticed that before. My ligand also does have positive peaks, but refine gives it a .91 occupancy. I wonder if I am missing some parameter cif file or some definition that would make the positive peaks decrease?
thanks for sending the data! I did refinement the way that I believe is the most appropriate given the data and model quality: - the command I used: phenix.refine params --overwrite - the parameter file contains these lines: refinement { input { pdb { file_name = model.pdb } xray_data { file_name = data.mtz r_free_flags { file_name = data.mtz } } monomers { file_name = ligand.cif } } output { prefix = test } refine { adp { individual { isotropic = (element H or element D) anisotropic = not (element H or element D) } } } main { ordered_solvent = True number_of_macro_cycles = 10 } target_weights { optimize_wxc = True optimize_wxu = True } ordered_solvent { n_cycles = 2 new_solvent = isotropic *anisotropic } } Since you sent me a .sca file that did not contain the R-free flags (and NOT the actual MTZ file that you used to refine your structure), so I had to do one of the worst possible things: re-create Rfree flags from scratch (note: Rfree flags should be created once, before any refinement or model building is done, and never changed since that). To make the refinement results more or less meaningful, I had to do the usual things to remove bias from Rfree: reset ADPs to isotropic, remove water, shake coordinates and do as many refinement macro-cycles as necessary to achieve convergence (10 in this case, see above). Also, I add H atoms. This is what model.pdb is. After refinement I got good R-factors (given the resolution): r_work = 0.1158 r_free = 0.1268 (the starting model you sent me has: r_work = 0.1430 r_free = 0.1595. And now I'm looking at your MGs: - Fig 1: http://cci.lbl.gov/~afonine/tmp/tmp_09357452/p1.png My interpretation of this is that MG probably partially occupies two sites, so I would try replacing that water (that phenix.refine automatically placed) with another MG, and refine occupancies of both MG (independently or constraining them to the sum = 1). Alternatively, could it be that you simply have two partially occupied waters here? - Fig 2: http://cci.lbl.gov/~afonine/tmp/tmp_09357452/p2.png In this case one of the waters needs to be shifted towards green density, and you need to add another water to empty blob (I don't know why phenix.refine did not add it automatically - I will investigate once I get a chance). A slight negative peak at around MG center may indicate under-refinement of its ADP, the undefined charge (you probably need to define it in input PDB file), may be its partial occupancy, etc... Eliminating it would probably require a lot of experimenting with different possibilities. I will send you the PDB and MTZ files in a separate email (OFF-LIST). Pavel.
On 6/27/11 10:43 AM, Pavel Afonine wrote:
In this case one of the waters needs to be shifted towards green density, and you need to add another water to empty blob (I don't know why phenix.refine did not add it automatically - I will investigate once I get a chance).
Dear Pavel, This has been my experience with Na sites as well. Phenix.refine water-update would always move/delete my waters out of coordination spheres (so I would turn off solvent updates, and strictly restrain these waters). I always assumed that since Mg and Na coordinate water with very short distances (2-2.4 Angstroms) compared to water to N and O atoms, they were disliked by solvent updates. Since I have not looked at the code (and haven't used the recent versions for Mg/Na containing structures), I cannot confirm this, but does solvent-update assume waters should be within 2.3-3.5 A? If that is the case, that may kill some true water sites. Cheer, Engin -- Engin Özkan Post-doctoral Scholar Howard Hughes Medical Institute Dept of Molecular and Cellular Physiology 279 Campus Drive, Beckman Center B173 Stanford School of Medicine Stanford, CA 94305 ph: (650)-498-7111
Hi Engin,
This has been my experience with Na sites as well. Phenix.refine water-update would always move/delete my waters out of coordination spheres (so I would turn off solvent updates, and strictly restrain these waters). I always assumed that since Mg and Na coordinate water with very short distances (2-2.4 Angstroms) compared to water to N and O atoms, they were disliked by solvent updates. Since I have not looked at the code (and haven't used the recent versions for Mg/Na containing structures), I cannot confirm this, but does solvent-update assume waters should be within 2.3-3.5 A? If that is the case, that may kill some true water sites.
I have special handling of "water - other_isolated_non_water_atom" situations that in theory should allow shorter distances, but apparently this fails sometimes (not always though). I should review that code given that I have more practical examples now. Pavel.
participants (3)
-
Engin Özkan
-
Pavel Afonine
-
Yuri