[Nexus] NIAC issue: Discuss mutations of the Eiger format #2

[Herbert J. Bernstein]

After discussion at NIAC, I have revised the NXmx 1.5 proposal in the
NXmx_multimodule_and_dectris_changes branch and on the hdrmx.medsbio.org
web site.  The main change was to add an enumeration of the beam profile
choices to include a rectangular option.

We also have some changes to the NXtransformations 1.1 proposal.  That is
still to be drafted in detail.

On Wed, Oct 5, 2016 at 9:42 PM, Herbert J. Bernstein <yayahjb at gmail.com>
wrote:

> In preparation for the NIAC meeting:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20161014/c4512a67/attachment.html>