1.1. NeXus Introduction¶
NeXus  is an effort by an international group of scientists motivated to define a common data exchange format for neutron, X-ray, and muon experiments. NeXus is built on top of the scientific data format HDF5 and adds domain-specific rules for organizing data within HDF5 files in addition to a dictionary of well-defined domain-specific field names. The NeXus data format has two purposes:
- raw data: NeXus defines a format that can serve as a container for all relevant data associated with a scientific instrument or beamline. This is a very important use case.
- processed data: NeXus defines standards in the form of application definitions for the exchange of data between applications. NeXus provides structures for raw experimental data as well as for processed data.
A community of scientists and computer programmers working in neutron and synchrotron facilities around the world came to the conclusion that a common data format would fulfill a valuable function in the scattering community. As instrumentation becomes more complex and data visualization becomes more challenging, individual scientists, or even institutions, find it difficult to keep up with new developments. A common data format makes it easier, both to exchange experimental results and to exchange ideas about how to analyze them. It promotes greater cooperation in software development and stimulates the design of more sophisticated visualization tools. Additional background information is given in the chapter titled Brief history of NeXus.
This section is designed to give a brief introduction to NeXus, the data format and tools that have been developed in response to these needs. It explains what a modern data format such as NeXus is and how to write simple programs to read and write NeXus files.
The programmers who produce intermediate files for storing analyzed data should agree on simple interchange rules.
|||J. Appl. Cryst. (2015). 48, 301-305 (https://doi.org/10.1107/S1600576714027575)|
1.1.1. What is NeXus?¶
The NeXus data format has four components:
- A set of design principles
- to help people understand what is in the data files.
- A set of data storage objects
- (Base Class Definitions and Application Definitions) to allow the development of portable analysis software.
- A set of subroutines
- (Utilities and examples) to make it easy to read and write NeXus data files.
- A Scientific Community
- to provide the scientific data, advice, and continued involvement with the NeXus standard. NeXus provides a forum for the scientific community to exchange ideas in data storage.
In addition, NeXus relies on a set of low-level file formats to actually store NeXus files on physical media. Each of these components are described in more detail in the Physical File format section.
The NeXus Application-Programmer Interface (NAPI), which provides the set of subroutines for reading and writing NeXus data files, is described briefly in NAPI: The NeXus Application Programming Interface. (Further details are provided in the NAPI chapter.)
The principles guiding the design and implementation of the NeXus standard are described in the NeXus Design chapter.
Base classes, which comprise the data storage objects used in NeXus data files, are detailed in the Base Class Definitions chapter.
Additionally, a brief list describing the set of NeXus Utilities available to browse, validate, translate, and visualise NeXus data files is provided in the NeXus Utilities chapter.
220.127.116.11. A Set of Design Principles¶
NeXus data files contain four types of entity: groups, fields, attributes, and links.
- Groups are like folders that can contain a number of fields and/or other groups.
- Fields can be scalar values or multidimensional arrays of a variety of sizes (1-byte, 2-byte, 4-byte, 8-byte) and types (characters, integers, floats). Fields are represented as HDF5 datasets.
- Extra information required to describe a particular group or field, such as the data units, can be stored as a data attribute. Attributes can also be given at the file level of an HDF5 file.
- Links are used to reference the plottable data from
NXdatawhen the data is provided in other groups such as
In fact, a NeXus file can be viewed as a computer file system. Just as files are stored in folders (or subdirectories) to make them easy to locate, so NeXus fields are stored in groups. The group hierarchy is designed to make it easy to navigate a NeXus file.
Example of a NeXus File¶
The following diagram shows an example of a NeXus data file represented as a tree structure.
Note that each field is identified by a name, such as
but each group is identified both by a name and, after a colon as a
delimiter, the class type, e.g.,
The class types, which all begin with
NX, define the sort of fields that the group should contain, in this
case, counts from a beamline monitor. The hierarchical design, with data
items nested in groups, makes it easy to identify information if you are
browsing through a file.
Here are some of the important classes found in nearly all NeXus files. A complete list can be found in the NeXus Design chapter.
is the only class required in a valid NeXus data file.
The top level of any NeXus file contains one or more groups with the
NXentry. These contain all the data that is required to describe an experimental run or scan. Each
NXentrytypically contains a number of groups describing sample information (class
NXsample), instrument details (class
NXinstrument), and monitor counts (class
NXentrygroup may contain one or more
NXdatagroups. These groups contain the experimental results in a self-contained way, i.e., it should be possible to generate a sensible plot of the data from the information contained in each
NXdatagroup. That means it should contain the axis labels and titles as well as the data.
NXentrygroup will often contain a group with class
NXsample. This group contains information pertaining to the sample, such as its chemical composition, mass, and environment variables (temperature, pressure, magnetic field, etc.).
There might also be a group with class
NXinstrument. This is designed to encapsulate all the instrumental information that might be relevant to a measurement, such as flight paths, collimation, chopper frequencies, etc.
Since an instrument can include several beamline components each defined by several parameters, the components are each specified by a separate group. This hides the complexity from generic file browsers, but makes the information available in an intuitively obvious way if it is required.
NeXus data files do not need to be complicated. In fact, the following diagram shows an extremely simple NeXus file (in fact, the simple example shows the minimum information necessary for a NeXus data file) that could be used to transfer data between programs. (Later in this section, we show how to write and read this simple example.)
This illustrates the fact that the structure of NeXus files is
extremely flexible. It can accommodate very complex instrumental
information, if required, but it can also be used to store very simple data
sets. Here is the structure of a very simple NeXus data file
Structure of a very simple NeXus Data file
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
verysimple.nx5 : NeXus data file @default = entry entry:NXentry @NX_class = NXentry @default = data data:NXdata @NX_class = NXdata @signal = counts @axes = two_theta @two_theta_indices =  counts:int32 = [1193, 4474, 53220, '...', 1000] @units = counts @long_name = two_theta (degrees) two_theta:float64 = [18.9094, 18.9096, '...', 18.9122] @units = degrees @long_name = photodiode counts
NeXus files are easy to visualize. Here, this data is plotted using NeXPy simply by opening the NeXus data file and double-clicking the file name in the list:
NeXus files are easy to create. This example NeXus file was created using a short Python program and the h5py package:
Using Python to write a very simple NeXus HDF5 Data file
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 26 27 28 29 30 31 32 33 34
#!/usr/bin/env python '''uses h5py to build the verysimple.nx5 data file''' import h5py angle = [18.9094, 18.9096, 18.9098, 18.91, 18.9102, 18.9104, 18.9106, 18.9108, 18.911, 18.9112, 18.9114, 18.9116, 18.9118, 18.912, 18.9122] diode = [1193, 4474, 53220, 274310, 515430, 827880, 1227100, 1434640, 1330280, 1037070, 598720, 316460, 56677, 1000, 1000] f = h5py.File('verysimple.nx5', 'w') f.attrs['default'] = 'entry' nxentry = f.create_group('entry') nxentry.attrs["NX_class"] = 'NXentry' nxentry.attrs['default'] = 'data' nxdata = nxentry.create_group('data') nxdata.attrs["NX_class"] = 'NXdata' nxdata.attrs['signal'] = 'counts' nxdata.attrs['axes'] = 'two_theta' nxdata.attrs['two_theta_indices'] = [0,] tth = nxdata.create_dataset('two_theta', data=angle) tth.attrs['units'] = 'degrees' tth.attrs['long_name'] = 'photodiode counts' counts = nxdata.create_dataset('counts', data=diode) counts.attrs['units'] = 'counts' counts.attrs['long_name'] = 'two_theta (degrees)' f.close()
18.104.22.168. A Set of Data Storage Objects¶
If the design principles are followed, it will be easy for anyone browsing a NeXus file to understand what it contains, without any prior information. However, if you are writing specialized visualization or analysis software, you will need to know precisely what specific information is contained in advance. For that reason, NeXus provides a way of defining the format for particular instrument types, such as time-of-flight small angle neutron scattering. This requires some agreement by the relevant communities, but enables the development of much more portable software.
The set of data storage objects is divided into three parts: base classes, application definitions, and contributed definitions. The base classes represent a set of components that define the dictionary of all possible terms to be used with that component. The application definitions specify the minimum required information to satisfy a particular scientific or data analysis software interest. The contributed definitions have been submitted by the scientific community for incubation before they are adopted by the NIAC or for availability to the community.
These instrument definitions are formalized as XML files, using NXDL, to specify the names of fields, and other NeXus data objects. The following is an example of such a file for the simple NeXus file shown above.
A very simple NeXus Definition Language (NXDL) file
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
<?xml version="1.0" ?> <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" category="base" name="verysimple" version="1.0" type="group" extends="NXobject"> <doc> A very simple NeXus NXDL file </doc> <group type="NXentry"> <group type="NXdata"> <field name="counts" type="NX_INT" units="NX_UNITLESS"> <doc>counts recorded by detector</doc> </field> <field name="two_theta" type="NX_FLOAT" units="NX_ANGLE"> <doc>rotation angle of detector arm</doc> </field> </group> </group> </definition>
Complete examples of reading and writing NeXus data files are provided later. This chapter has several examples of writing and reading NeXus data files. If you want to define the format of a particular type of NeXus file for your own use, e.g. as the standard output from a program, you are encouraged to publish the format using this XML format. An example of how to do this is shown in the Creating a NXDL Specification section.
22.214.171.124. A Set of Subroutines¶
NeXus data files are high-level so the user only needs to know how the data are referenced in the file but does not need to be concerned where the data are stored in the file. Thus, the data are most easily accessed using a subroutine library tuned to the specifics of the data format.
In the past, a data format was defined by a document describing the precise location of every item in the data file, either as row and column numbers in an ASCII file, or as record and byte numbers in a binary file. It is the job of the subroutine library to retrieve the data. This subroutine library is commonly called an application-programmer interface or API.
For example, in NeXus, a program to read in the wavelength of an experiment would contain lines similar to the following:
Simple example of reading data using the NeXus API
1 2 3
NXopendata (fileID, "wavelength"); NXgetdata (fileID, lambda); NXclosedata (fileID);
In this example, the program requests the value of the data that has
wavelength, storing the result in the variable lambda.
fileID is a file identifier that is provided by NeXus when the
file is opened.
We shall provide a more complete example when we have discussed the contents of the NeXus files.
126.96.36.199. Scientific Community¶
NeXus began as a group of scientists with the goal of defining a common data storage format to exchange experimental results and to exchange ideas about how to analyze them.
The NeXus Community provides the scientific data, advice, and continued involvement with the NeXus standard. NeXus provides a forum for the scientific community to exchange ideas in data storage.
The NeXus International Advisory Committee (NIAC) supervises the development and maintenance of the NeXus common data format for neutron, X-ray, and muon science through the NeXus class definitions and oversees the maintenance of the NeXus Application Programmer Interface (NAPI) as well as the technical infrastructure.
- Representation of data examples
- Class path specification
- Motivations for the NeXus standard in the Scientific Community
- NAPI: The NeXus Application Programming Interface