[phenixbb] Appropriate model_vs_data usage over part of a structure
andy.watkins2 at gmail.com
Wed May 25 17:38:18 PDT 2016
To large extent this may have been resolved by prior replies to the list,
but I figure I may as well clarify for your sake if no one else's!
> Suppose I have a model of one chain of a complex and an .mtz describing
> the entire complex.
> I'm struggling making sense of this statement.. MTZ file is just a file
> format to records some data with labels associated with it in a binary form
> to make it easier for machines to handle it. So what precisely you mean by
> ".mtz describing the entire complex"?
Precisely, I mean an .mtz that contains experimental structure factors.
(The use of "describing the entire complex" may be redundant, and my use of
that phrase may rest on a misunderstanding that I'll be able to refer to
For obvious reasons,
> phenix.model_vs_data chain_A.pdb whole_complex.mtz
> phenix.model_vs_data chain_A_refined.pdb whole_complex.mtz
> are undesirable: they evaluate the model of a single chain against the
> whole complex's data, and there's obviously a lot of unsatisfied electron
> density. So, while this command *works*, it reports an unrepresentative
> Could you please define "unrepresentative fit" in this context?
Well, suppose that the structure factors in whole_complex.mtz reflect a
tetramer. I would imagine that *part* of the reason that the resulting
Rwork and Rfree are poor is because the model contains only one chain; with
all four chains, the fit would be considerably better.
> (In theory, one solution to my problem would be to re-combine each chain's
> refined version, then run model_vs_data on the recombined, refined complex.
> I'm interested nonetheless in how it would work on the chains separately.
> I guess Fobs would not like this as they include contributions from all
> atoms, as far as I remember from the theory.
Yeah, I think that was the key conceptual issue I was having. Rationally, I
had *no* idea how there could possibly be a subset of Fobs that could be
associated with a subset of the atoms. But phenix.maps, being handed a PDB
and a MTZ file of structure factors, hands you--in addition to a .ccp4
map--the rather generically named map_coeffs MTZ file. Looking more into
the documentation for maps.params, it's probably just separate data:
> mFo-DFc and anomalous difference maps will be output in MTZ format
So it's possible that this entire line of not-quite-logically-consistent
questioning arose from an incorrect assumption about the meaning of the
output map_coeffs MTZ.
> Now, during the refinement procedure, we of course generate .ccp4 density
> maps for the individual chain models:
> phenix.maps chain_A.pdb whole_complex.mtz
> Well, this is what it seems *you* do as part of *your* protocol, but this
> is *not* what typical work-flow includes as phenix.refine always reports
> maps upon completion of refinement; so running phenix.maps seems to be an
> unnecessary step in this scenario.
Well, I intentionally didn't mention a particular refinement protocol: I'm
not using phenix.refine, but--in what I'm testing at the moment--an
external real-space refinement that uses the .ccp4 map to provide
> Hm.. I afraid I'm lost now: model vs data tool is not supposed to accept
> inputs other than original data, Iobs or Fobs, and model files.
Right: this was due to the aforementioned conceptual error re: what the
"map_coeffs" output really represented.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the phenixbb