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

Tue Oct 18 15:20:17 BST 2016

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/
> classes/applications/NXmx.html?highlight=nxmx
>
> and
>
> http://hdrmx.medsbio.org/NIAC_2016/manual3/build/html/
> classes/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/0b1d69c8/attachment.html>