[NeXus-committee] CBF Concordance Summary

[yayahjb]

Dear Mark,

   Very nicely done.  The only issue I think we may wish to add is the
old idea of having an NXgoniometer class.

   Regards,
     Herbert


On 5/22/13 5:44 AM, Mark Koennecke wrote:
> 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.
>
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>