Dear Matt, thank you for your reply. As I wrote, I did try rebin_xafs function, but it did not seem to improve the noise. It is not completely clear to me why, that was one of the questions. Regarding the suggestions, I found that rebinning
Dear Matt,
thank you for your reply.
As I wrote, I did try rebin_xafs function, but it did not seem to
improve the noise. It is not completely clear to me why, that was one of
the questions.
Regarding the suggestions, I found that rebinning of chi (chi(E) or
chi(k)) yields much lower noise than rebinning of mu(E). With this
approach the resulting chi(k) is noise-wise very similar to Athena.
My findings were summarized in a figure. I am not sure whether you got
it through the mailing list, so just in case I attach it here and add
your e-mail in cc.
All the best,
Kirill
On 23/11/2024 04:09, Matthew Newville wrote:
> Hi Kiril,
>
> Yes, this is a common issue, especially for data from some beamlines
> that do a continuous or fly-scan data collection (I'm 100% in favor of
> this). There is a function for that. See |larch.xafs.rebin_xafs:|
> https://urldefense.us/v3/__https://github.com/xraypy/xraylarch/blob/master/larch/xafs/__;!!G_uCfscf7eWS!Z6DCYyVN0uG5s3uCOcy03cAkLD6A6Fo0sZSDRwq_5OPp2mzDTlFp6NlwnNAIc2HqnSeCAjPQsPNkyAUmNHgINlwRXdqQSCWJkg$
> rebin_xafs.py#L55 <https://urldefense.us/v3/__https://github.com/xraypy/xraylarch/blob/master/__;!!G_uCfscf7eWS!Z6DCYyVN0uG5s3uCOcy03cAkLD6A6Fo0sZSDRwq_5OPp2mzDTlFp6NlwnNAIc2HqnSeCAjPQsPNkyAUmNHgINlwRXdoZkMNpOQ$
> larch/xafs/rebin_xafs.py#L55>
>
> For the data re-binning to each point in the output, this can do either
> a boxcar average (which might reduce resolution) or use a centroid value
> (which might do less resolution reduction). Either of these should be
> better (in the sense of "use more of the input data") than a simple
> interpolation.
>
>
> The Larix GUI will prompt users to use this to re-bin XAFS data that
> looks like it has too many points (more than 1200 points) or too fine an
> energy spacing (< 0.75eV) in the high-energy portion of the spectra.
> So, I think your data would be noticed as "needs rebinning".
>
> --Matt
>
> PS: suggestions for better approaches welcome!
>
>
> ------------------------------------------------------------------------
> *From:* Kirill LOMACHENKO via Ifeffit <ifeffit@millenia.cars.aps.anl.gov>
> *Sent:* Friday, November 22, 2024 12:10 PM
> *To:* ifeffit@millenia.cars.aps.anl.gov <ifeffit@millenia.cars.aps.anl.gov>
> *Cc:* Kirill LOMACHENKO <lomachenko@esrf.fr>
> *Subject:* [Ifeffit] Larch: noise in chi(k) - another try
> This Message Is From an External Sender
> This message came from outside your organization.
>
> Dear Matt and dear all, seems that my original message has been cut by
> the mailing server. I try again, this time without attachments. I have
> encountered an issue processing oversampled EXAFS data with Larch. In my
> example the energy step is 0.33 eV in all parts of the scan, including
> the EXAFS. When I use the default procedure in Larch (pre_edge and then
> autobk), I get the noise level in chi(k) that is higher than I would
> expect. Strangely, rebinning of mu(E) using rebin_xafs function does
> not help, and even increases the noise. The lowest level of noise can be
> obtained when rebinning the data in k (starting from the "raw"
> oversampled chi(E) provided by Larch). In this last case, the result is
> noise-wise very similar to Athena's default. I think that the high level
> of noise after the default Larch processing can be due to the fact that
> Larch does not seem to do averaging when converting the data from E to
> k. Instead, it does interpolation with UnivariateSpline which by design
> is not supposed to decrease the noise when applied to oversampled data.
> Is this correct? Would it be worth changing? The reason why the
> rebinning in E does not decrease the noise is not clear to me. Do you
> have any idea? Has anyone run into similar issues? Any comments and
> suggestions are welcome. Thank you Best regards, Kirill
>