XasDataSource: common API to XAS data

[woutdenolf]

Closes #409

To check with the data from https://github.com/xraypy/xraylarch/issues/409#issuecomment-1259174550

from glob import glob
from larch.io.xas_data_source import open_xas_source

for filename in glob("*.nxs"):
    source = open_xas_source(filename)
    print()
    print(filename)
    print(source.TYPE)
    for name in source.get_scan_names():
        scan = source.get_scan(name)
        print(scan.name)
        print(scan.description)
        print(scan.labels)

This API works with all NeXus compliant HDF5 files (extra support for ESRF and SOLEIL) and SPEC files.

Unit tests are provided for HDF5 (ESRF, SOLEIL, generic NeXus) and SPEC files.

GUI support has been started but needs work in another PR.

[woutdenolf]

@newville Does this go in the right direction? Do you think the API would work for all other sources (athena, xdi, ...)? It would be nice if all data importers have the same API.

[maurov]

@woutdenolf @newville what should we do with this pull request?

Here what I propose:

• keep the code in xas_data_source
• discard all GUI related changes in wxlib and wxxas
• convert test.py to a Jupyter notebook example to put in examples/Jupyter

[newville]

@woutdenolf @maurov Yeah, sorry that this got side-lined and less attention than it should have gotten.

I agree with the idea, and having a folder/module for xas_data_source (maybe io.xas?? not a strong preference) is a generally good idea -- like, we could move the existing readers for Athena and XDI, and perhaps beamline-specific readers (but hopefully not too maybe "facility-specific" readers) there as well, and then potentially have a folder/module for readers of XES, XRF, XRD, XRF map data too.

So, I agree with Mauro that we take xas_data_source and then re-work the changes to wxlib and wxxas. And, yes to a Jupyter example!

I'm OK with merging this even if not quite finished, and then fixing up some of those things in follow-up work.

[woutdenolf]

@newville Do you mind waiting over the holidays? I will likely find some time to work on this.

[newville]

@woutdenolf Yes, that is no problem at all!

[maurov]

@newville @woutdenolf thanks for your feedback! OK, let's wait new year for working on this (in parallel with the NXxas definition).

We currently have three different APIs for reading Spec/HDF5/NeXus (ESRF) spectroscopy data:

• this proposal
• what I have done in larch.io.datasource_spech5 (wrapper on top of silx.io.open)
• DAXS

It would be great to merge everything in a single common API, @mretegan would you be interested in merging here what you have done in DAXS?

@newville @woutdenolf @mretegan, what about to postpone this to a code camp during the ESRF users meeting week in February? It would be much faster than discussing here.

[newville]

@maurov @woutdenolf @mretegan I am OK for a code camp at/around the ESRF user meeting.

I would say that 3 different opinions/codes from 3 different people for reading ESRF Spec/HDF5 files is understandable ;). But hopefully, those could be combined.

FWIW, my preference is usually to avoid too many "Factory functions" and "abstract reader classes" and try to keep things as pretty simple functions when possible. But for a complex data store like an HDF5 file, a class that wraps the file and has methods to get/set/manipulate various data bits from that does make sense.

[woutdenolf]

@newville @maurov Ready for review/merge. I added unit tests and removed the GUI support (code is commented).

[maurov]

@woutdenolf @newville I have done some quick tests on my side and I propose merging it.

[newville]

@maurov @woutdenolf OK, I'll merge this... thanks both!