Trying to understand description of `_pd_proc.wavelength`

[rowlesmr]

PD_PROC is a Loop category

_pd_proc.wavelength is described as:

Wavelength in angstroms for the incident radiation as computed from secondary calibration information. This will be most appropriate for time-of-flight and synchrotron measurements. This will be a single value for continuous-wavelength methods or may vary for each data point and be looped with the intensity values for energy-dispersive measurements.

I'm confused about the "This will be a single value for continuous-wavelength methods" bit; isn't this what _diffrn_radiation_wavelength.value and _diffrn_radiation_wavelength.determination is for?

I get the next bit; you can use either energy, wavelength, or q as the X-coordinate for energy-dispersive data.

Is it even legitimate to give a single value to a loop data item, while also giving many values to other data items in another loop?* eg

_pd_proc.wavelength 1.234

loop_
_pd_data.point_id
_pd_proc.2theta_corrected
_pd_meas.intensity_total
_pd_calc.intensity_total
1   5.12   456.45   465.3
2   5.15   458.14   465.3
#...

* I don't think so, as the category key requirements won't be met.

[briantoby]

The existence of _pd_proc_wavelength was because _diffrn_radiation_wavelength (or whatever it was originally) was sensible only for single crystal work. The latter would be a IT-given (more or less = to handed down at Sinai) scalar value while in a powder diffraction experiment this is often a calibration result; it may be composed of multiple values; or, even be an ordinate in an energy-dispersive experiment (even then derived from quantities possibly fit in the refinement), but it all represents the same concept w/r to the underlying physics.

My goal in defining the original pdCIF dictionary was to minimize the number of pdCIF definitions rather than worry about database normalization. My philosophy was that one wavelength definition would be better, even though from a schema perspective that definition would play very different roles in synchrotron (single calibrated value) vs. lab (multiple primary standard quantities) vs. TOF measurements (derived ordinate). It may be time to change that, but I am not sure the complexity helps crystallographers comprehend the standard or develop software, even though data scientists would insist on normalization even at the expense of keeping the physics parallel.

On Jan 18, 2023, at 8:57 AM, Matthew Rowles @.**@.>> wrote:

PD_PROC is a Loop category

_pd_proc.wavelength is described as:

Wavelength in angstroms for the incident radiation as computed from secondary calibration information. This will be most appropriate for time-of-flight and synchrotron measurements. This will be a single value for continuous-wavelength methods or may vary for each data point and be looped with the intensity values for energy-dispersive measurements.

I'm confused about the "This will be a single value for continuous-wavelength methods" bit; isn't this what _diffrn_radiation_wavelength.value and _diffrn_radiation_wavelength.determination is for?

I get the next bit; you can use either energy, wavelength, or q as the X-coordinate for energy-dispersive data.

Is it even legitimate to give a single value to a loop data item, while also giving many values to other data items in another loop? eg

_pd_proc.wavelength 1.234

loop_ _pd_data.point_id _pd_proc.2theta_corrected _pd_proc.intensity_total _pd_calc.intensity_total 1 5.12 456.45 465.3 2 5.15 458.14 465.3

...

— Reply to this email directly, view it on GitHubhttps://github.com/COMCIFS/Powder_Dictionary/issues/95, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACH7E2H6DXV2NRFZAABJCDLWTAAEDANCNFSM6AAAAAAT7F4MGM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[rowlesmr]

Thanks for that Brian, it does shed quite a bit of light on the situation.

Yeah, _diffrn_radiation_wavelength_determination wasn't added into cif_core until the middle of 2010, which is a little while after cif_pd was released. Also, _pd_proc.wavelength is _list both, which I don't think is a concept that really exists in DDLm

I think now, you're able to do the following, for at least monochromatic(ish) incident beams; for true polychromatic, there is no way in core to assign a wavelength x-coordinate (they do have _refln.wavelength, but that is for reflections, not raw data), so we need _pd_proc.wavelength to fill that gap.

loop_
_diffrn_radiation_wavelength.id
_diffrn_radiation_wavelength.value
_diffrn_radiation_wavelength.wt
_diffrn_radiation_wavelength.determination
1   1.5405925   3.91    fundamental
2   1.5410769   0.474   fundamental
3   1.5443873   1.53    fundamental
4   1.5456782   0.754   fundamental
5   1.5347185   0.0153  fundamental
6   1.5338214   0.0182  fundamental
7   1.5354168   0.0612  fundamental
8   1.5329195   0.0610  fundamental

#...
loop_
_diffrn_radiation_wavelength.id
_diffrn_radiation_wavelength.value
_diffrn_radiation_wavelength.determination
1   1.540562   fundamental

# ...

loop_
_diffrn_radiation_wavelength.id
_diffrn_radiation_wavelength.value
_diffrn_radiation_wavelength.value_su
_diffrn_radiation_wavelength.determination
1   1.000354   0.000024    refined

[jamesrhester]

Would it be acceptable now to restrict _pd_proc.wavelength to energy-dispersive use, so looped with intensity values? The other uses can be covered by _diffrn_radiation_wavelength.value, I think.

[briantoby]

I will reiterate that it elevates data normalization over simplicity in describing the physics, but I do accept this.