[NeXus-tech] [Fwd: Re: dimensions]
Mark Koennecke
Mark.Koennecke at psi.ch
Fri Feb 20 16:20:41 GMT 2009
Hi,
I think the dimensions encoding is tightly integrated with the algorithm we
use to validate them later on. I thought about something like:
<dimensions size="3">
<dim level="0" value="25"/>
<dim level="1" value="np"/>
<dim level="2" path="/entry/blablabla/somefield" dim="0"/>
</dimensions>
The first case is trivial: validate against a number
The general idea is that the dimensions validator would initialise np
the first place it comes up against it and
checks against the value ever after. We must allow expressions like np+1
here.
The third syntax is to explicitly address a specific dimension of
another variable.
Mark
Akeroyd, FA (Freddie) wrote:
> Hi,
>
> I think we have three cases to consider here:
> (1) specifying an explicit value for a dimension
> (2) specifying a dimension to be the same size as that of an array
> already defined elsewhere (optionally +- a value)
> (3) specifying a dimension to be the same as a data value defined
> elsewhere (e.g. num_scan_points, optionally +- a value)
>
> For (1) how about
>
> <dim index="1" value="3" />
>
> For (2) how about
>
> <field name="data">
> <dimensions size="3">
> <dim index="1" label="num_time_channels"/>
> <!-- dimensions with no constraints or labels do not
> need to be mentioned -->
> </dimensions>
> </field>
> <field name="time_of_flight">
> <dimensions size="1">
> <dim index="1" ref="num_time_channels" incr="1"/>
> </dimensions>
> ...
> </field>
>
> For (3) how about
>
> <field name="num_scan_points" type="NX_INT"
> label="nscanpt" />
> <field name="data">
> <dimensions size="3">
> <dim index="1" label="num_time_channels"/>
> <dim index="3" ref="nscanpt"/>
> </dimensions>
> </field>
>
> Notes on dim tag:
>
> use 1 for first element in a sequence, +- to indicate sequence direction
> (or we could use an attribute instead)
>
> <dim index="1"> ! refers to first index (fastest varying)
> <dim index="-1"> ! refers to last index (slowest varying)
>
> <dim label="i"> ! we should constrain labels to be unique within the
> file and thus could be referred to
> from any location. This would mean that "i"
> could not be used everywhere as a label,
> but forcing the use of better names like
> "num_time_channels" makes things clearer. In the
> first instance by making label an xs:ID and
> ref an xs:IDREF we can enforce "something" in
> label="something" to always be unique and "some_ref" in ref="some_ref"
> to always point to a
> valid "label" (We may later want to use xs:key
> / xs:keyref to do this if we needed a second
> set of unique labels for another purpose)
>
> Regards,
>
> Freddie
>
>
>> -----Original Message-----
>> From: nexus-tech-bounces at nexusformat.org [mailto:nexus-tech-
>> bounces at nexusformat.org] On Behalf Of Peterson, Peter F. (pf9)
>> Sent: 19 February 2009 20:03
>> To: Pete Jemian
>> Cc: NeXus Technical sub-committee list
>> Subject: Re: [NeXus-tech] [Fwd: Re: dimensions]
>>
>> Pete,
>>
>> There are a couple of things that will make this easier. Leaving off
>> the
>> indices that aren't being linked/specified (what you have as a ':' in
>> the
>> example) would be clearer (I think). Otherwise we should come up with
>>
> a
>
>> different tag/attribute that makes the meaning of the ':' clearer. The
>> other
>> thing that will make dimensions clearer/cleaner is to get inheritance
>> like
>> what Mark has suggested so the rank of the data is fixed. TOFRAW is
>> hideous
>> because of these two issues. Are we nearing a stage where inheritance
>> makes
>> sense.
>>
>> P^2
>>
>>
>> On 2/19/09 2:53 PM, "Pete Jemian" <prjemian at gmail.com> wrote:
>>
>>
>>> perhaps:
>>> ---------------------------------% clip here
>>> %---------------------------------
>>> <field name="final_wavelength" type="NX_FLOAT"
>>>
> units="NX_LENGTH">
>
>>> <doc>Wavelength on leaving beamline component</doc>
>>> <dimensions size="1">
>>> <dim index="1">:</dim>
>>> </dimensions>
>>> </field>
>>> <field name="final_beam_divergence" type="NX_FLOAT"
>>>
>> units="NX_ANGLE">
>>
>>> <doc>Divergence FWHM of beam leaving this component</doc>
>>> <dimensions size="2"><!-- [2,:] -->
>>> <dim index="1">2</dim>
>>> <dim index="2">:</dim>
>>> </dimensions>
>>> </field>
>>> <field name="flux" type="NX_FLOAT" units="NX_FLUX">
>>> <doc>flux incident on beam plane area</doc>
>>> <dimensions size="1">
>>> <dim index="1">i</dim>
>>> </dimensions>
>>> </field>
>>> ---------------------------------% clip here
>>> %---------------------------------
>>>
>>>
>>>
>>> Pete Jemian wrote:
>>>
>>>> Regarding the definition of dimensions, so far, so good.
>>>> Now, here is part of (revised) NXbeam.nxdl.xml:
>>>>
>>>> ---------------------------------% clip here
>>>> %---------------------------------
>>>> <field name="final_wavelength_spread" type="NX_FLOAT"
>>>>
>> units="NX_LENGTH">
>>
>>>> <doc>Wavelength spread FWHM of beam leaving this
>>>>
>> component</doc>
>>
>>>> <dimensions size="[:]" />
>>>> </field>
>>>> <field name="final_beam_divergence" type="NX_FLOAT"
>>>>
>> units="NX_ANGLE">
>>
>>>> <doc>Divergence FWHM of beam leaving this component</doc>
>>>> <dimensions size="2"><!-- [2,:] --></dimensions>
>>>> </field>
>>>> <field name="flux" type="NX_FLOAT" units="NX_FLUX">
>>>> <doc>flux incident on beam plane area</doc>
>>>> <dimensions size="i" />
>>>> </field>
>>>> ---------------------------------% clip here
>>>> %---------------------------------
>>>>
>>>> How do we handle this? (So far, it is valid by the changes in NXDL
>>>>
>> rules.)
>>
>>>> Also, we need better documentation strings than given below.
>>>>
>>>>
>>>> (Here is just the revised part of nxdl.xsd):
>>>> ---------------------------------% clip here
>>>> %---------------------------------
>>>> <xs:complexType name="dimsType">
>>>> <!--
>>>> Here is a model:
>>>> <field name="data">
>>>> <dimensions size="3"/>
>>>> ...
>>>> </field><field name="time-of-flight">
>>>> <dimensions size="1">
>>>> <dim index="1" ref="data" refindex="3"
>>>>
> incr="1"/>
>
>>>> </dimensions>
>>>> ...
>>>> </field>
>>>>
>>>> In old terms this would make data[i,j,k] and time-of-
>>>>
>> flight[k+1].
>>
>>>> We need to get to the stage where people
>>>> don't need to read a manual to understand an existing
>>>>
>> NXDL.
>>
>>>> -->
>>>> <xs:annotation>
>>>> <xs:documentation>dimensions of a data element in a
>>>>
> NeXus
>
>>>> file</xs:documentation>
>>>> </xs:annotation>
>>>> <xs:sequence>
>>>> <xs:element name="dim" minOccurs="0"
>>>>
>> maxOccurs="unbounded">
>>
>>>> <xs:complexType>
>>>> <xs:attribute name="index" type="nx:NX_CHAR">
>>>> <xs:annotation>
>>>> <xs:documentation>Number indicating
>>>>
> which
>
>>>> subscript is being referenced,
>>>> ranging from 1 up to RANK (rank of
>>>>
>> the data
>>
>>>> structure). For example,
>>>> given an array A[i,j,k], index="1"
>>>>
>> would refer
>>
>>>> to the "i" subscript.</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> <xs:attribute name="ref" type="nx:NX_CHAR">
>>>> <xs:annotation>
>>>> <xs:documentation>Name of the data
>>>>
>> structure being
>>
>>>> referenced
>>>> indirectly.</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> <xs:attribute name="refindex" type="nx:NX_CHAR">
>>>> <xs:annotation>
>>>> <xs:documentation>Index within the data
>>>>
>> structure
>>
>>>> being
>>>> referenced
>>>>
>> indirectly.</xs:documentation>
>>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> <xs:attribute name="incr" type="nx:NX_CHAR">
>>>> <xs:annotation>
>>>> <xs:documentation>What is
>>>>
>> this?</xs:documentation>
>>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:sequence>
>>>> <xs:attribute name="size" type="nx:NX_CHAR">
>>>> <xs:annotation>
>>>> <xs:documentation>Rank (number of dimensions) of the
>>>>
>> data
>>
>>>> structure.
>>>> For example: a[5] has size="1" while b[8,5,6,4]
>>>>
>> has
>>
>>>> size="4".
>>>> See
>>>> http://en.wikipedia.org/wiki/Rank_(computer_programming)
>>>> for more details.</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> </xs:complexType>
>>>> ---------------------------------% clip here
>>>> %---------------------------------
>>>>
>>>> Pete
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> NeXus-tech mailing list
>> NeXus-tech at nexusformat.org
>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>>
More information about the NeXus-tech
mailing list