[phenixbb] Fwd: [ccp4bb] Phenix; converting a map to structure factors
Mayer, Mark (NIH/NICHD) [E]
mayerm at mail.nih.gov
Sat Jul 11 12:07:40 PDT 2015
Hi Pavel and Sacha,
This is great - thanks for explaining why its probably not a good idea to do reciprocal space refinement using EM maps as a starting point for structure factor calculation.
My last gasp:what about case where you have a not perfect model built into EM map, real space refined locally, and then would like to do a global geometry optimization?
From: Pavel Afonine [pafonine at lbl.gov]
Sent: Saturday, July 11, 2015 2:51 PM
To: Mayer, Mark (NIH/NICHD) [E]; Terwilliger, Thomas Charles; PHENIX user mailing list
Subject: Re: Fwd: [phenixbb] [ccp4bb] Phenix; converting a map to structure factors
> Would reciprocal space refinement improve maps - or would all the improvement come from model bias? i.e. would maps look nicer, but with no new information content?
cryo-EM map is your data, similarly to Fobs in case of X-ray. We never
change Fobs during structure solution and refinement, likewise cryo-EM
map should not be changed.
What happens when you use reciprocal space refinement programs to refine
against "Fobs and phases" generated from cryo-EM map is that the program
will calculate 2mFo-DFc and mFo-DFc maps using model phases combined
with phases from the map. Obviously such calculated maps will be model
biased. I would say this is not desirable. (Oh and don't forget - you
need to use electron form-factors if you refine against the cryo-EM map
in reciprocal space!).
> I guess the difference from X-ray is that while each HKL has contributions from all atoms in the ASU, for an EM map converted to structure factors this is not true. Also, EM maps have substantial local resolution differences, and I don't understand how this would impact SF calculation.
This brings another point.. If you calculate a box of reflections from
the map, then conversion Map <> Structure Factors is lossless and
biunique. The problem is that when we convert map to structure factors
of certain resolution we essentially carve a sphere with reflections out
of the box; this is because reciprocal-space refinement programs are
designed to work with sphere of reflections not the box. This
manipulation result in loss of information: Map1 -> sphere of
reflections -> Map2 with Map1 being not the same as Map2.
> I know that some in the EM community, who are not used to hands on (i.e. coot/O etc) real space refinement, are disappointed by the small radius of convergence for automatic real space refinement that is not guided by a human being sitting at a graphics terminal.
One of the great things about real-space refinement is that it can be
done locally. In particular this means optimization methods with larger
convergence radius can be used: for example, one can systematically
sample chi angles of a residue side chain to find the best fitting
rotamer. Another example: data / restraints target optimal weights can
be obtain in a matter of seconds, while obtaining optimal weight in
reciprocal space refinement may be a very time consuming task. I can
bring many more examples like these.
In real-space refinement one can use refinement target functions that
are much faster to compute (such as sum of map values at atom centers)
compared to reciprocal space LS or ML functions. This allows programs to
try more things during refinement and eventually arrive at a better result.
We use all this in phenix.real_space_refine.
Of course a human being moving atoms by hand at a graphics is the
optimization tool with perhaps largest convergence radius. I would say
in terms of convergence radius real-space refinement sits in between
reciprocal-space refinement and human being.
More information about the phenixbb