Repository navigation
Need canonical names for wavelength resolution and angle resolution #70
Description
Activity
- changed the title
[-]Need canonical names for wavelength resolution and incident angle resolution[/-][+]Need canonical names for wavelength resolution and angle resolution[/+]on Dec 7, 2021 Bearing in mind that the wavelength uncertainty for monochromatic and chopper reactor-based TOF instruments are quite different, with the latter being definitively non-Gaussian - does prefixing with s make sense?
Furthermore, on many chopper based NR instruments (e.g. D17) the wavelength resolution is sometimes relaxed by opening the chopper phasings, meaning that d_{lambda}/lambda is not constant as a function of wavelength.
The angular part is not Gaussian either.
I don't know how you'd denote all that in a simple way, thus proving the necessity for all facilities to put their overall resolution in a sQz column, or creating multiple columns to provide a probability distribution of Qz for each data point.
Don't get me wrong - I am not advocating for those names. I think they are bad. I'm suggesting that we need some standard names that aren't those ones.
I also agree that there are complexities yet to tackle (like distributions at each data point, which I think we can probably all agree doesn't map onto a text representation very well) but I think a first step is to standardise the name of "wavelength resolution" and "angle resolution" or equivalent (we already have a name for the Qz resolution, but if you think sQz is too suggestive of a Gaussian I would be fine with changing it). The shape of the resolution is a separate issue, I think.
We can not combine wavelength and angular resolution into sQz (even if we make it very detailed), because we often in the fitting adjust "sample broadening", which is an addition/subtraction to angular resolution, coming from the curvature of the sample.
We (at NIST, not ORSO) also can't combine incident angle and wavelength into Q, because of uncertainties in the incident angle (for small samples) that necessitate a theta_offset fit parameter, which is why we need separate incident_angle and wavelength columns, and for us the Q column is actually not used most of the time.
I think this is addressed with the "physical_quantity" keyword in https://github.com/reflectivity/file_format/blob/master/specs_discussion.md#reserve-key-words
This issue is a blocking one for us: we can't deploy orsopy-based tools or integrate orsopy into refl1d until it is resolved. I hope it can be resolved soon.
Is there any reason not to use "wavelength resolution" and "angular resolution"?
Not sure I understand what the actual issue is here. I would think that all these points are already covered by the current specification or not necessary to be in the specification:
- Any user column that is added can have an error/resolution using
ErrorColumnas column. - The
ErrorColumndoes not have a name and references directly to the column it applies to. - The "sQz" is only used in the column header line, which is a comment that is not part of the specification. Currently it automatically adds the "s" in the front, but we could change that if required (e.g. to σ, as we are UTF-8). This, however does not influence the .ort specification or readout of the data.
- Non-gaussian errors are also covered with
ErrorColumn, using thedistributionattribute. If it is not a Lorentzian, sigma still makes sense, but even FWHM is possible if the attributeerror_typeis used. - In the case where you want to provide resolution to a fixed parameter (e.g. wavelength for monochromatic) we also have the
errorattribute now, which allows the same flexibility when you supply anErrorValueas in the case of a column.
If you like I can create an example file, just send me some columns and information that need to be supplied.
So please correct me if I'm missing something, but I think everything you mentioned is already resolved.
If not, we can have a quick Zoom meeting this week to discuss.- Any user column that is added can have an error/resolution using
Yes, you can add "error_of" to a column. That is not the problem I am describing.
We do not have a specified way to resolve quantities that must be located in either
columnsordatasource.measurement.instrument_settings
such as:
- wavelength
- wavelength resolution
- incident angle
- angular resolution
Any analysis software that is looking for these values needs a resolution scheme, that is specified, because these items (among others) can be found in either 1 or 2. The
error_ofattribute only helps you if you already know you have a column for wavelength, and we don't have a specified way of doing that.Here is an example: let's say my analysis software wants to know the angular resolution for a measurement. Right now, it can look in
datasource.measurement.instrument_settingsfor anangular_resolution, or it can look for a column for the incident angle and then look at all the other columns and try to find one that has anerror_ofattribute that points to the first column (by name, which is not canonical?). The problem with the second is that there is no specified way to indicate that a particular column refers to the incident angle that might otherwise be found indatasource.measurement.instrument_settings.incident_angleIf we decide to standardise and specify the
physical_quantityvalues, then we could at least positively identify the column by thephysical_quantityattribute, and then the resolution described above could work, even if it is awkward.Just a question on "resolution", I think I know what you mean, but to be clear, do you mean resolution as in the thing which smears out the reflectivity curve, or resolution as in the order which objects are ordered when they are defined in multiple places?
To add my tuppence, on the latter I would say that column should "trump" instrument_settings since if you have gone to the effort of writing it out for every reflectivity value, you are quite likely to have had a good reason for it :)
Sorry, you're right - the word resolution is doing double duty here, as in "object resolution" (programming: find a specific thing) but also the object being resolved might be e.g. "angular resolution" (a description of the distribution of angles in a particular measurement point)
It isn't often you discuss the definition of the resolution resolution and its definition :)
It gets worse - at some point this issue will be resolved
Reacted by Andrew McCluskey
Currently we have "canonical" names for Q resolution (sQz) and the uncertainty in R (sR), but it is awkward to apply these to "wavelength" and "incident_angle", resulting in
Also, we probably need to include whatever we decide on in the header - right now there is no attribute specified for wavelength or incident angle resolution.