Hi Johan,

On Fri, May 27, 2016 at 6:21 AM, Johan Nilsson <johan.nilsson@chalmers.se> wrote:

Hello,

I've found a small "bug" in larch when I tried to run the pre_edge function for some spectra. It seems that find_e0 will not accept a 2d 1-column array as input for energy or mu, and it gives a traceback which is quite difficult to decipher. Other functions like plot accepts these arrays without any problems, which made it a bit difficult to figure out what the problem was. Maybe there can be some some sort of warning if arrays have unexpected shapes, or an internal reshape if that works. I've attached a script that should give a minimum working example, my output is:

larch> run('cu.lar')
(612,)
8977.58
(612, 1)
File "/usr/local/lib/python2.7/dist-packages/larch/__init__.py", line 37, in wrapper
    return fcn(*args, **keywords)
File "/usr/share/larch/plugins/xafs/pre_edge.py", line 51, in find_e0
    dmu = np.gradient(mu)/np.gradient(energy)
File "/usr/lib/python2.7/dist-packages/numpy/lib/function_base.py", line 918, in gradient
    out[slice1] = (f[slice2] - f[slice3])file cu.lar, line 14
IndexError: index 1 is out of bounds for axis 1 with size 1
    find_e0(e,cu.mu,group=cu)
find_e0(e,cu.mu,group=cu)
file cu.lar, line 14
larch>

Thanks. I'll turn this into a github Issue. For completeness (though I suspect you had figured this out), the immediate problem can be solved by simply doing

e = e.squeeze()

That said, I do see your point that this should be done by find_e0(). If every function that wanted a 1d array had to make such tests, it would probably be a losing battle. But, it is probably reasonable to expect the "processing functions" like find_e0(), pre_edge(), and autobk() -- that is, the functions designed to take "raw"-like data arrays" and turn them into EXAFS -- should try to accept data arrays in lots of "formats", including plain lists data with extra dimensions, and possibly even pandas dataframes.

--Matt