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 later.) 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 fit.
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 restraints.
...
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.