[NeXus-committee] CBF Concordance Summary
yayahjb at gmail.com
Wed May 22 13:09:37 BST 2013
Very nicely done. The only issue I think we may wish to add is the
old idea of having an NXgoniometer class.
On 5/22/13 5:44 AM, Mark Koennecke wrote:
> 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!
> 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:
> 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
> occur in any component which we care to place (sample, detector,...) This
> group could look like this:
> 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
> q coordinates or whatever.
> The Scan Issue
> NeXus chooses to store scans as it is done, with the positions of
> as read from the hardware in arrays. CBF chooses to rather store the
> 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:
> 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:
> 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:
> 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
More information about the NeXus-committee