<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div><br></div><div>I've been pondering the McMaster correction recently.</div><div><br></div><div>My understanding is that it is a correction because while chi(k) is defined relative to the embedded-atom background mu_o(E), we almost always extract it from our data by normalizing by the edge step. Since mu_o(E) drops gradually above the edge, the normalization procedure results in oscillations that are too small well above edge, which the McMaster correction then compensates for. It's also my understanding that this correction is the same whether the data is measured in absorption or fluorescence, because in this context mu_o(E) refers only to absorption due to the edge of interest, which is a characteristic of the atom in its local environment and is thus independent of measurement mode.</div><div><br></div><div>So here's my question: why is existing software structured so that we have to put this factor in by hand? Feff, for instance, could simply define chi(k) consistently with the usual procedure, so that it was normalized by the edge step rather than mu_o(E). A card could be set to turn that off if a user desired. Alternatively, a correction could be done to the experimental data by Athena, or automatically within the fitting procedure by Ifeffit.</div><div><br></div><div>Of course, having more than one of those options could cause trouble, just as the ability to put sigma2 into a feff calculation <i>and</i> in to Ifeffit sometimes does now. But wouldn't it make sense to have it available (perhaps even the default) at one of those stages?</div><div><br></div><div>--Scott Calvin</div><div>Sarah Lawrence College</div></body></html>