Skip to content

Commit

Permalink
Changes to Section IIIA (mostly)
Browse files Browse the repository at this point in the history
The most substantive changes are
(i) shift NXdata description above NXmonitor, since it’s more
important.
(ii) make it clear that not all data in NXdata groups are linked.
(iii) describe the NXmonitor group, without apologizing for its
location in the NXentry groups (since I don’t feel an apology is
necessary, and it’s probably unwise when you are promoting the format).
This is the right place for, e.g., all pulsed neutron experiments.
  • Loading branch information
rayosborn committed Sep 10, 2014
1 parent d1a79eb commit 63a2884
Showing 1 changed file with 16 additions and 18 deletions.
34 changes: 16 additions & 18 deletions 2014/csipaper/nexus14aip.tex
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,7 @@ \section{Introduction}
home-grown data formats. This scheme has a number of drawbacks addressed by NeXus:
\begin{itemize}
\item It makes the life of traveling scientists unnecessarily difficult as they must deal with multiple files
in different formats or use file converters, in order to extract scientific information from the data.
in different formats, file converters, etc., in order to extract scientific information from the data.
\item An unnecessary burden is imposed on data analysis software producers to accommodate many different formats.
\item The whole idea of open access to data is sabotaged if the data is in a format that cannot be easily understood.
\item Scientific integrity is jeopardized if the data cannot be understood or important elements are missing.
Expand Down Expand Up @@ -184,9 +184,8 @@ \section{Design Principles}

\section{File Hierarchies}
NeXus data files are organized into a hierarchy of groups which, in turn, can contain further groups or fields,
very much like an internal file system. The content of each NeXus group is defined by a base class, or
an application definition, or a contributed definition.

very much like an internal file system. The possible contents of each NeXus group are defined by a base class, while an application definition,
or a contributed definition, is used to specify which of these fields and groups are required for a particular type of analysis.

\subsection{Raw Data File Hierarchy}

Expand All @@ -202,13 +201,13 @@ \subsection{Raw Data File Hierarchy}
An overview of the NeXus data file structure for raw experimental data is shown in FIG.~\ref{rawfile}.


When looking at a beamline it is easy to
discern different components: beam optic components, sample position, detectors and such. It is quite natural to replicate this physical
separation with a logical arrangement of storing the data from each component into a separate group. This approach explains the
When looking at a beamline, it is easy to
discern different components: beam optic components, sample position, detectors, etc. It is quite natural to replicate this physical
separation with a logical arrangement, in which metadata from each component are stored a separate group. This approach explains the
list of beamline components in the \texttt{NXinstrument} group presented in FIG.~\ref{rawfile}.
As there can be multiple instances of the same kind of equipment, like slits or detectors, in a given beamline it becomes necessary
As there can be multiple instances of the same kind of equipment, like slits or detectors, in a given beamline, it becomes necessary
to add type information to the group name. This type information, the NeXus class name, is provided by a HDF5 attribute.
By convention NeXus class names start
By convention, NeXus class names start
with the prefix \texttt{NX}. Each NeXus group describing a beamline component contains further groups and fields describing the component.
A field can contain a single number, a text string or an array, as appropriate to the data to be described.

Expand All @@ -217,16 +216,15 @@ \subsection{Raw Data File Hierarchy}
group in the hierarchy. The \texttt{NXentry} group thus represents one scan or run (or a processed data entry, as will be discussed later).
The \texttt{NXentry} group also holds the experiment metadata, such as the date and time at which it was performed.

In the course of NeXus history,
the decision was taken to move \texttt{NXmonitor}
out of \texttt{NXinstrument} to the higher hierarchy level of \texttt{NXentry},
in order to facilitate quick inspection.
To enable default visualization of the experimental data,
at least one \texttt{NXdata} group should be provided at the \texttt{NXentry} level.
It contains the plottable data, or links to the data, which often reside in the \texttt{NXdetector} group (links are supported by HDF5 and work like
symbolic links in the Unix file system). It also contains information about plot axes, using attributes to define what
the data should be plotted against.

To enable a simple default visualization,
a \texttt{NXdata} group must be provided at \texttt{NXentry} level.
It contains information about plot axes and links to the data
(which often reside in the \texttt{NXdetector} group).
Links are supported by HDF5 and work like symbolic links in the Unix file system.
The \texttt{NXentry} group may also contain one or more \texttt{NXmonitor} groups, containing data from beamline monitors. Since they may
also contain plottable data, it uses the same attribute scheme to associate the monitor data with its plotting axes. Its location in the
\texttt{NXentry} group facilitates quick inspection for beamline diagnostics.

A special base class, \texttt{NXcollection}, exempts its contents from validation
and thereby allows inclusion of whatever data in arbitrary non-NeXus formats.
Expand Down

0 comments on commit 63a2884

Please sign in to comment.