[phenixbb] occupancy

Maia Cherney chern at ualberta.ca
Sat Aug 22 14:03:03 PDT 2009


Hi Pavel,
is it possible to refine individual occupancies of atoms in alternative 
conformations?

Maia

Pavel Afonine wrote:
> Hi Bill,
>
>> About a year ago I refined a 1.6 Å RNA structure with phenix.refine  
>> 1.3b-rc6 and then got distracted.  
>
> I'm not sure I got the message... Was anything wrong about the maps? 
> If so, did you let us know (sorry, I don't remember).
>
>> I picked it up today and  
>> essentially repeated the last round of refinement with 1.4-57 (and  
>> also 1.4-159).  The maps are subtly different, but consistently  
>> slightly worse with 1.4.
>>   
>
> Which maps we are looking at? I presume 2mFo-DFc (not 2Fo-Fc): 
> regular? filled? kicked? (see copies of previous emails to the BB 
> explaining these maps at the bottom of this email).
>
>> Here are two examples:  http://sage.ucsc.edu/~wgscott/mystuff/old_vs_new.pdf
>>   
>
> May be because I'm looking at static pictures, but apart from the 
> water #5, the differences seem subtle indeed.
>
>> In the second example, this would lead to deletion of one of the  
>> octahedrally coordinated waters on a known Mg++ ion.
>>   
>
> Do you mean you would delete this water manually because you don't see 
> it in the map, or phenix.refine deletes it?
>
>> Has the weighting for the bulk solvent mask or something like that  
>> been increased?
>>   
>
> I can name two major things:
>
> - phenix.refine outputs "filled" maps by default since December 2008 
> (or may be January 2009?);
> - a few weeks (a month?) ago we switched to using a faster and more 
> memory efficient bulk solvent mask calculation code. Plus this new 
> code has a minor bug fixed that existed many years in the old one.
>
> If you send me 1.6A resolution data and your best model, I will be 
> happy to have a closer look.
>
> Pavel.
>
>
> PS> Copies of replies to BB about kicked and filled maps:
>
> Kick maps:
> """
> there will be a paper about it in next coming Acta D. This method was 
> introduced about 10-15 years ago by Dusan Turk in his program MAIN is 
> used since that. Here is the copy-paste from the manuscript:
>
> "(...) An average kick map (AK map) is computed as following (Gunčar 
> et al., 2000; Turk, 2007; Pražnikar et al., 2009): a large ensemble of 
> structures (several hundreds) is created where the coordinates of each 
> structure from the ensemble are all randomly shaken. The shake amount 
> (rmsd distortion introduced to coordinates) varies from 0 to 1.0 Å. 
> Then for each structure a map is computed ((mFobs-DFmodel)exp(iαmodel) 
> or (2mFobs-DFmodel)exp(iαmodel) or any other map, for example a 
> ligand-omit map). Finally, all maps are averaged out to produce one 
> averaged kick map. An AK map is expected to have less or no bias, less 
> noise, enhance existing signal and potentially can clear up some 
> initially bad densities. (...)"
> """.
>
> Filled maps:
> """
> Hi Everyone,
>
> I think it's time to review this subject since it is one of the most 
> frequently asked questions. Ironically, I think this is because we 
> tried to make it as clear as possible -:)
>
> So, what kind of maps phenix.refine outputs by default? phenix.refine 
> outputs two types of maximum-likelihood weighted maps (or, in other 
> words, sigmaa-weighted maps): 2mFo-DFc and mFo-DFc.
>
> Now, as many of you noticed, the MTZ file with map coefficients 
> "_map_coeffs.mtz" contains in fact four maps: 2mFo-DFc and mFo-DFc, 
> and "filled" 2mFo-DFc and mFo-DFc (in fact fo-fc maps should be nearly 
> identical; actually I have to fix it and not write identical fo-fc 
> maps). The first two maps are computed using original Fobs (Fo), and 
> the last two maps are computed using "filled Fobs", that is the 
> original Fobs where missing reflections are "filled" with DFc. It is 
> well known (I can spell a long list or references) that the data 
> incompleteness affects the map quality, and sometimes, certain types 
> of data incompleteness can *severely* distort maps.
>
> A possible solution (in order to reduce this negative effect) is to 
> "model" missing Fobs somehow. One possibility is just to put in DFc in 
> place where Fobs is missing, or as suggested by the classics, one can 
> use <Fobs> taken in a resolution bin around a missing reflection. I 
> even tried to use the random numbers and it was also better than doing 
> nothing. Obviously, there is a nearly invisible line between the 
> benefits of "filling in" missing Fobs and introducing bias. Where this 
> line goes - is the subject of a research that to my knowledge is not 
> done yet.
>
> Anyway, this is why phenix.refine writes out "regular" and "filled" 
> maps: one is to give you unbiased but eventually lower quality map, 
> and the other one is to give you a better-looking map with a risk of 
> being biased. This way users have more options in exploring their maps 
> (and less reasons for saying that Refmac produces better-appearing 
> maps than phenix.refine -- see below).
>
> I have to mention that to my knowledge REFMAC always writes "filled" 
> maps (those with missing Fobs substituted by DFc):
>
> - it is mentioned in Maria Turkenburg's thesis:
> http://www.ysbl.york.ac.uk/~mgwt/thesis-tth/chapter2.html#tth_sEc2.6.5
>
> - and in Refmac docs:
> http://www.ccp4.ac.uk/html/refmac5/keywords/xray-general.html
>
> "Missing Data: For those reflections where the FP are missing, mFo is 
> set equal to dFc. (...)".
>
> Correct me if I'm missing something.
>
> Please let me know if I wasn't clear in my attempt to explain this. I 
> will update the phenix.refine documentation accordingly.
>
> Pavel.
> """.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://www.phenix-online.org/mailman/listinfo/phenixbb
>   




More information about the phenixbb mailing list