[NeXus-tech] SAS2012 canSAS data format presentation
Pete Jemian
jemian at anl.gov
Thu Nov 8 18:05:56 GMT 2012
On 11/8/2012 4:55 AM, Tobias.Richter at diamond.ac.uk wrote:
> When we were discussing this with the NeXus people for the more general case, they preferred @axes over @I_axes
> Is that something we want to address and change? On the technical side it makes no difference for canSAS, I believe but would offer a wider compatibility (potentially).
Sorry, long answer coming...
This change involves how multi-dimensional data is described.
The answer from the NeXus tech committee on this is not satisfying to me
but they may not have been able to see our use so clearly. I believe
our plan is superior and should not be changed so quickly as the real
benefit would be to NeXus, rather than canSAS. We should press them to
consider this better, by making a formal proposal to them and making
that proposal very clear.
Our required dataset in SASdata is "I" and we created an @I_axes
attribute to describe the components of its various axes. One could use
this same construct to describe the axes of any dataset (such as
"background" would have an associated @background_axes attribute on the
SASdata group). The NeXus Tech Committee suggested that we change the
name of this attribute to "axes" to be more consistent with current
NeXus usage.
The NeXus tech committee is interested in making changes that will not
break backward compatibility and preserve existing structures. One of
them commented "Currently we have two ways and this would be a third."
Understood. See this link for the NeXus algorithm (incorporates both
current methods) to find the plottable data:
http://download.nexusformat.org/doc/html/datarules.html#index-27
Another relevant link in the NeXus manual:
http://download.nexusformat.org/doc/html/datarules.html#linking-multi-dimensional-data-with-axis-data
I believe ours is a change that NeXus should give more consideration,
especially since it offers a solution to a problem they have.
In NeXus, there is an @axes attribute possible for any dataset. In our
plans, we move this attribute to the parent group of the dataset and we
have sound reasons for this change, involving linked datasets.
Also involved in this change is how NeXus uses the @signal attribute on
datasets. What will be hard for NeXus to adopt is the notion that they
should modify the technique they currently use to identify the principal
data to be plotted, since that will certainly mean they have three ways
to do describe the axes of multi-dimensional data. The proposed plan
for them addresses directly a known limitation in a positive and
flexible way.
Consider this example from the NeXus documentation:
data:NXdata
time_of_flight:float[250] = 1500.0 1502.0 1504.0 ...
polar_angle:float[100] = 15.0 15.6 16.2 ...
some_other_angle:float[100] = 0.0 0.0 2.0 ...
data:float[100,250] = 5 7 14 ...
@axes = polar_angle:time_of_flight
@signal = 1
Using the canSAS ideas, we would re-write this:
data:NXdata
@signal = data
@data_axes = polar_angle, time_of_flight
time_of_flight:float[250] = 1500.0 1502.0 1504.0 ...
polar_angle:float[100] = 15.0 15.6 16.2 ...
some_other_angle:float[100] = 0.0 0.0 2.0 ...
data:float[100,250] = 5 7 14 ...
Note that the name of the @axes attribute changed to @data_axes as it
moved up to the NXdata group. (One could argue changing the name of
@signal to @plot but let's leave that discussion to NeXus).
Q: Doesn't look so different so why should NeXus change?
A: When using hard links of data sets into other groups.
In HDF5, a hard link of a dataset will represent the
dataset name, its data, and its attributes in more
than one HDF5 group.
Consider a NeXus NXdata group, one of the datasets
must have the attribute @signal=1. That's a NeXus rule.
If a second dataset were to be linked into this
dataset (conceivably from another NXdata group), it
might also have the @signal=1 attribute set. This
would violate the NeXus rule since two datasets in
the same NXdata group would have the @signal=1 attribute.
We could /easily/ run into this by linking into the
same SASdata group some additional (non-required)
experimental data such as dark_frame, white_frame,
or background.
Our plan completely avoids this problem and fixes it for NeXus.
(Also, our plan assumes the SASdata group attribute @signal = I)
Thanks for hearing me out,
Pete
--
----------------------------------------------------------
Pete R. Jemian, Ph.D. <jemian at anl.gov>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source, Argonne National Laboratory
Argonne, IL 60439 630 - 252 - 3189
-----------------------------------------------------------
Education is the one thing for which people
are willing to pay yet not receive.
-----------------------------------------------------------
More information about the NeXus-tech
mailing list