Processor interface

[steinnymir]

How will the interface to the processor look like?
Will we just pass the loaded data frame?
How will we deal with meta data here?

There are many open questions about this matter, and I would suggest that anyone who has an idea, good or bad, should write it here!

As this is inteded to give the best user experience, the requests and expectations of users are vital to define a succesful interface.

[rettigl]

I was thinking somewhat on the general outline of the class and the interface to the other pieces, and what would be convenient to use.
Our pipeline looks something like:

1. load data
2. bin subset of data in machine coordinate
3. feed this subset into the momentumCalibrator class, and generate distortion corrections and momentum calibration parameters
4. load additional files for energy calibration, feed those into energyCalibrator class, and generate energy calibration parameters
5. use use these generated parameters to bin the data into momentum and energy calibrated grid

Right now, one needs to move all the calibration elements piece by piece as input elements to functions between the different classes, and there is no conventient and automatic interface.

I think most conventient would be to integrate the whole work flow into one class, that stores all data generated by the individual steps in class attributes and takes care of automatically moving it between the member functions and classes.

What we should discuss is how this fits with our goal of making a rather generic class.

[steinnymir]

What you describe seems much like a merging of the structure of hextof-processor with the functionality of MPES.
I am still not sure how to reduce the requirement of human input in some cases, such as evaluation of optimal correction parameters, but it seems like a solid structure and starting point.

[rettigl]

Another thought to the data input interface:
From the convenience point of view, it would also be nice to have this as part of the class. So you don't need to pass metadata and dataframes around, and handle multiple classes, but just one. I was wondering if we could write an abstract "reader" class, that reads in files, and generates a dataframe out of them, and then several implementations for the different use cases (labs), that derive from this abstract class?
We did something similar for the reader class in the datacoverter of the parser-nexus package, so there is an example to start from.

[steinnymir]

This is a very good idea. An abstract reader class can also be useful for testing, or loading data already in tabluar format.
Subclassing this to create the specific dataframe generation class for each application should be a safe way to input data in SED.

[rettigl]

I can create an issue for that and start to build a skeleton based on what we have for this in the nexus-parser project, if I find time.

[rettigl]

Regarding the core class itself: You started to make it "xarray-like". Could we just make it a subclass of xarray.DataArray?

[steinnymir]

We are not really dealing with an array until the binning result. To subclass xarray.DataArray we would need an array to initialize it.
Furthermore, xarray is not well designed for subclassing (citing their own documentation) and therefore I don't think this would be so helpful.

[rettigl]

Yes, I came to a similar conclusion yesterday, you need to know the size of the xarray at the point of creation it seems. Still, maybe we can think about how to make class interface functions to the binned xarray, so that one can easily manipulate and e.g. plot it after binning in an intuitive manner (that was my initial idea behind this, and probably your's as well).

[rettigl]

From the other discussion, and thinking about this in other contexts, I believe what I sketched here should be implemented in another class, that imports and utilizes this package. Then we keep the sed package and class functionality relatively clean and reusable.