<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Dear Matt,</p>
    <p>attached you will find a recent data file which is showing the
      problem and two plots of the data (A RuO2 powder sample on Scotch
      tape) in the file. One plot is showing the Chi(k) with and without
      rebinning the other one just mue(E) with and without rebinning. It
      seems it is no good to convert previously rebinned data to
      k-space. the rebinned mue(E) looks okay and the original data
      converted to k-space does also look ok. <br>
    </p>
    <p>I produced the plots with Athena 0.9.24 (I know not the most
      recent version) under WIN 7 with IFEFFIT as backend. I wasn't able
      yet to reproduce this on my office desktop using LINUX and the
      most recent dathena and Larch, because of some trouble with
      reading the data file... No idea yet, might be worse another
      thread or might be something stupid on my site. <br>
    </p>
    <p>Cheers,</p>
    <p>Edmund<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 27.06.2018 20:31, Matt Newville
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+7ESbq--_=qjXALgfZ4Bhg4xcwGJDbby5sSshEwMVB=v_bptA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">HI Ilya,
          Edmund, Carlo, </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">Ilya and/or
          Carlo: can you post some example unbinned data?  As it turns
          out, I am adding a rebinning feature in the Larch XAS Viewer
          GUI that should be ready for a ready-to-try release very soon
          (for IIT XAFS School and XAFS2018).   <br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">This seems like
          a good chance to test these procedures out.<br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">My approach for
          this is to this is to make a "normal XAFS energy grid" of ~5
          eV steps, 0.25 eV steps, 0.05 Ang^-1 steps that the downstream
          processing needs, and then do one of two strategies -- maybe
          there should be more?:</div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"> a) do a
          straight interpolation onto this array -- that is probably the
          "noisy" result.  <br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"> b) assign each
          energy point in the original data to one of these energy bins,
          and take the average of all the points in each bin.  <br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">I'd also like
          to try using energy-weighted mean (centroid).  Probably most
          of the data is so finely spaced that this won't make much
          difference, but it might be a good option.   It might be able
          to help compensate for energy jitter, assuming that the
          recorded energy (probably from an encoder) is more accurate
          than the requested energy.<br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">It's also
          interesting to think about doing a Savitzky-Golay smoothing,
          though that might require knowing if the data points are
          actually uniform in mono angle or mono energy.  It also makes
          it easy to over-do the smoothing, and so a little trickier to
          prevent bad results.<br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">Do you (or
          anyone else) have any suggestions for how to best re-bin this
          kind of data?</div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif">--Matt</div>
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Wed, Jun 27, 2018 at 10:15 AM Carlo Segre
            <<a href="mailto:segre@iit.edu" target="_blank"
              moz-do-not-send="true">segre@iit.edu</a>> wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            Yes, we measure fast and have taken as many as 20000
            points.   The problem <br>
            is not in the shifts that you mention.  This is normal and
            expected.  the <br>
            problem is specificallly in the rebinning algorithm in
            Demeter.  It seems <br>
            to be different than the one in the old Horae package.  I
            have done a test <br>
            of this and I attache a coule of figures that show the
            difference.<br>
            <br>
            I have used 10 continuous scans for this test.  The data
            were taken at the <br>
            MRCAT beamline, Sector 10 at the APS.  The data are for the
            Fe K-edge and <br>
            there are about 3400 points per scan with a point density of
            about 0.35 <br>
            eV/step.  I used both versions of Athena and performed the
            following steps <br>
            to give the data groups shown in the plots<br>
            <br>
            new_athena.png<br>
              Fe_new_rebin_merge - (blue) all 10 scans rebinned at input
            and then<br>
                                   merged<br>
              Fe_new_merge       - (red) all 10 scans merged only<br>
              Fe_new_merge_rebin - (green) all 10 scans merged then
            rebinned<br>
            <br>
            old_athena.png<br>
              Fe_old_rebin_merge - (blue) all 10 scans rebinned at input
            and then<br>
                                   merged<br>
              Fe_old_merge       - (red) all 10 scans merged only<br>
              Fe_old_merge_rebin - (green) all 10 scans merged then
            rebinned<br>
            <br>
            comp_athena.png<br>
              Fe_old_rebin_merge - (blue)<br>
              Fe_new_rebin_merge - (red)<br>
            <br>
            It is clear that the new Athena (Demeter) is not rebinning
            the same way as <br>
            the old one (Horae).  The contrast is particularly evident
            with the last <br>
            plot. The new rebinning algorithm is introducing more
            noise.  For the <br>
            moment, I recommend only merging and perhaps smoothing if
            you can tolerate <br>
            a bit of amplitude reduction.<br>
            <br>
            I have been thinking that it might even be better to have
            the data <br>
            acquisition software do the rebinning on the fly so the data
            does not have <br>
            to be manipulated in Athena.  I am not sure if this is a
            good idea yet but <br>
            I think it would help my users.<br>
            <br>
            Carlo<br>
            <br>
            <br>
            On Wed, 27 Jun 2018, Edmund Welter wrote:<br>
            <br>
            > Dear Carlo,<br>
            ><br>
            > do you also measure as fast as possible in the sense
            that for two consecutive <br>
            > scans the points on the energy axis are not at the same
            positions? This is <br>
            > what happens at my beamline. The differences are
            typically very small but <br>
            > there are differences and one should not just add all
            the first points and <br>
            > all the second points and so on because they are not
            necessarily exactly at <br>
            > the same energy. Sometimes the beamline computer is
            doing something else in <br>
            > parallel (whatever that might be) and the distance
            between points A and B is <br>
            > significantly larger than the distance between B and C.<br>
            ><br>
            > So, the problem is, at which point does it make sense
            to merge several <br>
            > spectra of the same sample? I presume that Athena is
            taking care of this when <br>
            > I use it to merge spectra, but it can only do so by
            interpolating the points <br>
            > in the spectrum onto a common grid before summing up
            the spectra.<br>
            ><br>
            > The best solution might be to rebin/interpolate the
            spectra onto a fixed grid <br>
            > before they are imported into Athena (or any other
            program), depends on what <br>
            > Athena is exactly doing when it is rebinning data.<br>
            ><br>
            > Another aspect is that Athena is not very happy about
            8600 points/spectrum <br>
            > anyway, at least as long as it using Ifeffit.<br>
            ><br>
            > Cheers,<br>
            ><br>
            > Edmund<br>
            ><br>
            ><br>
            ><br>
            > On 27.06.2018 15:14, Carlo Segre wrote:<br>
            >> <br>
            >> <br>
            >> Hi Ilya:<br>
            >> <br>
            >> We always take data in this mode at APS Sector 10
            and I have also find that <br>
            >> the rebinning function is not working
            satisfactorily at this time.  I find <br>
            >> that for the current version of the software it is
            better to merge your <br>
            >> data and let IFEFFIT interpolate to the dk=0.05
            grid that it uses.<br>
            >> <br>
            >> Carlo<br>
            >> <br>
            >> <br>
            >> On Wed, 27 Jun 2018, Ilya Sinev wrote:<br>
            >> <br>
            >>> Hi all,<br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> I have a question regarding the chi(k) function
            isolation and rebinning<br>
            >>> processes. I have some data recorded in ?quasi
            channel-cut? modus, i.e. <br>
            >>> with<br>
            >>> the mono constantly moving and the data points
            collected with the highest<br>
            >>> possible rate. With 180 sec measurement in
            yields to a spectrum of ca. <br>
            >>> 8600<br>
            >>> point, which obviously needs to be rebinned.
            The rebinned data, however,<br>
            >>> does not look good in k-space even if multiple
            data are merged. Moreover, <br>
            >>> I<br>
            >>> have an impression that the raw spectrum in
            k-space does not have those<br>
            >>> 8000+ points anymore but significantly less. Is
            there any reduction of the<br>
            >>> data points number that is not seen (e.g. as a
            preparation step for FT)?<br>
            >>> Since the unbinned data has higher quality,
            does it then make more sense <br>
            >>> to<br>
            >>> keep using it for EXAFS analysis?<br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> Thank you<br>
            >>> <br>
            >>> Ilya Sinev<br>
            >>> <br>
            >>> <br>
            >>> <br>
            >>> <br>
            >> <br>
            ><br>
            > _______________________________________________<br>
            > Ifeffit mailing list<br>
            > <a href="mailto:Ifeffit@millenia.cars.aps.anl.gov"
              target="_blank" moz-do-not-send="true">Ifeffit@millenia.cars.aps.anl.gov</a><br>
            > <a
              href="http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit</a><br>
            > Unsubscribe: <a
              href="http://millenia.cars.aps.anl.gov/mailman/options/ifeffit"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://millenia.cars.aps.anl.gov/mailman/options/ifeffit</a><br>
            ><br>
            <br>
            -- <br>
            Carlo U. Segre -- Duchossois Leadership Professor of Physics<br>
            Interim Chair, Department of Chemistry<br>
            Director, Center for Synchrotron Radiation Research and
            Instrumentation<br>
            Illinois Institute of Technology<br>
            Voice: 312.567.3498            Fax: 312.567.3494<br>
            <a href="mailto:segre@iit.edu" target="_blank"
              moz-do-not-send="true">segre@iit.edu</a>   <a
              href="http://phys.iit.edu/%7Esegre" rel="noreferrer"
              target="_blank" moz-do-not-send="true">http://phys.iit.edu/~segre</a> 
             <a href="mailto:segre@debian.org" target="_blank"
              moz-do-not-send="true">segre@debian.org</a>_______________________________________________<br>
            Ifeffit mailing list<br>
            <a href="mailto:Ifeffit@millenia.cars.aps.anl.gov"
              target="_blank" moz-do-not-send="true">Ifeffit@millenia.cars.aps.anl.gov</a><br>
            <a
              href="http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit</a><br>
            Unsubscribe: <a
              href="http://millenia.cars.aps.anl.gov/mailman/options/ifeffit"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://millenia.cars.aps.anl.gov/mailman/options/ifeffit</a><br>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr" class="m_-2371958114737165186gmail_signature"
          data-smartmail="gmail_signature">--Matt Newville <newville
          at <a href="http://cars.uchicago.edu" target="_blank"
            moz-do-not-send="true">cars.uchicago.edu</a>>
          630-252-0431<br>
        </div>
      </div>
      <!--'"--><br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Ifeffit mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ifeffit@millenia.cars.aps.anl.gov">Ifeffit@millenia.cars.aps.anl.gov</a>
<a class="moz-txt-link-freetext" href="http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit">http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="http://millenia.cars.aps.anl.gov/mailman/options/ifeffit">http://millenia.cars.aps.anl.gov/mailman/options/ifeffit</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>