[NeXus-definitions-tickets] [NeXusDefinitions] #268: CIF->NeXus mapping

[NeXus Base Classes and Instrument Definitions]

#268: CIF->NeXus mapping
-------------------------+------------------------
 Reporter:  Pete Jemian  |      Owner:  Unassigned
     Type:  task         |     Status:  new
 Priority:  major        |  Milestone:  NXDL 3.2
Component:  general      |   Keywords:  CIF
-------------------------+------------------------
 as emailed from Tobias Richter, 2013-09-17
 {{{


 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

 }}}

-- 
Ticket URL: <http://trac.nexusformat.org/definitions/ticket/268>
NeXus Base Classes and Instrument Definitions <http://www.nexusformat.org/>
NeXus Base Classes and Instrument Definitions