Hi Bruce,
Now this is clear.
In my case the correction I have to perform requires these measured/evaluated parameters: chi, mu (not sure if it's better to work with normmu here) and the background function. 
Is it physically meaningless to have the mu(k) and bkg(k) data? If that is not the case I would like to have these two columns exported in the ascii chi(k) file. 
So then I can perform the correction and re-import the new corrected chi(k) and make comparison with the uncorrected.

Kind regards,
Matteo

2016-04-01 15:06 GMT+02:00 <ifeffit-request@millenia.cars.aps.anl.gov>:
Send Ifeffit mailing list submissions to
        ifeffit@millenia.cars.aps.anl.gov

To subscribe or unsubscribe via the World Wide Web, visit
        http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
or, via email, send a message with subject or body 'help' to
        ifeffit-request@millenia.cars.aps.anl.gov

You can reach the person managing the list at
        ifeffit-owner@millenia.cars.aps.anl.gov

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ifeffit digest..."


Today's Topics:

   1. Chi(E) data export and import (Matteo Busi)
   2. Re: Chi(E) data export and import (Bruce Ravel)
   3. Re: Question about Io during data collection (Luxton, Todd)


----------------------------------------------------------------------

Message: 1
Date: Fri, 1 Apr 2016 13:58:23 +0200
From: Matteo Busi <basebush@gmail.com>
To: ifeffit@millenia.cars.aps.anl.gov
Subject: [Ifeffit] Chi(E) data export and import
Message-ID:
        <CAOyEiGhFhPbQ5Xn1is+R4MPVDQ4mxS4wXCcWM-j2qBcO5117-g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Bruce,
this message il linked to the previous solutions you find for me.

For the reference, I asked to have a column of the chi(E) in the exported
mu(E) data.
This has worked correctly so far.

Now for my master thesis, I'm performing a correction to chi(E) in the E
space regarding to some geometrical properties of the sample.
I have also tried to re-import the corrected data as a chi(k), having
reproduced the right k grid column, but it looks totally wrong.
The thing I'm not sure about is if the chi(E) needs to be fourier
trasnformed into chi(k) or not.
That's because I would have liked to make comparison in the Athena software
between the two chis, but if that's not possible I will keep it to the
external software (mathematic) with which the correction is performed.
Or if you can share me the fourier transform routine performed I can
include it to my correction script.

Hope the message is clear,
Kind Regards,

Matteo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20160401/0dc1c9f1/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 1 Apr 2016 08:25:07 -0400
From: Bruce Ravel <bravel@bnl.gov>
To: XAFS Analysis using Ifeffit <ifeffit@millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] Chi(E) data export and import
Message-ID: <56FE68A3.5020008@bnl.gov>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 04/01/2016 07:58 AM, Matteo Busi wrote:
> Now for my master thesis, I'm performing a correction to chi(E) in the E
> space regarding to some geometrical properties of the sample.
> I have also tried to re-import the corrected data as a chi(k), having
> reproduced the right k grid column, but it looks totally wrong.
> The thing I'm not sure about is if the chi(E) needs to be fourier
> trasnformed into chi(k) or not.
> That's because I would have liked to make comparison in the Athena
> software between the two chis, but if that's not possible I will keep it
> to the external software (mathematic) with which the correction is
> performed.
> Or if you can share me the fourier transform routine performed I can
> include it to my correction script.

You seem to be thinking about this wrongly.  The chi(E) that gets
written to the mu(E) ascii file using the thing we discussed last time is

   mu(E) - bkg(E)

That's it.  The difference between the chi(E) in the mu(E) file and the
normal chi(k) is that (mu(E)-bkg(E)) is interpolated onto a uniform
k-grid.  There are at least two reasons for doing that, (1) every data
sets then ends up on the same k-grid, which is a convenience, and (2) a
uniform k-grid allows use of a /fast/ Fourier transform.

If you want to overplot chi(E) and chi(k), you also have to do the
coordinate transform between energy and wave-number, which depends upon
the value of E0.

You have never clearly explained what you are up to and why
interpolating the normal chi(k) back onto the energy grid was
inadequate, so I don't know what else I can say that would be helpful.

B

--
  Bruce Ravel  ------------------------------------ bravel@bnl.gov

  National Institute of Standards and Technology
  Synchrotron Science Group at NSLS-II
  Building 535A
  Upton NY, 11973

  Homepage:    http://bruceravel.github.io/home/
  Software:    https://github.com/bruceravel
  Demeter:     http://bruceravel.github.io/demeter/


------------------------------

Message: 3
Date: Fri, 1 Apr 2016 13:05:57 +0000
From: "Luxton, Todd" <Luxton.Todd@epa.gov>
To: XAFS Analysis using Ifeffit <ifeffit@millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] Question about Io during data collection
Message-ID:
        <BY1PR09MB091823A3FBDB6E06C8361B3CFF9A0@BY1PR09MB0918.namprd09.prod.outlook.com>

Content-Type: text/plain; charset="utf-8"

Matt and Max,

Thank you for your responses, the information was really helpful in trying to understand what would lead to the changes in Io between scans.  My knowledge of the infrastructure and mechanics of the beamline in front of Io is limited, and this short discussion has been very insightful. I wanted to make clear I was not trying to call out a specific issue with a beamline, but rather better inform myself about the how beamlines in general are setup and the mechanics behind it.

It is hard to find a specific text or manuscript that covers topics along this line.  Not just with XAFS, the same could be said about a number of other spectroscopy/analytical techniques.  Being able to pose questions of this nature to the list is really helpful and provides an insight and source of information that is not readily available.

All the Best,

Todd Luxton, Ph.D.
Office of Research and Development
National Risk Management Research Laboratory
Land Remediation and Pollution Control Division
Waste Management Branch

Mailing Address:
5995 Center Hill Ave
Cincinnati, OH 45243

Phone:
Office: (513) 569-7210
Cell: (513) 319-5104
Fax: (513) 569-7879

Email: Luxton.todd@epa.gov<mailto:Luxton.todd@epa.gov>

?A nation that destroys its soils destroys itself?
Franklin D. Rosevelt

From: Ifeffit [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of Matt Newville
Sent: Thursday, March 31, 2016 6:41 PM
To: XAFS Analysis using Ifeffit <ifeffit@millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] Question about Io during data collection

Hi Todd,


On Thu, Mar 31, 2016 at 9:27 AM, Luxton, Todd <Luxton.Todd@epa.gov<mailto:Luxton.Todd@epa.gov>> wrote:
All:

Recently our group was at the APS collecting Pb L(III) spectra on an ID line using quick XAFS.  Data was collected from -200 to +800 eV for Pb L(III) at 0.2 eV steps with a count rate of 0.025 seconds.  Each scan took about 2.5 minutes to complete.   During our measurements we began noting issues with the linearity of scans collected in the extended region of the same sample.  After poking around in the data we noticed that Io was not linear throughout the measurement for a portion of the scans.  This was not always the true (see Athena project attached to the email, and images attache to the email).  I was always under the impression that Io should ideally remain linear throughout the energy region scanned, or at least remain unchanged between replicate scans.  We worked with the beamline scientists to try alleviate/fix the issue, but it kept persisting.   I realize this is not an IFEFFIT issue, but I was hoping someone might be able to help me understand what was going on !
 and why this was happening?  If I have not included enough information for the question please let me know.

It's a little hard to see much detail from the blurry images, but I0 is definitely falling in dramatically different ways for the different scans.
My guess (from similar experience trying to do continuous XAFS scans at another APS ID line) is that the undulator is not tracking with the monochromator correctly in some of the scans. This tracking is definitely challenging for us. I suspect MR-CAT does small, constant energy steps per time point, but I'm not sure of this.  There is no way I can scan my undulator at 25 ms per energy point.
What I see (and from talking to the undulator control folks at the APS), there is about a 0.5 second "settling time" for the devices during which time is pointless to ask for another move.
So, when I do QXAFS at 13-ID-E, I set up "a normal XAFS scan", with 0.05 Ang^-1 steps and move the mono energy between these points in a fixed time -- so doing a ~4 eV move per time point at 10 Ang^-1.   But I find that if I try to go faster than about 100 ms per point, I see oscillations in I0, as the undulator  lags behind and then tries to catch up.   That can put oscillations in I0, but what you're seeing is it just falling off, like the tracking just isn't working.
For those not at the APS, the undulators cannot be hardware-synchronized (perhaps that is "yet", but we've been waiting a long time).  One can move the undulator at a constant rate in gap (mm) velocity, and then try to synchronize the mono energy to that... I don't do that and I'm pretty sure that MR-CAT does not either.

Anyway, I would suspect the tracking of the undulator.
Hope that helps,

--Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20160401/05cb13cc/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit


------------------------------

End of Ifeffit Digest, Vol 158, Issue 1
***************************************