<div dir="ltr"><div class="gmail_extra">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!</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div>Suppose I have a model of one chain of a complex and an
.mtz describing the entire complex.</div></div></blockquote></span>
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"?</div></blockquote><div><br></div><div>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.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>For obvious reasons,<br></div></div></blockquote></span><span class=""><blockquote type="cite"><div dir="ltr">
<div><br>
</div>
<div>phenix.model_vs_data chain_A.pdb whole_complex.mtz</div>
<div>
<div>phenix.model_vs_data chain_A_refined.pdb
whole_complex.mtz</div>
</div>
<div><br>
</div>
<div>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 <i>works</i>,
it reports an unrepresentative fit. </div>
</div>
</blockquote>
<br></span>
Could you please define "unrepresentative fit" in this context?</div></blockquote><div><br></div><div>Well, suppose that the structure factors in whole_complex.mtz reflect a tetramer. I would imagine that <i>part</i> 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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>(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.</div></div></blockquote></span>
I guess Fobs would not like this as they include contributions from
all atoms, as far as I remember from the theory.</div></blockquote><div><br></div><div>Yeah, I think that was the key conceptual issue I was having. Rationally, I had <i>no</i> 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:</div><div><br></div><div>> mFo-DFc and anomalous difference maps will be output in MTZ format</div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>Now, during the refinement procedure, we of course generate
.ccp4 density maps for the individual chain models:</div>
<div><br>
</div>
<div>phenix.maps chain_A.pdb whole_complex.mtz</div></div></blockquote></span>
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.</div></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div>...</div>
</div>
</blockquote></span>
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.<br></div></blockquote><div><br></div><div>Right: this was due to the aforementioned conceptual error re: what the "map_coeffs" output really represented.</div></div></div></div>