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

Tue Oct 18 15:33:20 BST 2016

Dear Andreas,

We call it the "NeXus NXmx application definition".  The intention is to
support a wide range of NeXus files for MX.  You are welcome to use that
label for files that comply.  If you find that too narrow, I would suggest
"NeXus NXmx application definition with Dectris Eiger extensions".  We'll
be happy to work with you to clarify things.  I would suggest participating
in the NeXus telco's that will be coming up as we talk through any further
clarifications and adjustments in making NXmx 1.5 and NXtransformations 1.1
final.

Regards,
    Herbert

On Tue, Oct 18, 2016 at 4:20 PM, Andreas Förster <
andreas.foerster at dectris.com> wrote:

> Dear Herbert,
>
> thank you for simplifying the description of the sample transformation
> axes.  We'll modify the EIGER firmware accordingly in due time.
>
> Is my understanding correct that the description is sufficiently general
> and broad as to cover data coming from a variety of detectors?  In that
> case, could this format, even informally, not to be referred to as EIGER
> format?  The impression that we're imposing something on the community is
> not only wrong but also counterproductive.
>
> Thank you and all best.
>
>
> Andreas
>
>
>
> On Fri, Oct 14, 2016 at 3:17 PM, Herbert J. Bernstein <yayahjb at gmail.com>
> wrote:
>
>> I have now added a revised NXtransformations 1.1 proposal in the
>> NXmx_multimodule_and_dectris_changes branch and have posted it to the
>> hdrmx.medsbio.org.  The major changes are:
>>
>>   1.  The formerly proposed AXISNAME_range has been removed from the
>> proposal as duplicative of AXISNAME_end, and the proposed
>> AXISNAME_average_range has been changed to AXISNAME_increment_set to
>> conform better to NeXus conventions.
>>
>>   2.  The proposed transformation type 'general' has been replaced by
>> simply not providing a transformation_type omitting that attribute.
>>
>> The new proposals for both NXmx and NXtransformations can be seen at:
>>
>> http://hdrmx.medsbio.org/NIAC_2016/manual2/build/html/classe
>> s/applications/NXmx.html?highlight=nxmx
>>
>> and
>>
>> http://hdrmx.medsbio.org/NIAC_2016/manual3/build/html/classe
>> s/base_classes/NXtransformations.html?highlight=nxtransformations
>>
>>  -- HJB
>>
>>
>> On Fri, Oct 14, 2016 at 10:34 AM, Herbert J. Bernstein <yayahjb at gmail.com
>> > wrote:
>>
>>> 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.
>>>>
>>>>
>>>
>>
>
>
> --
> <https://www.dectris.com>
> Andreas Förster, Ph.D.
> MX Application Scientist, Scientific Sales
> Phone: +41 56 500 2100 | Direct: +41 56 500 2176 | Email: andreas.
> foerster at dectris.com
> DECTRIS Ltd. | Taefernweg 1 | 5405 Baden-Daettwil | Switzerland |
> www.dectris.com
>
> [image: LinkedIn] <https://www.linkedin.com/company/5067919>
>  [image: facebook]
> <https://www.facebook.com/pages/Dectris-Ltd/623855944369304>
> <https://twitter.com/DECTRIS_News>
>
>
>
>
>
> Confidentiality Note: This message is intended only for the use of the
> named
> recipient(s) and may contain confidential and/or privileged information. If
> you
> are not the intended recipient, please contact the sender and delete the
> message.
> Any unauthorized use of the information contained in this message is
> prohibited.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20161018/dc2c89c5/attachment-0001.html>