# [Ifeffit] continuous scan data

Matt Newville newville at cars.uchicago.edu
Wed Jul 17 10:11:02 CDT 2002

```Hi Carlo,

On Tue, 16 Jul 2002, Carlo U. Segre wrote:

> First of all, thanks!  I just put athena and ifeffit on our beamline
> computer at MR-CAT for our users to assess data as they take it.  It
> proved to be very easy for the students and newbies to figure out.

Thanks!!  Like Bruce said, that's great news.

> The question that I have is how does IFEFFIT handle continuous scan data,
> where the point spacing is almost but not quite uniform in energy all the
> way through the scan.
>
> I have noticed the error of misordered data which can often show up in the
> continuous scans.  We will probably try to fix that ourselves.
>
> What is done with the high density data when converting to k-space?  Do
> you rebin (averaging both E and mu data) or do you use a smoothing fit to
> take advantage of the statistics present in the excess data points, or do
> you just interpolate and throw away the extra statistics?

It's supposed to handle data binned from continuous scans,
including data in order that's not strictly increasing in
energy.  Of course, it could be making mistakes: we haven't
tested this very extensively.  There's also the possibility
that's it's not working as expected (or really desired).

What's supposed to happen with out-of-order data is:

-- read_data() normally does not re-order the data.  This is
because it's not always obvious which column to use to order
the data in (some data is given as a function of mono
angle, energy might not be the first column, etc).

-- if you know (or athena can help you guess) which column
should be in strictly increasing order, you can use
read_data(file =...  , sort = 1)

where 'sort=n' means to sort all the data so the nth column
is strictly increasing.  At this point, duplicate values are
preserved.

-- the pre_edge() and spline() commands should handle poorly
sorted energy/xmu data (including duplicate energy values:
here it uses the average of the duplicate values), and
will generate arrays for normalized xmu, and background
arrays that exactly match the input energy array (that is,
not necessarily sorted).  That way, point-by-point
subtraction will still work as expected.

-- spline() generates k and chi arrays using a 0.05Ang-1 grid
using a three-point interpolation of the chi(e) data.
That could possibly be improved, I suppose.

So my first guess would be that using