[phenixbb] geometry_minimization makes molprobity score worse

[Pavel Afonine]

Hi James,

>>> Greetings all, and I hope this little observation helps improve 
>>> things somehow.
>>>
>>> I did not expect this result, but there it is. My MolProbity score 
>>> goes from 0.7 to 1.9 after a run of phenix.geometry_minimization
>>>
>>> I started with an AMBER-minimized model (based on 1aho), and that 
>>> got me my best MolProbity score so far (0.7). But, even with 
>>> hydrogens and waters removed the geometry_minimization run increases 
>>> the clashscore from 0 to 3.1 and Ramachandran favored drops from 98% 
>>> to 88% with one residue reaching the outlier level.
>>
>> It is not a secret that 'standard geometry restraints' used in Phenix 
>> and alike (read Refmac, etc) are very simplistic. They are not aware 
>> of main chain preferential conformations (Ramachandran plot), 
>> favorable side chain rotamer conformations. They don't even have any 
>> electrostatic/attraction terms -- only anti-bumping repulsion! 
>> Standard geometry restraints won't like any NCI (non-covalent 
>> interaction) and likely will make interacting atoms break apart 
>> rather than stay close together interacting.
>
> Yes, there's the rub: I'm not seeing "interacting atoms break apart", 
> but rather they are being smashed together.  Torsion angles are also 
> being twisted out of allowed regions of the Ramachandran plot.

I think this can go both ways depending on local arrangement. For 
example, if atoms interact via NCI but something else pushes them apart, 
they will split. But if nothing pushes them they may just stay together.

Also, if H are not present atoms can come close enough to each-other 
creating a clash from MolProbity viewpoint (because it adds H for clash 
evaluations).

>> With this in mind any high quality (high-resolution) atomic model or 
>> the one optimized using sufficiently high-level QM is going to have a 
>> more realistic geometry than the result of geometry regularization 
>> against very simplistic restraints target. An example:
>>
>> https://journals.iucr.org/d/issues/2020/12/00/lp5048/lp5048.pdf
>>
>> and previous papers on the topic.
>
> I agree, but what doesn't make sense to me is how the "simplistic 
> restraints" of phenix.geometry_minimization would be so inconsistent 
> with the "simplistic restraints" in phenix.molprobity ?

MolProbity way to quantify clashes and repulsion terms in standard 
restraints are different. If everything else is favorable they may 
match, but otherwise they don't have to (by the way they are defined and 
calculated).

> What I am doing here is starting with an energy-minimized model of a 
> 1.0 A structure (1aho). It's not a fancy QM, just the ff14SB potential 
> in AMBER.  I get my best molprobity scores this way, but I need an 
> x-ray refinement program like phenix.refine to compare these models 
> with reality.  It troubles me that the "geometry" in the x-ray 
> refinement program all by itself messes up my molprobity score.

If in this case AMBER force-field does a better job, then you can run 
X-ray refinement using AMBER based restraints. Nigel can help with that 
in case it does not work right off the box.

>>> Just for comparison, with refmac5 in "refi type ideal" mode I see 
>>> the MolProbity rise to 1.13, but Clashscore remains zero, some Ramas 
>>> go from favored to allowed, but none rise to the level of outliers.
>>
>> I believe this is because of the nature of minimizer used. Refmac 
>> uses 2nd derivative based one, which in a nutshell means it can move 
>> the model much less (just a bit in vicinity of a local minimum) than 
>> any program that uses gradients only (like Phenix).
> good point.
>
> So, what should I do to stabilize phenix.geometry_minimization? Crank 
> up the non-bonded weight?  Restrain to starting coordinates?

Restraining to starting coordinates is a fine option (there is an option 
to do it).

Cranking up nonbonded weight might have side effects:

http://phenix-online.org/presentations/nb_weight.pdf

>>> Files and logs here:
>>> https://bl831.als.lbl.gov/~jamesh/bugreports/phenixmin_070721.tgz
>>>
>>> I suspect this might have something to do with library values for 
>>> main-chain bonds and angles?  They do seem to vary between programs. 
>>> Phenix having the shortest CA-CA distance by up to 0.08 A. After 
>>> running thorough minimization on a poly-A peptide I get:
>>> bond   amber   refmac  phenix  shelxl Stryer
>>>  C-N   1.330   1.339   1.331   1.325     1.32
>>>  N-CA  1.462   1.482   1.455   1.454     1.47
>>> CA-C   1.542   1.534   1.521   1.546     1.53
>>> CA-CA  3.862   3.874 *3.794* 3.854
>>>
>>> So, which one is "right" ?
>>
>> I'd say they are all the same, within their 'sigmas' which are from 
>> memory about 0.02A:
> I note that 3.874 - 3.794 = 0.08 > 0.02

Right, but I was talking about covalent bonds as defined in Monomer 
Library or GeoStd, and for those it looks like they stay within their 
'sigmas'. There is no explicit restraints on CA-CA distances.

> This brings me to my pet theory.  I think what is going on is small 
> errors like this build up a considerable amount of tension in the long 
> main chain. For this 64-mer, the contour length of the main chain 
> after idealization is ~5 A shorter after phenix.geometry_minimization 
> than it is after shelxl or amber. That 5 A has to come from 
> somewhere.  Without stretching bonds or bending angles the only thing 
> left to do is twisting torsions. A kind of "whirlygig" effect.
>
> The question is: is the phenix CA-CA distance too short?  Or is the 
> amber CA-CA distance too long?

I don't know the answer, but try this (m.pdb is a nearly perfect 
alpha-helix from 1US0):

phenix.dynamics m.pdb number_of_steps=5000

and compare the result (eg., in PyMol) with the staring model.

Pavel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20210708/cf8a671d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m.pdb
Type: chemical/x-pdb
Size: 7661 bytes
Desc: not available
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20210708/cf8a671d/attachment.bin>