[NeXus-tech] Telco Week 51 Summary

[Mark Koennecke]

============================
NeXus Telco Week 51/2013 Summary
============================


AXIS Type for Fields
=======================

This is about assigning a type to an SDS such that the presence of
certain attributes can be validated. The use case is the axis type
which needs to have the transformation_type, vector, offset and
depends_on attributes.

We made a little progress here. Freddie is next to sure that the 
presence of
attributes can easily be checked. He will verify this untill the next 
Telco.
Herbert suggested to make the field type explicit through a NXclass or
field_type attribute. Which seems to be a good idea.

There is also the requirement to verify the depends_on chain. It was
agreed that this can only be done in code. Herbert has something in
this direction.


PX Application Definition
===========================

The rest of the time was spent on discussing the PX application definition.
The first topic were the pose:NXcollection groups. They deviate from
the normal NeXus usage. The meaning of them is to contain a list of axes
to position the component. For PX two are needed: to position the detector
and to position the sample. There is aggreement that this information 
needs to
be stored.

If a NXcollection is the right place to store this information is a
different matter. There are options:
- Pull it down into either NXgoniometer, NXsample  or NXdetector. This 
poses
   the risk of name collisions.
- We briefly discussed to use NXgoniometer for this. Because 
NXgoniometer is
   just this: a list of axes and a depends_on field. Herbert objected
   that crystallographers use the word goniometer exclusively for the 
sample
   positioner and would be confused by finding a NXgoniometer somewhere 
else.
- As neither suggestion was satisfactory we briefly discussed creating a
   new name, perhaps NXaxis_list to cover this use case.

To be mulled over until the next teleconference.

Next we went through Tobias list of issues about the PX definition:

Axis movement during frame acquisition
    This is about an axis moving while the data for a frame is being
    collected. Two values are needed: the start and stop value of the
    movement. Obviously the information belongs at the axis moving. We
    ended with making this axis two dimensional, [NP,2] with [NP,0]
    being the start and [NP,1] being the end. Separating this into
    two fields axis_start[NP], axis_end[NP] was rejected because it
    breaks the dependency chain.
Check that arrays are not flipped or rotated
    This is about storage order of arrays. It was clarified that NeXus has
    the offset/stride attribute scheme to cover this problem. Graeme is
    going to verify that this works for him. Also see note below.
Reconstruct scan intent
    Was considerend non essential as it can be reconstructed from the
    arrays stored for a scan.
Tick of that information required by MOSFLM is present
    Considered done by Graeme
Define how NXbeam captures the full wavelength spectrum
    The problem here is that the base class is fairly fussy about this.
    We quickly aggreed (at least I think) to have the application 
definition
    use a spectrum NXdata class which contains data(counts) versus 
wavelength.
    For FEL this would be two dimensional with NP the first dimension as
    the spectrum changes with each shot.

Herbert noted that we are very close to get this done. Good!

Offset conflict
===================

Something I noted on the Telco but did not mention because I did not 
want to
open a new topic: we have a conflict about the offset attribute for fields
in NeXus. There are two meanings:
- offset is Rank values of offsets to use for each dimension if the data is
   not in C storage order. Of type NX_INT. This at design#attributes
- In the discussion on NeXus coordinate systems offset means: 3 float
   components to describe a translation to be applied before applying 
the operation
   of the real axis.
Obviously this must be resolved. Obviously (to me) is that the case for 
the first
use case of offset is weaker as it will be rarely used. Thus I suggest 
to rename it
to pixel_offset or array_offset. To be discussed.


Topics Still Pending
=======================

Variants and ESD
-------------------

Many people at the Telco liked Pete Jemians idea about specifying the
names of error fields in an attribute. Concerning variants a mix of the
different proposals was preferred. Tobias will provide an example
file with an implementation for us to look at and discuss again.


NXpinhole and NXslit
-----------------------

I think this is ready for voting in the next year.


Eugens Proposal on Non Standard Fields
-----------------------------------------

What to we do with it?


NeXus Interfaces
--------------------

Do we want this? To be discussed later in 2014 when PX is done with.



I thank everyone for the work put in in 2013 and wish you a Merry Christmas
and a Happy New Year 2014

Mark Koennecke