[NeXus-committee] Updated concordance issues

[Mark Koennecke]

Hi,

as promised, a new summary of the CBF concordance issues updated with 
the results
from yesterdays teleconference. We are not finished: some things still 
need to be
discussed, you may choose to disagree with what we agreed upon at the Telco.

Best Regards,

               Mark Koennecke


Concordance Summary
--------------------

May, 23, 2013, Mark Koennecke

This document summarizes the problems occurring when mapping CBF to
NeXus how I see them from the discussion with Herbert. In the following
discussion all groups which are not NeXus yet will be prefixed with
TBD for To Be Discussed. This is the version updated after the May, 22
teleconference.


The Variant Issue
----------------------

CBF has the concept of variants for fields. For example there is
a field beam_center_x. This has somehow been determined and written
to file. Later this is refined in another way. CBF stores this then
as beam_center_x_variant. This concept of variants is missing in NeXus.
Another way to understand this is to see it as a version control for
values. However, as this is rarely used, a complicated solution is not
desirable.

So far there are three options to remedy this:

- A TBDvariant group which can occur in all other groups and
   contains the variant values with the same field names as in the
   parent group.
- Simply append _variant to the existing NeXus name. If there is more
   then one variant append another qualifier to _variant. For example:
   beam_center_x_variant_refined
- As the request can rather be understood as  a means to keep track of old
   versions of values, another option is this rule: When updating a value,
   update the value with the NeXus name. Store the old value in a new field
   labelled with nexusname_old_timestamp. Where nexusname is the original
   name of the filed, for example beam_center_x, and timestamp is a: 
timestamp
   like 2013-05-23. At the Telco, this was the preferred solution.



The Axisset Issue
--------------------

NeXus chooses to document axis names with a predefined meanings. The
CBF people learned that this did not work for them as people were using
axes differently, could not be bothered to even look which conventions
others used etc. Thus they choose rather to document axes by the
way how they operate. And a given component may even have more then
one axes description associated with it.

NeXus goes a long way to support this with the recently added offset, type,
vector and depends_on attributes.

But mapping the full CBF scheme would require a TBDaxisset group which can
occur in any component which we care to place (sample, detector,...) This
group could look like this:

TBDaxisset
    axis-name-or-id[NA]
    offset[3,NA]
    type[NA]
    vector[3,NA]
    depends_on[NA]

with NA being the number of axes.

I can see that such a scheme would also allow NeXus to neatly describe
a given data set in terms of different axis types: instrument coordinates,
q coordinates or whatever.

At the Telco the agreement was that the current NeXus scheme is sufficient
to do the CBF mapping. But for further use, it might be a good idea to
reserve the namespace for axisset. It was also felt that there to many
ways to describe axes in NeXus and we should discuss and aggree on a
preferred way to do axes in an upcoming NIAC meeting.


The Scan Issue
------------------

NeXus chooses to store scans as it is done, with the positions of components
as read from the hardware in arrays. CBF chooses to rather store the intent
of the scan: i.e. the axis moved, their start and increments etc. NeXus
lacks such a intent description. This already caused us problems because 
the
intent axes are nice for plotting and the actual positions as read are
necessary for detailed DA.

Thus to capture the CBF description a new group may be required:

TBDscan_intent
    axis-name-or-id[NSA]
    start[NSA]
    increment[NSA]
    NP

with NSA being the Number of Scan Axes and NP the number of points in
the scan. May be some more fields.

The agreement on the NeXus Telco was that the recently aggreed upon
axes scheme with the attributes on the NX group is sufficient to do
the CBF mapping. Again, it might be worth to reserve the namespace.

New Fields
--------------

This may be a bit easier: the CBF mapping asks for a couple of fields to
be added to the NeXus base classes:


NXxray_tube
    radiation_type
    radiation_xray_symbol

Radiation_type is different to probe. Probe gives a very general 
description
like neutrons, x-ray etc.  This gives the type of radiation like Cu Kalpha,
Mo etc. The situation is further complicated by the fact that even at
synchrotrons wavelengths are selected which match the characteristics of
well known x-ray tube anode materials. Thus, a NXxray_tube group may not
be the appropriate place.


NXcollimator

    div_x_y_source
    radiation_filter_edge    # May belong into a NXfilter
    radiation_inhomegeneity  # May belong into NXsource or NXmonochromator



CBF stores polarisation information of the beam in NXmonochromator.
It is an open question where this belongs: NXbeam, NXpolariser or
NXmonochromator being candidates. The fields:

polarisation_norm
polarisation_ratio
polarisation_source_norm
polarisation_source_ratio

NXdetector
   gain
   gain_esd
   linerarity
   offset
   scaling
   overload
   undefined_value

Some of these fields address the computed data value issue which we
discussed some time ago. The last state on this was that Armando was
to make a proposal for calculated data. Which, as far as I am aware,
did not happen.


CBF also has a structure to describe the elements of a multi component
detector. We discussed something similar recently with the DECTRIS module
. This was then added a s a non NeXus standard group. May be we need to
revise this with input from CBF?

The good news is that the proposed fields come with documentation which we
may directly copy from the CBF documents.


NXgoniometer
----------------

Consider the situaton when a sample is mounted on some sort of positioning
device: x-y tables, eulerian cradle goniometer or such. The current NeXus
convention is to store the values coming from such positioning devices in
the NXsample group.  The rationale is that their purpose is to position
the sample. Now, the suggestion is to separate such values out into a
NXgoniometer group. This unloads the sample group somewhat and makes for
a cleaner separation.  Where in the NeXus hierarchy a NXgoniometer will
be positioned is another question to be discussed: NXsample or NXinstrument
both being good candidates.