Closed rowlesmr closed 1 year ago
This is one of the several historical anomalies with the pdCIF. Because this item must be listed together with _pd_meas.* items, it belongs to the PD_MEAS category (only items that are in the same category, or are children of the same category, can be listed together). The name doesn't reflect this, as it was named before the rules on names and categories were properly developed. We are stuck with the "_pd_instr_var_illum_len" name (at least as an alias) for backwards compatibility. We could make its official name "_pd_meas.var_illum_len" perhaps, but it is a handy simplification for software to cope with "dotted" names if all it has to do when presented with a "dotted" name is change the "dot" to an underscore to get the old-style name.
So we have tended to leave these definitions alone as historical anomalies and not made the situation any more complicated than it already is for software authors.
The fun of history.
Then how does pd_calib_2theta_offset work? It's definition reads as if you loop it with pd_meas.2theta_scan to provide the calibrated 2th values in the case of a specimen displacement or something where the offset is not constant.
_pd_calib_2theta_offset
belongs to the PD_CALIB_OFFSET
category and so is looped together with the other items in that category. Offsets are listed together with the range of 2 theta that they apply to e.g.
loop_
_pd_calib_offset.id
_pd_calib.2theta_offset
_pd_calib.2theta_off_point
_pd_calib.2theta_off_min
_pd_calib.2theta_off_max
1 0.01 12.0 0.0 20.0
2 0.02 20.0 40.0 60.0
3 -0.03 60.0 100.0 180.0
Another example of a data name that doesn't quite match the category it belongs to.
Ah.
To simplify things, I could just skip the calib loop and go straight to adding a _pd_proc_2theta_corrected
column in the histogram loop. I forgot about that.
Not a bug.
_pd_instr.var_illum_len was listed under PD_MEAS. I think it also had an incorrect _name.category_id.