Created PD_CALIB_XCOORD

[rowlesmr]

This category holds information on the corrections in X-coordinate used to calibrate detector_ids. It is trying to be a single category that can cover all of the different types of measured x-coordinate; 2Th, TOF, position, wavelength, detector_id (aka channel).

[rowlesmr]

Method 1

Is what it currently does:

PD_CALIB_XCOORD. Loop category, keyed on _pd_calib_xcoord.id and _pd_calib_xcoord.detector_id

Separate data items for each x-coordinate: _pd_calib_xcoord.2theta_nominal, _pd_calib_xcoord.2theta_offset; _pd_calib_xcoord.position_nominal, _pd_calib_xcoord.position_offset; etc.

I think it is supposed to be used as a loop of nominal and offset values, through which a calibration line is drawn and applied to your measured data.

Another way of using it is to associated each offset with a point_id from your diffractogram. This is a direct transformation of meas to proc data.

method 2

An idea I just had

PD_CALIB_XCOORD. Loop category, keyed on _pd_calib_xcoord.id and _pd_calib_xcoord.detector_id

Two (main) data items for each x-coordinate: _pd_calib_xcoord.nominal, _pd_calib_xcoord.offset

PD_CALIB_XCOORD_OVERALL. Set category, keyed on something.

~~one main data item: _pd_calib_xcoord.type which is an enumerated list of "2theta", "position", or "TOF" which determines what type of x-coord it is.~~

Method 2 is bad.

[rowlesmr]

Should

• _pd_calib_xcoord.special_details
• _pd_calib_xcoord.block_id
• _pd_calib_xcoord.phase_id
• _pd_calib_xcoord.diffractogram_id

be in their own PD_CALIB_XCOORD_OVERALL Set category, as they would (normally, always, ...?) apply to the entire calibration.

[jamesrhester]

I am happy with the overall direction of the proposal, despite the proliferation of data names for each type of x-coordinate. Any given dataset is likely to use only a particular subset of them.

Some thinking-out-loud thoughts:

1. _pd_calib_xcoord.detector_id is necessary, I think, because even though the diffractogram that has been used for calibration will determine the relevant detector, what if a diffractogram wasn't used?
2. _pd_calib_xcoord.point_id is purely informational, as the tth/tof/position equivalent will still be provided. It is presumably possible that a calibration point won't be one of the pd_data points.
3. _pd_calib_xcoord.id doesn't really add anything as a key, because nothing refers to it from elsewhere. However, there is no other data name that could be the key in its place unless the point_id data name is used and all calibration points are forced to be included in the pd_data list of points. What do you think of this?

Should

* `_pd_calib_xcoord.special_details`

* `_pd_calib_xcoord.block_id`

* `_pd_calib_xcoord.phase_id`

* `_pd_calib_xcoord.diffractogram_id`

be in their own PD_CALIB_XCOORD_OVERALL Set category, as they would (normally, always, ...?) apply to the entire calibration.

A particular phase in a particular diffractogram is used to calibrate position, so therefore both diffractogram and phase should be identified for a given group of calibration points. I agree that an overall category is therefore sensible, as otherwise the above items would be repeated for every point. But it needs to take into account the possibility of calibrations for multiple detectors (so multiple pieces of overall information), so there must be a way for the information in the overall category to be linked to the lists of offsets. One way to do this is to move _pd_calib_xcoord.detector_id to the overall category, and then the key to the loop of offsets could be a dataname that points to _pd_calib_xcoord_overall.id (new data name) and _pd_calib_xcoord.point_id (as per above suggestion). If the point_id data name being a key data name is controversial, we can keep the way things are now, minus detector_id, and just have an ordinary (non-key) data name pointing to the overall_id.

[rowlesmr]

1. _pd_calib_xcoord.detector_id is necessary, I think, because even though the diffractogram that has been used for calibration will determine the relevant detector, what if a diffractogram wasn't used?

Yes. The detector to which the calibration applies needs to be able to be designated. I've always calibrated my Inel detector using the direct beam, so you can't rely on a diffractogram inference (or also calibration points corresponding to diffraction data points).

2. _pd_calib_xcoord.point_id is purely informational, as the tth/tof/position equivalent will still be provided. It is presumably possible that a calibration point won't be one of the pd_data points.

I need to write some examples. To my mind, this category is used to record peak displacements relating to specimen displacement (as a primary example, not it's only use), so if you give a point_id, the _pd_meas.2_theta value from the diffraction data is used as the "nominal" position, and the offset is applied to that:

data_diffractogram

loop_
_pd_calib_xcoord.point_id
_pd_calib_xcoord.2theta_offset
1    0.01
2    0.01
3    0.02
4    0.02
...

loop_
_pd_data.point_id
_pd_meas.2theta_scan
_pd_meas.counts_total
_pd_calc.intensity_total
1   10.01   1234    1234.1
2   10.03   1235    1235.3
3   10.05   1352    1236.5
4   10.07   1324    1237.7
....

3. _pd_calib_xcoord.id doesn't really add anything as a key, because nothing refers to it from elsewhere. However, there is no other data name that could be the key in its place unless the point_id data name is used and all calibration points are forced to be included in the pd_data list of points.

Just plain id is used if the calibration points don't necessarily correspond to data points. The calibration may need some sort of interpolation to be applied (which would be described in special_details).

data_diffractogram

loop_
_pd_calib_xcoord.id
_pd_calib_xcoord.2theta_nominal
_pd_calib_xcoord.2theta_offset
a   10.00    0.01
b   12.00    0.02
c   14.00    0.03
d   16.00    0.04
...

loop_
_pd_data.point_id
_pd_meas.2theta_scan
_pd_meas.counts_total
_pd_calc.intensity_total
1   10.01   1234    1234.1
2   10.03   1235    1235.3
3   10.05   1352    1236.5
4   10.07   1324    1237.7
....

[rowlesmr]

Should

* `_pd_calib_xcoord.special_details`

* `_pd_calib_xcoord.block_id`

* `_pd_calib_xcoord.phase_id`

* `_pd_calib_xcoord.diffractogram_id`

be in their own PD_CALIB_XCOORD_OVERALL Set category, as they would (normally, always, ...?) apply to the entire calibration.

A particular phase in a particular diffractogram is used to calibrate position, so therefore both diffractogram and phase should be identified for a given group of calibration points. I agree that an overall category is therefore sensible, as otherwise the above items would be repeated for every point. But it needs to take into account the possibility of calibrations for multiple detectors (so multiple pieces of overall information), so there must be a way for the information in the overall category to be linked to the lists of offsets. One way to do this is to move _pd_calib_xcoord.detector_id to the overall category, and then the key to the loop of offsets could be a dataname that points to _pd_calib_xcoord_overall.id (new data name) and _pd_calib_xcoord.point_id (as per above suggestion). If the point_id data name being a key data name is controversial, we can keep the way things are now, minus detector_id, and just have an ordinary (non-key) data name pointing to the overall_id.

I think I get this. I'll have a go at

just have an ordinary (non-key) data name pointing to the overall_id