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
>