[NeXus-tech] [Fwd: Re: dimensions]
Akeroyd, FA (Freddie)
freddie.akeroyd at stfc.ac.uk
Fri Feb 20 10:15:54 GMT 2009
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
--
Scanned by iCritical.
More information about the NeXus-tech
mailing list