[NeXus-tech] some requirements for MX application definition

[Tobias.Richter at diamond.ac.uk]

Dear all,

Below is a list of requirements for MX data that Graeme Winter prepared as expert of the relevant analysis (software).
We can discuss at the next telco. Quite a few items can be ticked off easily.
Most items I can explain in slightly more detail, but if someone has any specific problems: Graeme is happy to answer questions (cc'd).

Regards,

Tobias

================================================================================================


Basic requirements:
·         Use one single well defined coordinate frame implicitly or explicitly defined within the file – explicitly is nice as this will allow validation, but critically enough that I can determine the positional relationship between all elements taking part in the experiment.
·         Use e.g. SI (+ degrees and eV) units for the definition of displacement and rotation
·         In addition to values add the option to store the expected variance of the value e.g. if the value refines substantially beyond this value trigger a warning or error – these may be derived from analysis of historical data
·         Timestamps on all values to allow for storage of refined values maintaining access to original values (e.g. variants)

Specific minimum requirements:
·         Structure of the beam e.g. wavelength, energy dispersion, size, divergence, profile, energy spectrum (for X-FEL in particular) and direction (defined either sample to source or the reverse, but defined within the standard.)
·         All rotation axes, their composition order, those being scanned and those which are fixed, all of their settings and offsets, perhaps their derivatives if possible (i.e. “axis speed” if not constant)
·         Position, orientation and extent of the detector(s) and their mechanical relationships e.g. the structure of the detector relevant to refinement – the detector is made of 4 quadrants which are in turn constructed from 8 elements etc. This may be expressed as conventional use of axes in imgCIF.
·         Image masks for dead pixels, hot pixels, tile join regions etc. and appropriate values for these.
·         Limits on trusted pixel values e.g. above ‘X’ ignore value as overloaded.
·         Exposure time / beam attenuation or flux
·         Sample xyz translation applied
·         Sample unique ID
·         Sample group unique ID

Last two are to learn automatically from the structure of the experiment, the sample ID and the timestamps the intent of the experiment. These should not necessarily take any format but scans with the same sample ID should be from the same sample, and scans from the same sample group should be somehow related e.g. multi-crystal experiments.

Clearly these are just a starting point but should be a useful place to start the discussion.

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