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] _detectorattribute 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 _detectorattribute The polynominal coeffcients describing the image curvature. These are in decreasing order e.g. .. code-block:: python curvature[0]*x2 + curvature[1]*x*1 + curvature[2]x0 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 _detectorattribute 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 _detectorattribute Conversion factor between the input intensity values in table and photons. This depends on the beamline energy. detector : string _detectorattribute 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 _detectorattribute fliter events below this threshold defaults to -infinity to include all events max_threshold : float _detectorattribute 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.