Definition of axis ... in a NXdata #755
Comments
That's correct. NeXus has decided to not define whether (or not) to use log-scale. |
Your example is correct. Use the There is one thing to change with your example. It is common practice in small-angle scattering to use
The NXcanSAS definition has arrived at the use of |
|
The |
|
The |
Do you recall why this looked obsolete? The engineering Your questions here prompted me to use the index of the NeXus documentation to find |
Where is this written in the manual? |
|
And, technically, monochromatic SAXS data is not a spectrum. |
|
Ok, I see it now. That's definitive. And, Here are the references to |
|
As described in the manual, |
|
Yes Pete, it has nothing to do with what the data actually represent. It is just a convention for specifying 1D data. I recall that Mark preferred the word histogram, but finally spectrum was retained. |
|
@kif - feel free to close this issue if all your questions have been answered. |
|
On Mon, 17 Feb 2020 10:53:19 -0800 Pete R Jemian ***@***.***> wrote:
@kif - feel free to close this issue if all your questions have been answered.
Thanks Pete for all those clarifications:
To wrap up:
* @Interpretation="spectrum" should be associated to the *I* array rather than the NXdata group which contains it, even if we all agree "spectrum" is not the proper word when considering SAXS.
* There is no "official" way to specify the data or an axis should be displayed in log scale. Within the silx team, we will probably adopt one as this is needed.
* The @Units attribute should be used to specify the units used for the dataset of consideration. I miss understood the definition.
* The spelling "angstrom" should be used instead of the capital A which could lead to confusion with Ampere. I initially intended to use unicode Å (\u212B), would you consider this acceptable ?
Thanks again for the clarification. I'll close the issue in a couple of days as some colleagues may comment on this as well.
Cheers,
Jérôme
|
|
If you used the unicode Å (\u212B), you might find interchange with other software might be more difficult unless they expect this. Times are changing and unicode is more widely accepted. For me, the test is Will it be convertible using the cfunits package? That package implements UDUNITS in python. setup the conda python environment
Test various units
Since NeXus does not validate the engineering |
|
I may have misunderstood what is being suggested, but you can't store unicode directly in HDF5 files. However, you can store unicode strings as variable-length strings encoded as UTF-8 (unless a 'byte' dtype is specifically chosen, in which case I guess you can choose your own encoding - it's unwise to use other encodings since there is no way of specifying which you are using). Programs like h5py will automatically decode variable-length strings into unicode strings. These days, I don't think there is any reason NeXus fields and attributes shouldn't contain unicode strings although the documentation doesn't mention them. Å makes sense to me. |
|
I think @rayosborn has made a point that was clearly stated in NIAC 2018 and that made it into the documentation. Therefore the UTF-8 representation of the Angstrom unit is perfectly valid and in agreement with the NeXus manual: NX_CHAR |
|
Thanks for the comments |
Hi there,
If I understand well, the NXdata is intended to describe the plot (i.e. what to plot, how, ...). I need to save some SAXS data so that they can be displayed by default correctly, following the Nexus convention.
In such plot, the intensity I should be plotted in 1D vs the scattering vector q:
I found in the Nexus documentation that the x dataset in an NXdata can have an attribute @Units but it looks to be part of an obsolete definition. Would you consider this saxs NXdata as valid from a Nexus perspective ?
Some references:
silx-kit/silx#2927
The text was updated successfully, but these errors were encountered: