How to save numbers needed to create the spectra

[mpmdean]

Saving dictionary of values defining the numbers required to make the spectrum

[danielballan]

One low-rent way is to use jump.dump and json.load: https://docs.python.org/3/library/json.html

[mpmdean]

These are calibration values determined at the beamline e.g. by a calibration scan done by the staff, but that need to be applied to all the downstream data processing.

@awalter-bnl suggested they could be assigned detector attributes
@stuwilkins mentioned writing them into databroker

One could imagine pseudomotors as well? Not that I'm necessarily advocating this.

These are most of the keyword arguments into:
make_scan
in sixtools.rixswrappers

elastic_pixel : float -- databroker
The pixel we consider as elastic. This changes with beamline energy and could either be kept up to date or changed based on a meaurement at a known incident energy.
There are two of these, which we label low_2theta and high_2theta
light_ROI : [minx, maxx, miny, maxy] detector_attribute
Define the region of the sensor to use.
Events are chosen with minx <= x < maxx and miny <= y < maxy
There are two of these, which we label low_2theta and high_2theta
curvature : array detector_attribute
The polynominal coeffcients describing the image curvature.
These are in decreasing order e.g.
.. code-block:: python
curvature[0]*x2 + curvature[1]*x1 + curvature[2]*x**0
The order of polynominal used is set by len(curvature) - 1
There are two of these, which we label low_2theta and high_2theta
bins : float or array like detector_attribute
Binning in the y direction.
If bins is a sequence, it defines the bin edges,
including the rightmost edge.
If `bins' is a single number this defines the step
in the bins sequence, which is created using the min/max
of the input data. Half a bin may be discarded in order
to avoid errors at the edge. (Default 1.)
ADU_per_photon : float detector_attribute
Conversion factor between the input intensity values in table
and photons. This depends on the beamline energy.
detector : string detector_attribute
name of the detector passed on header.data
At SIX
'rixscam_centroids' is the centroided data, which is the default
'rixscam_image' is the image data
min_threshold : float detector_attribute
fliter events below this threshold
defaults to -infinity to include all events
max_threshold : float detector_attribute
fliter events above this threshold
defaults to +infinity to include all events
background : array databroker
2D array for background subtraction
Only used for image data.

[danielballan]

I see. I like @awalter-bnl's suggestion of making that part of what the detector reports as configuration.

[mpmdean]

I added a description of the list of values we are talking about in the comment above.
@stuwilkins was going to weigh in on this shortly.

[mpmdean]

Some quick input from @tacaswell
It should be defined as a descriptor and written during each run.

Consider whether the background should be saved into the desriptor or put into a different data stream.

[stuwilkins]

I think we should think carefully about this. They are not detector attributes

[stuwilkins]

Let’s get together next.week, I don’t like saving info in a run that is the result of an analysis. It seems like a really bad idea to maintain that state in BS

[awalter-bnl]

I am still in favour of making them detector attributes and setting them to be read at configuration time. This way they will be saved in the current 'event_descriptor' document under the 'detector' information in databroker and easily accessible in that way. It also ensures that they are not written unnecessarily when a scan is performed that does not include this detector.

Some quick input from @tacaswell
It should be defined as a descriptor and written during each run.

I am not in favour of creating a seperate new descriptor document purely for these values, I think they should be associated with the detector, and the most logical way to do that is through detector configuration attributes.

While they are technically not attributes of the detector they are values that are required to analyze data from this detector. So tying them to the detector configuration attributes makes the most sense to me. At any rate it should be possible to not use these default values at analysis time.

I am happy to meet next week to dicuss, my outlook is up to date.