[NeXus-committee] CBF Concordance Summary

[Mark Koennecke]

Hi,

here is my very own concordance summary. I know it it is late but it is 
not to long.
This represents my view, I may be missing something or got it wrong.
Please shout!

Hear you at the upcoming Telco!

                  Mark



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

May, 22, 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.


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.
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.
- Make an NXsubentry which contains links to all unchanged data items
   and gives values for the changed ones.
- Simpy 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


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 someway 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.


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.


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:

NXsource
    radiation_type
    radiation_xray_symbol


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.


The End
-----------

IMHO, these are the main issues. But I may have overlooked something.
Please read the Concordance paper, especially the first section.