This section describes how NeXus structures are mapped to features of the underlying physical file format. This is a guide for people who wish to create NeXus files without using the NeXus-API.
At its beginnings, the founders of NeXus identified the Hierarchical Data Format (HDF) as a capable and efficient multi-platform data storage format. HDF was designed for large data sets and already had a substantial user community. HDF was developed and maintained initially by the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign (UIUC) and later spun off into its own group called The HDF Group (THG: http://www.hdfgroup.org/). Rather then developing its own unique physical file format, the NeXus group choose to build NeXus on top of HDF.
HDF (now HDF5) is provided with software to read and write data (this is the application-programmer interface, or API) using a large number of computing systems in common use for neutron and X-ray science. HDF is a binary data file format that supports compression and structured data.
NeXus data structures map directly to HDF structures. NeXus groups are HDF4 vgroups or HDF5 groups, NeXus data sets (or fields) are HDF4 SDS (scientific data sets) or HDF5 datasets. Attributes map directly to HDF group or dataset attributes.
The only special case is the NeXus class name. HDF4 supports a group class which is set with the Vsetclass() call and read with VGetclass(). HDF-5 has no group class. Thus the NeXus class is stored as an attribute to the HDF-5 group with the name NX_class and value of the NeXus class name.
A NeXus link directly maps to the HDF linking mechanisms.
Note
Examples are provided in the Examples of writing and reading NeXus data files chapter. These examples include software to write and read NeXus data files using the NAPI, as well as other software examples that use native (non-NAPI) libraries. In some cases the examples show the content of the NeXus data files that are produced. Here are links to some of the examples:
Perhaps the easiest way to view the implementation of NeXus in HDF5 is to view how the data structures look. For this, we use the h5dump command-line utility provided with the HDF5 support libraries. Short examples are provided for the basic NeXus data components:
group: created in C NAPI by:
NXmakegroup (fileID, "entry", "NXentry");
field: created in C NAPI by:
NXmakedata (fileID, "two_theta", NX_FLOAT32, 1, &n);
NXopendata (fileID, "two_theta");
NXputdata (fileID, tth);
attribute: created in C NAPI by:
NXputattr (fileID, "units", "degrees", 7, NX_CHAR);
link created in C NAPI by:
# --tba--
# TODO: write some text about HDF5 hard links
# until then, see the h5dump example below
See the sections NAPI Simple 2-D Write Example (C, F77, F90) and NAPI Python Simple 3-D Write Example in the Examples of writing and reading NeXus data files chapter for examples that use the native HDF5 calls to write NeXus data files.
h5dump of a NeXus NXentry group
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | GROUP "entry" {
ATTRIBUTE "NX_class" {
DATATYPE H5T_STRING {
STRSIZE 7;
STRPAD H5T_STR_NULLPAD;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
DATA {
(0): "NXentry"
}
}
# ... group contents
}
|
h5dump of a NeXus field (HDF5 dataset)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | DATASET "two_theta" {
DATATYPE H5T_IEEE_F64LE
DATASPACE SIMPLE { ( 31 ) / ( 31 ) }
DATA {
(0): 17.9261, 17.9259, 17.9258, 17.9256, 17.9254, 17.9252,
(6): 17.9251, 17.9249, 17.9247, 17.9246, 17.9244, 17.9243,
(12): 17.9241, 17.9239, 17.9237, 17.9236, 17.9234, 17.9232,
(18): 17.9231, 17.9229, 17.9228, 17.9226, 17.9224, 17.9222,
(24): 17.9221, 17.9219, 17.9217, 17.9216, 17.9214, 17.9213,
(30): 17.9211
}
ATTRIBUTE "units" {
DATATYPE H5T_STRING {
STRSIZE 7;
STRPAD H5T_STR_NULLPAD;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
DATA {
(0): "degrees"
}
}
# ... other attributes
}
|
h5dump of a NeXus attribute
1 2 3 4 5 6 7 8 9 10 11 12 | ATTRIBUTE "axes" {
DATATYPE H5T_STRING {
STRSIZE 9;
STRPAD H5T_STR_NULLPAD;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
DATA {
(0): "two_theta"
}
}
|
h5dump of a NeXus link
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | # NeXus links have two parts in HDF5 files.
# The dataset is created in some group.
# A "target" attribute is added to indicate the HDF5 path to this dataset.
ATTRIBUTE "target" {
DATATYPE H5T_STRING {
STRSIZE 21;
STRPAD H5T_STR_NULLPAD;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
DATA {
(0): "/entry/data/two_theta"
}
}
# then, the hard link is created that refers to the original dataset
# (Since the name is "two_theta" in this example, it is understood that
# this link is created in a different HDF5 group than "/entry/data".)
DATASET "two_theta" {
HARDLINK "/entry/data/two_theta"
}
|
This takes a bit more work than HDF. At the root of NeXus XML file is a XML element with the name NXroot. Further XML attributes to NXroot define the NeXus file level attributes. An example NeXus XML data file is provided in the NeXus Introduction chapter as Example A very simple NeXus Data file (in XML).
NeXus groups are encoded into XML as elements with the name of the NeXus class and an XML attribute name which defines the NeXus name of the group. Further group attributes become XML attributes. An example:
NeXus group element in XML
1 2 | <NXentry name="entry">
</NXentry>
|
NeXus data sets are encoded as XML elements with the name of the data. An attribute NAPItype defines the type and dimensions of the data. The actual data is stored as PCDATA [1] in the element. Another example:
| [1] | PCDATA is the XML term for parsed character data (see: http://www.w3schools.com/xml/xml_cdata.asp). |
NeXus data elements
1 2 3 4 5 6 | <mode NAPItype="NX_CHAR[7]">
monitor
</mode>
<counts NAPItype="NX_INT32[4]">
21 456 127876 319
</counts>
|
Data are printed in appropriate formats and in C storage order. The codes understood for NAPItype are all the NeXus data type names. The dimensions are given in square brackets as a comma separated list. No dimensions need to be given if the data is just a single value. Data attributes are represented as XML attributes. If the attribute is not a text string, then the attribute is given in the form: type:value, for example: signal="NX_POSINT:1".
NeXus links are stored in XML as XML elements with the name NAPIlink and a XML attribute target which stores the path to the linked entity in the file. If the item is linked under a different name, then this name is specified as a XML attribute name to the element NAPIlink.
The authors of the NeXus API worked with the author of the miniXML XML library to create a reasonably efficient way of handling numeric data with XML. Using the NeXus API handling something like 400 detectors versus 2000 time channels in XML is not a problem. But you may hit limits with XML as the file format when data becomes to large or you try to process NeXus XML files with general XML tools. General XML tools are normally ill prepared to process large amounts of numbers.
NeXus makes use of some special attributes for its internal purposes. These attributes are stored as normal group or data set attributes in the respective file format. These are:
The napimount attribute is used to implement external linking in NeXus. The string is a URL to the file and group in the external file to link too. The system is meant to be extended. But as of now, the only format supported is:
nxfile://path-to-file#path-infile
This is a NeXus file in the file system at path-to-file and the group path-infile in that NeXus file.