nexusformat / NIAC

Issue for the NIAC to discuss (no code)
2 stars 0 forks source link

Discuss mutations of the Eiger format #2

Closed zjttoefs closed 6 years ago

zjttoefs commented 8 years ago

Report from Dectris, plus other changes that are proposed for NXmx

yayahjb commented 7 years ago

I have created a branch, NXmx_multimodule_and_dectris_changes, with a draft of the proposed changes to NXmx and NXtransformations. You can see the nxdl files in that branch on github. You can see the definitions at:

http://hdrmx.medsbio.org/NIAC_2016/manual/build/html/classes/applications/NXmx.html?highlight=nxmx

and

http://hdrmx.medsbio.org/NIAC_2016/manual/build/html/classes/base_classes/NXtransformations.html?highlight=nxtransformations

and the blank-suppressed differences at

http://hdrmx.medsbio.org/NIAC_2016/NXmx.diff

and

http://hdrmx.medsbio.org/NIAC_2016/NXtransformations.diff

The rationale for the proposed changes is as follows:

  1. NXmx changes 1.1. Version number updated from 1.4 to 1.5 -- to help software packages in distinguishing files made to conform to the changed version. 1.2. Add documentation of the possibility of a third image dimension. This case arises for the CSPAD and helps to organize data arrays to correspond to the module structure of multi-module detectors. The main change was to add a variable dataRank to carry a rank of either 2 or 3 and to add an optional index k after i and j. 1.3. Add explicit, but optional use of the NXdetector_group base class for the case of a detector in which each module has its own data array, rather than the case being considered in 1.2, above. In this case the relationship among multiple the relationships among multiple NXdetector groups needs to be stated. This was, of course, already an implicit option under NXmx 1.4, but now we are making the possibility explicit, with documentation that comes closer to the descriptions used with CBF for the same situation. Note that CBF calls a NXdetector_group a detector and an NXdetector a detector element, and deal an NXdetector_module using and array_structure_list_section. 1.4. Add additional documentation in the NXmx use of NXdetector_module and add an optional data_stride field in the NXmx use of NXdetector_module for completeness. 1.5. Add optional new total_flux, incident_beam_size, and profile in the NXmx use of NXbeam. These are needed to provide a place to put information crystallographers record
  2. NXtransformations changes 2.1. Version number updated from 1.0 to 1.1 -- to help software packages in distinguishing files made to conform to the changed version. 2.2. To help people understand the distinctions among axis types and what information they need to provide, add an explicit general axis type, for such things as the direction of gravity or other special reference coordinate axes they need to track but probably don't move, change from the upercase pseudovariable TRANSFORMATION to AXISNAME (making it consistent with NXDATA) and make an new upper case pseudovariable AXISUNITS to help explain the units they need to provide for rotation and translation axes. 2.3. Add new AXISNAME_end, AXISNAME_range and AXISNAME_average_range fields to hold information on the scan steps taken in crystallographic experiments. These are also needed to provide a place to put information crystallographers record.
zjttoefs commented 6 years ago

This has been discussed and progress is tracked in the definitions repo, if I am not mistaken.