[Ifeffit] Re: Ifeffit Digest, Vol 1, Issue 123

Grant Bunker bunker at biocat1.phys.iit.edu
Fri Mar 14 17:20:02 CST 2003


HI, Irit - well, I'm sure the whole EXAFS community wishes you the best in
delivery of your third child!  And the whole world hopes the Bush/Saddam
war will be short with minimum casualties on both sides.

(I'll continue the conversation without the whole world listening)

best wishes  - grant

ps congratulations on your Nature paper

On Fri, 14 Mar 2003 ifeffit-request at millenia.cars.aps.anl.gov wrote:

> 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. Re: Ifeffit Digest, Vol 1, Issue 121 (Irit Sagi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Mar 2003 21:07:04 +0200
> From: "Irit Sagi" <cssagi at wisemail.weizmann.ac.il>
> Subject: [Ifeffit] Re: Ifeffit Digest, Vol 1, Issue 121
> To: <ifeffit at millenia.cars.aps.anl.gov>
> Message-ID: <se70f2fb.035 at wisemail.weizmann.ac.il>
> Content-Type: text/plain; charset=US-ASCII
>
> Oops, I see that the whole EXAFS community saw this mail.......Oh well, SHALOM from Israel. Irit.
>
>
>
>
>
>
>
> Dr. Irit Sagi
> Department of structural Biology
> The Weizmann Institute of Science
> ISRAEL
> Tel/Fax 972-8-9342130
> e-mail: irit.sagi at weizmann.ac.il
>
> >>> cssagi at wisemail.weizmann.ac.il 03/13/03 08:56pm >>>
> Hi Grant
> I read your e-mails regarding IFEFFIT and I could not help myself to ask how are you doing and how are things.
> We are all OK here in Israel, as much as we can of course. I am pregnant with my third child and I am due by the end of the month. Besides this, we are well prepared for the USA-Iraq war. In fact we are expecting it to start on Monday.
> I was invited to give a talk in the APS workshop this year but I will not be able to make due to the new baby.
> I hope that everything is OK with you and your family.
> All the best, Irit.
>
> Dr. Irit Sagi
> Department of structural Biology
> The Weizmann Institute of Science
> ISRAEL
> Tel/Fax 972-8-9342130
> e-mail: irit.sagi at weizmann.ac.il
>
> >>> bunker at biocat1.phys.iit.edu 03/13/03 08:38pm >>>
> Matt - it might be sensible to just add a new function to do the
> rebinning i.e. map mu(E)->mu'(E') on resampled grid (mu data around the
> edge could be left unchanged). People could call the function ('rebin"?)
> only they needed it; subsequent routines could be kept as they
> are now. Anyone who doesn't like the rebinning wouldn't be obligated to
> use it.
>
> thanks - grant
>
> On Thu, 13 Mar 2003 ifeffit-request at millenia.cars.aps.anl.gov wrote:
>
> > 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. RE: Rebinning (Kelly, Shelly D.)
> >    2. Rebinning (Bruce Ravel)
> >    3. Re: Rebinning (Carlo U. Segre)
> >    4. Re: Rebinning (Matt Newville)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 12 Mar 2003 13:52:45 -0600
> > From: "Kelly, Shelly D." <SKelly at anl.gov>
> > Subject: RE: [Ifeffit] Rebinning
> > To: "'XAFS Analysis using Ifeffit'"
> > 	<ifeffit at millenia.cars.aps.anl.gov>
> > Message-ID:
> > 	<DC97518EF1B5E3418A86F59A9A58035D01D9A70A at ANLEXCH.CTD.ANL.GOV>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hello All,
> >
> > There seems to be a lot of interest in Rebinning data.  I have a perl script
> > that
> > I've written to do the same thing.  I thought it might be of interest.
> >
> > Shelly
> >
> > > -----Original Message-----
> > > From: Newville, Matthew G.
> > > Sent: Tuesday, March 11, 2003 2:08 PM
> > > To: Carlo.Segre at iit.edu; XAFS Analysis using Ifeffit
> > > Subject: Re: [Ifeffit] Rebinning
> > >
> > >
> > > Hi Carlo,
> > >
> > > Thanks!!  That's wonderful.  It seems like this should be an
> > > option in spline() and bkg_cl(), and possibly in pre_edge().  I
> > > admit to being still a little confused by the goal of the
> > > rebinning, especially with respect to loss of resolution.  It
> > > seems like to use this script, you need to do two things:
> > >   1. select an E0.   The data will be put at energies that
> > >      will give an even k-grid with this e0.  I think it's
> > >      inevitable that if e0 changes, you might want to re-bin.
> > >
> > >   2. assume that the k-grid is small enough that the
> > >      measurements at independent energies are within the
> > >      acceptable energy resolution that they can be
> > >      simply summed.
> > >
> > > Is that right?
> > >
> > > Would it be OK with you (and everyone else) to have a weighted
> > > average replace the boxcar average?  For example, at k=12,
> > > [E(k+0.05) - E(k)] = 5eV, which is larger than normal energy
> > > resolutions, so the boxcar average might wash out the high-k
> > > EXAFS, no?  It might be better to convolve the spectra with a
> > > lorenztian reflecting the incident energy resolution (probably
> > > defaulting to 1eV).  Does that seem OK or is there something eles
> > > going on?
> > >
> > > Anyway, thanks!!
> > >
> > > --Matt
> > >
> > > _______________________________________________
> > > Ifeffit mailing list
> > > Ifeffit at millenia.cars.aps.anl.gov
> > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> > >
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: binpt.pl
> > Type: application/octet-stream
> > Size: 4769 bytes
> > Desc: not available
> > Url : http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20030312/03a3b542/binpt-0001.obj
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 12 Mar 2003 16:02:37 -0500
> > From: Bruce Ravel <ravel at phys.washington.edu>
> > Subject: [Ifeffit] Rebinning
> > To: "'XAFS Analysis using Ifeffit'"
> > 	<ifeffit at millenia.cars.aps.anl.gov>
> > Message-ID: <200303121602.37646.ravel at phys.washington.edu>
> > Content-Type: text/plain;  charset="us-ascii"
> >
> >
> > Hey folks,
> >
> > As an interface developer, I have to keep a broad perspective.  It
> > seems to me that, when Athena gets a rebinning capability, it should
> > give the user a choice between boxcar and convolution (and whatever
> > other technique someone makes a reasonable case for), thus I would
> > want to implement something like what Ken or Shelly wrote as well as
> > an interface to ifeffit's built-in convolution thingie.
> >
> > To address one of Matt's points, I reckon I'll put a flag in Athena's
> > group object that would get set whenever E0 changes.  That way Athena
> > could automagically rebin the data before background removal for any
> > data group for which rebinning has been requested.  That combined with
> > some of Athena's other automation features should make handling large
> > amounts of qexafs data a breeze.
> >
> > As for which approach is appropriate, Grant pointed out that
> > preserving resolution at high k is not completely necessary.  I agree,
> > but only with the caveat that your measurement is of a single edge.
> > One could imagine using quick measurement techniques to measure two
> > different, nearby edges --- perhaps for a dichroism experiment,
> > perhaps simply to measure two exafs spectra.  In that case, Matt's
> > concern about boxcar is quite valid.   That's not rocket science, but
> > it would be easy to forget at the beamline at 3 in the morning ;-)
> >
> > Regards,
> > B
> >
> > P.S.  I really have to insist that everyone (and _especially_ the
> > digest users) respect netiquette quoting guidelines.  In the last few
> > days there have been some egregious examples of poor netiquette on our
> > lovely, little mailing list.  Here's a nice explanation of how to
> > quote when responding to another person's posting:
> >
> >   http://earlydues.hispeed.com/ieel/netiquette.htm#quote
> >
> >
> >
> > --
> >  Bruce Ravel  ----------------------------------- ravel at phys.washington.edu
> >  Code 6134, Building 3, Room 222
> >  Naval Research Laboratory                          phone: (1) 202 767 5947
> >  Washington DC 20375, USA                             fax: (1) 202 767 1697
> >
> >  NRL Synchrotron Radiation Consortium (NRL-SRC)
> >  Beamlines X11a, X11b, X23b, X24c, U4b
> >  National Synchrotron Light Source
> >  Brookhaven National Laboratory, Upton, NY 11973
> >
> >  My homepage:    http://feff.phys.washington.edu/~ravel
> >  EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 12 Mar 2003 15:19:09 -0600 (CST)
> > From: "Carlo U. Segre" <segre at iit.edu>
> > Subject: Re: [Ifeffit] Rebinning
> > To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> > Message-ID:
> > 	<Pine.LNX.4.44.0303121048420.5582-100000 at oxide.phys.iit.edu>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >
> > Matt:
> >
> > I think that I didn't explain clearly.  First of all, I misused the name
> > boxcar.  In the most stringent of definitions we are not doing a boxcar
> > average because we make no assumptions of where the energy position is to
> > be.  Let me try to restate it.
> >
> > 1. There is no effort to put the data on a uniform energy grid.  The date
> > from a continuous scan is never on an even grid anyway, just
> > approximately.  This is because, at least at MR-CAT, we just count the
> > encoder steps and use that to determine the angular position and thence
> > the energy.  Since we can only se our monochromator to move at a uniform
> > angular speed (and even the spacing in angle is not always perfectly
> > uniform), the energy spacing will have a siusoidal dependence at the best.
> >
> > 2. There is no effort to put the data on an even grid in k-space.  The
> > purpose of the delta-k is to set the window over which we average the
> > data.  The algorithm determines which points in energy space are within
> > the desired box in k-space and then it finds the center of mass of the
> > points by averaging the counts AND averaging the energy too.
> >
> > The resultant spectrum will have datapoints which have the desired density
> > but which will not be on any kind of regular grid.  The idea is to let the
> > analysis programs such as IFEFFIT interpolate and regrid.
> >
> > Carlo
> >
> > On Wed, 12 Mar 2003, Matt Newville wrote:
> >
> > >Hi Carlo,
> > >
> > >On Tue, 11 Mar 2003, Carlo U. Segre wrote:
> > >
> > >> Matt:
> > >>
> > >> Jeff Terry mentioned that perhaps I did not explain myself adequately with
> > >> the last message.
> > >>
> > >> The algorithm averages BOTH counts and Energy.  We do not just place the
> > >> average number of counts at the center of the bin.  Because of this, there
> > >> should be no distortion and no need to weight.
> > >>
> > >> Carlo
> > >
> > >I'm not sure I see that at first glance, but I'll take your word
> > >for it.  That isn't what I'm concerned about.
> > >
> > >Let me explain where I get stuck: let's say you have data
> > >collected in energy steps of 0.25eV -- could be QEXAFS, could be
> > >step scan.  For the sake of argument, lets' set the energy
> > >resolution to 1eV.  You have to get the data on the 0.25eV grid
> > >to an even k-grid for the analysis (at least in ifeffit).  For
> > >the sake of argument, we'll say dk = 0.05Ang^-1, No matter what
> > >the details are, you need to get values of mu(E) for the data
> > >onto a gridded set E={E_i}.
> > >
> > >At k=4, E~=61.0, and k=0.05 corresponds to 1.5eV.  A boxcar
> > >average will average the original data between 60.25 and 61.75
> > >and call that the new data for E=61.  Seems reasonable, though
> > >giving equal weight to the data at 61.0 and 61.75 could be
> > >questioned for 1eV resolution.
> > >
> > >At k=16, E~=975.0 eV, k=0.05 corresponds to 6eV.  So here, you
> > >average of data between E=972.0 and 978.0eV and call that the
> > >data for E=975.0eV.  Giving equal weight to the data at 972.0 and
> > >975.0 when the resolution is 1eV is what worries me.  The simple
> > >average of mu(E) between 972.0 and 978.0 is definitely not the
> > >same as mu(E) at E=975.0. It would probably be better to average
> > >the original data between 974.0 and 976.0 for the new data at
> > >975.0, and might be preferrable to just do a convolution with a
> > >1eV point spread function for all the data.
> > >
> > >Certainly, if you were to re-bin data collected in 0.25eV steps
> > >to a grid of 10eV there would be real problems.  By 'using all
> > >the data', one can use too much data and spoil the resolution.
> > >
> > >I don't claim that the boxcar average is wrong, or that
> > >convolution is definitely the right thing to do, just that I'm
> > >confused by this.
> > >
> > >--Matt
> > >
> > >_______________________________________________
> > >Ifeffit mailing list
> > >Ifeffit at millenia.cars.aps.anl.gov
> > >http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> > >
> >
> > --
> > Carlo U. Segre -- Professor of Physics
> > Associate Dean for Research, Armour College
> > Illinois Institute of Technology
> > Voice: 312.567.3498            Fax: 312.567.3494
> > Carlo.Segre at iit.edu    http://www.iit.edu/~segre
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 12 Mar 2003 16:34:27 -0600 (CST)
> > From: Matt Newville <newville at cars.uchicago.edu>
> > Subject: Re: [Ifeffit] Rebinning
> > To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> > Message-ID:
> > 	<Pine.LNX.4.44.0303121629250.13751-100000 at millenia.cars.aps.anl.gov>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >
> > Carlo, Grant, Shelly, Bruce,
> >
> > Thanks!  Shelly's script eems to be similar to what Carlo, Ken,
> > and Grant have done as well, at least as far as how the rolling
> > average is done. I think Sam Webb mentioned he had used a similar
> > technique for some of his QEXAFS data too.  So the consensus
> > definitely seems to be that the moving simple average over a
> > limited energy/k range is 'good enough' when converting to
> > k-space.  I agree with that: it's certainly no worse than what
> > happens in ifeffit/autobk now.
> >
> > I'm sort of uncomfortable with automatically rebinning the mu(E)
> > data for it's own sake, because I think it's too easy to lose
> > resolution of the data.  I think no one was proposing that -- the
> > discussion seems only how to convert data on a fine energy grid
> > to k -- but I want to make sure.  At any rate, the conversion of
> > mu(E) to chi(k) seems to be the part that ifeffit should be
> > concerned with.  I propose these behaviors for ifeffit commands:
> >
> >  - read_data() should leave the QEXAFS energy values intact,
> >    optionally sorting data.  That is the current behavior.
> >
> >  - spline() and bkg_cl() [the commands that convert mu(E) to
> >    chi(k)] need to work with both 'step scan' and 'continuous'
> >    energy data.  That complicates things a little, but I think it
> >    means they should create chi(k) on the even k-grid like this:
> >
> >    At each k-point (i*kgrid for i=0,Npts), if there are more than
> >    2 data points in the range (k - kgrid/2, k + kgrid/2], average
> >    all points in that region.  If there are fewer than 2 points
> >    in that range, do a 3-point interpolation using the 2
> >    surrounding points and the next nearest point.  Both of these
> >    averages may spoil resolution somewhat, but like Grant says,
> >    the kgrid=0.05 is pretty conservative anyway.
> >
> > I believe this approach will handle QEXAFS data about as well and
> > as simply as possible, and needs no additional flags or settings.
> > The rolling average will *ALWAYS* be done by spline() and
> > bkg_cl() if and where it is needed. That will make spline() a
> > little slower, but only because it would be using more data.
> >
> > This change should help other data, and do no harm that isn't
> > already being done.  For example, data taken on an even energy
> > grid would 'use all the data' to effectively increase the dwell
> > time at each k value linearly with k.  Currently, this does not
> > happen with ifeffit/autobk, and the additional statistics
> > inherent in such data is lost.
> >
> > This approach should also make Bruce's job much easier, as the
> > calls to spline() and bkg_cl() from athena would not need any
> > changes for QEXAFS data.
> >
> > Any objections, suggestions, or other thoughts?
> >
> > --Matt
> >
> > PS: I think that the fix for the non-uniform k-grid problem in
> > feffit() and this new E->k procedure would be enough to call it a
> > new version.  Were there any other outstanding requests?
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Ifeffit mailing list
> > Ifeffit at millenia.cars.aps.anl.gov
> > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> >
> >
> > End of Ifeffit Digest, Vol 1, Issue 121
> > ***************************************
> >
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>
>
>
> ------------------------------
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>
>
> End of Ifeffit Digest, Vol 1, Issue 123
> ***************************************
>



More information about the Ifeffit mailing list