[NeXus-tech] Upcoming NeXus telco

[Pete Jemian]

What about datasets that could be both a field and an axis?
I sense that we are overdesigning.

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