[NeXus-tech] NeXus additions for CIF mapping

[Pete Jemian]

Tobias:

This is an important list.  I'm tempted to create a new definitions 
ticket with this as content.  We can then comment and modify and work 
against this ticket until satisfied.

Agreed?

Pete

On 9/17/2013 4:19 AM, Tobias.Richter at diamond.ac.uk wrote:
> Hi all,
>
> Below is a list of items that we think need addressing for our CIF->NeXus mapping to work. rst2pdf will make a printable version.
> The converter is fairly complete but a few things might still be coming.
>
>
> Regards,
>
> Tobias
>
>
>
> Additions/Changes required for CIF conversion
> ---------------------------------------------
>
> A faithful mapping of CIF data into NeXus requires some changes or additions to what is currently *documented*. For example the geometry decritpion is (largely) part of the official standard, but has not been put in NXDL yet. Some items are new or different, though.
>
> translation and rotation
> ========================
>
> * no particular name
> * a 'transformation_type' attribute which should be set to 'rotation' or 'translation'
> * a 'vector' attribute defining the axis to rotate around or to translate in(I assume in a right-handed direction), whose magnitude is not significant;
> * units given by the 'units' attribute;
> * an offset defining a point to be rotated around, relative to the origin of the local coordinate system (with units given by the 'offset_units' attribute, which doesn't have a natural default but can be omitted if the offset is zero and is not used here);
> * a 'depends_on' attribute with the path to the previous axis in the chain. A '.' denotes the coordinate system origin
>
> depends_on as field
> ===================
>
> Instead of NXgeometry or the like any (sensible) NXclass can carry a depends_on field to enter the chain of transformations that places that device in space.
>
> This needs a definition where on each device it's own origin lies.
>
> NXgoniometer
> ============
>
> We write an NXgoniometer group that contains the group of axes provided by a piece of equipment for which usually a single purchase order is issued. This keeps things toegther that scientists think of as one unit.
> Not much would be lost if we used an NXcollection instead though.
>
> In fact our NXdetector carries a set of transformations in an NXcollection (named "axes" currently - which isn't nice).
>
> NXdetector added scaling_factor
> ===============================
>
> As far as I could see scaling_factor was only defined inside NXdata.
> It should (with offset) be also in NXdetector.
>
> NXdetector documentation
> ========================
>
> CIF has:
>
> diffrn_detector.type 'ADSC QUANTUM315'
> we currently map it to NXdetector/description
>
> diffrn_detector.details 'slow mode'
> we currently map it to NXdetector/details (which is new)
>
> diffrn_detector.detector 'pixel array'
> we currently map it to NXdetector/type
>
> NXcollimator
> ============
>
> Jonathan currently maps to this, but from the documentation this looks like a false friend in the translation as
> NXcollimator appears to be neutron only. What is the last status of http://wiki.nexusformat.org/NXaperture_and_Slits ?
>
> new (canSAS-style) axes
> =======================
>
> We use @axes, @signal and @<axisdataset>_indices on NXdata as presented to NIAC in 2012.
>
> polarisation
> ============
>
> The current array indices for recording polarisation is wrong. The scheme to record polarisation could be more precise.
> We now write:
>
> /entry/sample/beam/incident_polarisation_stokes
>
> The _stokes could be implied by the dataset being 4 long.
>
> See http://en.wikipedia.org/wiki/Stokes_parameters
>