[NeXus-tech] NeXus additions for CIF mapping

Tobias.Richter at diamond.ac.uk Tobias.Richter at diamond.ac.uk
Tue Sep 17 10:19:27 BST 2013


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

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 






More information about the NeXus-tech mailing list