[NeXus-tech] NeXus additions for CIF mapping

Tue Sep 17 15:01:35 BST 2013

Summary of the discussions in the telco:

translation and rotation / depends_on as field
--------------------------------------------------------------
Some documentation exists, Freddie and Pete will make a start on NXDL. We will decide if that is the preferred method and any deprecation of alternatives, once the documentation is done.

NXgoniometer as container for transformations
----------------------------------------------------------------
Accepted, should be drafted and voted on.

offset and scaling_factor in NXdetetcor
----------------------------------------------------
Should be added for correctness/consistency

details in NXdetector
-----------------------------
Use in CIF converter okay. No need to ratify.

NXcollimator
------------------
Converter should use proposed NXslit and NXpinhole. We need to establish a placement in coordinate system with respect to an NXbeam or other component using depends_on.

Axes and Polarisation
-----------------------------
Not discussed due to lack of time.

________________________________________
From: nexus-tech-bounces at nexusformat.org [nexus-tech-bounces at nexusformat.org] on behalf of Tobias.Richter at diamond.ac.uk [Tobias.Richter at diamond.ac.uk]
Sent: 17 September 2013 10:19
To: nexus-tech at nexusformat.org
Subject: [NeXus-tech] NeXus additions for CIF mapping

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

_______________________________________________
NeXus-tech mailing list
NeXus-tech at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-tech

-- 
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