[Ifeffit] Ifeffit Digest, Vol 158, Issue 1

Matteo Busi basebush at gmail.com
Fri Apr 1 08:35:43 CDT 2016 

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 at millenia.cars.aps.anl.gov>:

> Send Ifeffit mailing list submissions to
>         ifeffit at 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 at millenia.cars.aps.anl.gov
>
> You can reach the person managing the list at
>         ifeffit-owner at 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 at gmail.com>
> To: ifeffit at millenia.cars.aps.anl.gov
> Subject: [Ifeffit] Chi(E) data export and import
> Message-ID:
>         <
> CAOyEiGhFhPbQ5Xn1is+R4MPVDQ4mxS4wXCcWM-j2qBcO5117-g at 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 at bnl.gov>
> To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> Subject: Re: [Ifeffit] Chi(E) data export and import
> Message-ID: <56FE68A3.5020008 at 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 at 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 at epa.gov>
> To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> Subject: Re: [Ifeffit] Question about Io during data collection
> Message-ID:
>         <
> BY1PR09MB091823A3FBDB6E06C8361B3CFF9A0 at 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 at epa.gov<mailto:Luxton.todd at epa.gov>
>
> ?A nation that destroys its soils destroys itself?
> Franklin D. Rosevelt
>
> From: Ifeffit [mailto:ifeffit-bounces at millenia.cars.aps.anl.gov] On
> Behalf Of Matt Newville
> Sent: Thursday, March 31, 2016 6:41 PM
> To: XAFS Analysis using Ifeffit <ifeffit at 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 at epa.gov<mailto:
> Luxton.Todd at 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 at 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
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20160401/e13ae406/attachment-0001.html>

More information about the Ifeffit mailing list