Closed rowlesmr closed 1 year ago
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.
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.~~
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.
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:
_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?_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._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.
_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).
_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
....
_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 thepoint_id
data name is used and all calibration points are forced to be included in thepd_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
....
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
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).