[NeXus-tech] Upcoming NeXus telco

[Mark Koennecke]

Pete,

On 01/23/2014 04:07 PM, Pete Jemian wrote:
> What about datasets that could be both a field and an axis?
> I sense that we are overdesigning.
>
Feels not an issue to me. Axis is like field but axis make the offset, 
transformation_type, vector and
depends_on attribute necessary.  The point is to have those attributes 
mandatory and validatable in
an application definition.

Suggestions?

Regards,

Mark
> On 1/23/2014 7:47 AM, freddie.akeroyd at stfc.ac.uk wrote:
>> Hi,
>>
>> Sorry, I have a meeting clash so cannot make the telco. To answer the 
>> question against me:
>>
>> Nexus fields currently all have a type <xs:complexType 
>> name="fieldType">   which is used to validate units attributes etc. 
>> if they are present
>>
>> I believe the question here was whether we could designate a field as 
>> being an "axis" type and hence having a different set of required 
>> attributes.
>>
>> If we defined a complex type "axisType" in xsd when we can certainly 
>> set up this validation, we then just need to specify that a field in 
>> NXDL is "axisType" and not "fieldType"
>>
>> The easiest way to do this from the xsd schema point of view would be 
>> to use something like:
>>
>> <axis name="whatever">   rather than <field name="whatever">
>>
>> in the NXDL to indicate an axis field. Doing
>>
>> <field type="axis" name="whatever">
>>
>> is more awkward - it might be possible to check at runtime with 
>> nxvalidate/schematron, but when editing the NXDL with an xml aware 
>> editior I'm not sure you can change the validation rules based on the 
>> content of the type attribute.
>>
>> Regards,
>>
>> Freddie
>>
>>
>>> -----Original Message-----
>>> From: nexus-tech-bounces at nexusformat.org [mailto:nexus-tech-
>>> bounces at nexusformat.org] On Behalf Of Mark Koennecke
>>> Sent: 23 January 2014 12:45
>>> To: NeXus Technical sub-committee list
>>> Subject: [NeXus-tech] Upcoming NeXus telco
>>>
>>> Hi,
>>>
>>> In preparation of the upcoming Telco I send the summary of the last one
>>> again, as a
>>> reference.
>>>
>>> Hear you soon,
>>>
>>>          Mark
>>> ============================
>>> NeXus Telco Week 51/2013
>>> ============================
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> NeXus-tech mailing list
>>> NeXus-tech at nexusformat.org
>>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech