Skip to content

Commit 6cfc2d2

Browse files
Scan from tamash (#304)
* Update NXscan.yaml I just added a slight clarification what we mean under the word scan. However, it makes me wonder whether this should be more a base class than an application definition. And whether the control parameter set should be only positional. So, I have some doubts here... * rebase. * update yaml * Fix conflict. --------- Co-authored-by: T. Haraszti <haraszti@dwi.rwth-aachen.de>
1 parent 1f460cd commit 6cfc2d2

File tree

2 files changed

+199
-177
lines changed

2 files changed

+199
-177
lines changed

applications/NXscan.nxdl.xml

Lines changed: 91 additions & 83 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<?xml version="1.0" encoding="UTF-8"?>
2-
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl" ?>
2+
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
33
<!--
44
# NeXus - Neutron and X-ray Common Data Format
55
#
@@ -21,90 +21,98 @@
2121
#
2222
# For further information, see http://www.nexusformat.org
2323
-->
24-
<definition name="NXscan" extends="NXobject" type="group"
25-
category="application"
26-
xmlns="http://definition.nexusformat.org/nxdl/3.1"
27-
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
28-
xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd"
29-
>
24+
<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXscan" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
3025
<symbols>
31-
<doc>
32-
The symbol(s) listed here will be used below to coordinate datasets with the same shape.
33-
</doc>
34-
<symbol name="nP">
35-
<doc>Number of points</doc>
36-
</symbol>
37-
<symbol name="xDim">
38-
<doc>xDim description</doc>
39-
</symbol>
40-
<symbol name="yDim">
41-
<doc>yDim description</doc>
42-
</symbol>
26+
<doc>
27+
The symbol(s) listed here will be used below to coordinate datasets
28+
with the same shape.
29+
</doc>
30+
<symbol name="nP">
31+
<doc>
32+
Number of points
33+
</doc>
34+
</symbol>
35+
<symbol name="xDim">
36+
<doc>
37+
xDim description
38+
</doc>
39+
</symbol>
40+
<symbol name="yDim">
41+
<doc>
42+
yDim description
43+
</doc>
44+
</symbol>
4345
</symbols>
44-
<doc>
45-
Application definition for a generic scan instrument.
46-
47-
This definition is more an
48-
example then a stringent definition as the content of a given NeXus scan file needs to
49-
differ for different types of scans. This example definition shows a scan like done
50-
on a rotation camera: the sample is rotated and a detector image, the rotation angle
51-
and a monitor value is stored at each step in the scan. In the following, the symbol
52-
``NP`` is used to represent the number of scan points. These are the rules for
53-
storing scan data in NeXus files which are implemented in this example:
54-
55-
* Each value varied throughout a scan is stored as an array of
56-
length ``NP`` at its respective location within the NeXus hierarchy.
57-
* For area detectors, ``NP`` is the first dimension,
58-
example for a detector of 256x256: ``data[NP,256,256]``
59-
* The NXdata group contains links to all variables varied in the scan and the data.
60-
This to give an equivalent to the more familiar classical tabular representation of scans.
61-
62-
These rules exist for a reason: HDF allows the first dimension of a data set to be
63-
unlimited. This means the data can be appended too. Thus a NeXus file built according
64-
to the rules given above can be used in the following way:
65-
66-
* At the start of a scan, write all the static information.
67-
* At each scan point, append new data from varied variables
68-
and the detector to the file.
69-
</doc>
70-
<group type="NXentry">
71-
<field name="title"/>
72-
<field name="start_time" type="NX_DATE_TIME"/>
73-
<field name="end_time" type="NX_DATE_TIME"/>
74-
<field name="definition" type="NX_CHAR">
75-
<doc> Official NeXus NXDL schema to which this file conforms </doc>
76-
<enumeration>
77-
<item value="NXscan"/>
78-
</enumeration>
79-
</field>
80-
<group type="NXinstrument">
81-
<group type="NXdetector">
82-
<field name="data" type="NX_INT" signal="1">
83-
<dimensions rank="3">
84-
<dim index="1" value="nP" />
85-
<dim index="2" value="xDim" />
86-
<dim index="3" value="yDim" />
87-
</dimensions>
46+
<doc>
47+
Application definition for a generic scan instrument.
48+
49+
Repetitive measurements when varying a control parameter in a given range are called
50+
scans. This application definition is designed as an envelop to describe such measurements
51+
allowing for a generic definition of the scanned control parameter and the recorded data.
52+
53+
This definition is more an example then a stringent definition as the content of a given
54+
NeXus scan file needs to differ for different types of scans. This example definition
55+
shows a scan like done on a rotation camera: the sample is rotated and a detector image,
56+
the rotation angle and a monitor value is stored at each step in the scan. In the following,
57+
the symbol ``NP`` is used to represent the number of scan points. These are the rules for
58+
storing scan data in NeXus files which are implemented in this example:
59+
60+
* Each value varied throughout a scan is stored as an array of
61+
length ``NP`` at its respective location within the NeXus hierarchy.
62+
* For area detectors, ``NP`` is the first dimension,
63+
example for a detector of 256x256: ``data[NP,256,256]``
64+
* The NXdata group contains links to all variables varied in the scan and the data.
65+
This to give an equivalent to the more familiar classical tabular representation of scans.
66+
67+
These rules exist for a reason: HDF allows the first dimension of a data set to be
68+
unlimited. This means the data can be appended to. Thus a NeXus file built according
69+
to the rules given above can be used in the following way:
70+
71+
* At the start of a scan, write all the static information.
72+
* At each scan point, append new data from varied variables and the detector to the file.
73+
</doc>
74+
<group type="NXentry">
75+
<field name="title"/>
76+
<field name="start_time" type="NX_DATE_TIME"/>
77+
<field name="end_time" type="NX_DATE_TIME"/>
78+
<field name="definition" type="NX_CHAR">
79+
<doc>
80+
Official NeXus NXDL schema to which this file conforms
81+
</doc>
82+
<enumeration>
83+
<item value="NXscan"/>
84+
</enumeration>
8885
</field>
89-
</group>
86+
<group type="NXinstrument">
87+
<group type="NXdetector">
88+
<!--here we consider the raw data on the detector, which is always integer
89+
obtained by the Analog to Digital Converter (ADC)-->
90+
<field name="data" type="NX_INT" signal="1">
91+
<dimensions rank="3">
92+
<dim index="1" value="nP"/>
93+
<dim index="2" value="xDim"/>
94+
<dim index="3" value="yDim"/>
95+
</dimensions>
96+
</field>
97+
</group>
98+
</group>
99+
<group type="NXsample">
100+
<field name="rotation_angle" type="NX_FLOAT" axis="1">
101+
<dimensions rank="1">
102+
<dim index="1" value="nP"/>
103+
</dimensions>
104+
</field>
105+
</group>
106+
<group type="NXmonitor">
107+
<field name="data" type="NX_INT">
108+
<dimensions rank="1">
109+
<dim index="1" value="nP"/>
110+
</dimensions>
111+
</field>
112+
</group>
113+
<group type="NXdata">
114+
<link name="data" target="/NXentry/NXinstrument/NXdetector/data"/>
115+
<link name="rotation_angle" target="/NXentry/NXsample/rotation_angle"/>
116+
</group>
90117
</group>
91-
<group type="NXsample">
92-
<field name="rotation_angle" type="NX_FLOAT" axis="1">
93-
<dimensions rank="1">
94-
<dim index="1" value="nP" />
95-
</dimensions>
96-
</field>
97-
</group>
98-
<group type="NXmonitor">
99-
<field name="data" type="NX_INT">
100-
<dimensions rank="1">
101-
<dim index="1" value="nP"/>
102-
</dimensions>
103-
</field>
104-
</group>
105-
<group type="NXdata">
106-
<link name="data" target="/NXentry/NXinstrument/NXdetector/data"></link>
107-
<link name="rotation_angle" target="/NXentry/NXsample/rotation_angle"></link>
108-
</group>
109-
</group>
110118
</definition>

0 commit comments

Comments
 (0)