1.简介

越来越多的主要中子和X射线设备选择使用NeXus数据格式存储数据。自2006年最后一次出版以来（Könnecke&NIAC，2006）)NeXus经历了实质性的重新聚焦，精炼和增强，如本文所述。

从历史上看，中子和X射线设备选择以过多的家庭式数据格式存储数据。NeXus解决了该方案的一些缺点：

（i） 这使得旅行科学家的生活变得不必要的困难，因为他们必须处理不同格式的多个文件、文件转换器等，以便从数据中提取科学信息。

（ii）为适应多种不同的格式，数据分析软件生产商承担了不必要的负担。

（iii）如果数据的格式不易理解，那么公开访问数据的整个想法就被破坏了。

（iv）如果数据无法理解或重要元素缺失，科学完整性就会受到损害。

（v） 现代高速探测器以如此高的速度产生数据，以至于许多旧的单图像存储方案变得不切实际，高效的容器格式是强制性的。

数据格式的主要必要性是定义物理文件格式：数据是如何写入磁盘的？NeXus没有发明另一种格式，而是选择了HDF5（HDF Group，2014一)作为物理文件格式。HDF5是一种公共领域的二进制文件格式，受到商业和自由软件工具的良好支持。它高效、自我描述且依赖于平台。

NeXus数据文件是使用基本的HDF5存储元素构建的：数据组（如文件系统文件夹）、数据字段（如字符串、浮点、整数和数组）、属性（组和字段的附加描述符）和链接（如文件系统链接）。NeXus是根据这些基本存储元素实现的。

NeXus增加了HDF5：

（i） 用于在HDF5文件中组织特定于域的数据的规则，尤其是用于在文件中安排数据的数据层次结构。

（ii）支持快速默认可视化的链接结构

（iii）以基类形式表示的文档化域特定字段的字典。

（iv）可以应用定义形式验证的标准定义。

NeXus的开发由NeXus国际咨询委员会（NIAC）监督（NIAC，2014b条).

2.总则

鼓励数据采集和仪器控制软件的作者每次测量只生成一个NeXus容器文件（测量是在固定条件下的数据积累或扫描）。该文件不仅包括探测器和监视器数据，还包括元数据、波束线状态信息、参数日志等。数据还原和数据分析软件的作者可以使用NeXus存储处理过的数据以及元数据和处理日志。

NeXus可以用于许多不同的实验技术和不同级别的数据处理。对于这些不同的应用程序，需要标准化NeXus实体的特定子集（数据组和字段）。特定用例的最小字段集在NeXus应用程序定义中进行了标准化（§6). 通过从NeXus基类（§5）中添加额外字段，可以始终增强最小集).

作为一种容器格式，NeXus允许通过附加内容随时扩展文件，包括NeXus基类、HDF5组和HDF5数据集。因为HDF5提供了对文件的完全读写访问，所以可以在现有NeXus文件中进行此类更改，而无需编写完整的新文件。

将定义良好的组层次结构与全面且有良好文档记录的数据和元数据名称字典相结合，可确保NeXus文件是自我描述的。另一位科学家应该可以在不查阅任何一个设施或束线特定文档的情况下理解NeXus文件的内容。通过实现全面元数据的存储，NeXus格式促进了合作者之间的数据共享和长期数据管理。

3.数据文件层次结构

NeXus使用组层次结构来安排HDF5文件中的数据。数据文件可能包含原始数据或处理过的数据，或两者都包含，每个文件都有一个层次结构。

3.1. 原始数据文件层次结构

NeXus的主要重点是记录原始实验数据，即直接从实验设备中获取的信息或仅根据需要进行处理以提供物理意义上的值的信息。NeXu的原始数据文件层次结构是一些实际考虑的结果。图1显示了NeXus原始实验数据数据文件结构的概览.

图1 NeXus原始数据文件的结构概述。请注意，只有此结构的一小部分（第一个NX条目组和第一个NX数据组）。其他内容是可选的。

当观察光束线时，很容易辨别出不同的组件：光束光学组件、样品位置、探测器等等。复制这种物理分离是很自然的，因为逻辑安排是将每个组件的数据存储在一个单独的组中。该方法解释了NX仪器图1所示的组由于在给定的波束线中可能存在相同类型的设备的多个实例，例如狭缝或检测器，因此有必要将类型信息添加到组名称中。此类型信息（NeXus类名）由HDF5属性提供。按照惯例，NeXus类名以前缀开头西北描述波束线分量的每个NeXus组包含描述该分量的另外的组和字段。字段可以包含单个数字、文本字符串或数组，具体取决于要描述的数据。

需要能够在同一文件中存储多个相关扫描或运行，或者需要在一个文件中捕获完整的工作流，这会导致波束线组件层次结构被深入到NX条目层次结构中的组。这个NX条目因此，组表示一次扫描或运行（或处理的数据条目，稍后将讨论）。这个NX条目group还保存实验元数据，例如执行实验的日期和时间。

在NeXus的发展过程中，决定NX监视器由于NX仪器更高层次的NX条目，以便于人类快速检查。

要启用简单的默认可视化NX数据必须在NX条目级别。它包含有关绘图轴和数据链接的信息（通常位于NX探测器组）。链接由HDF5支持，其工作方式与Unix文件系统中的硬链接类似。

一个特殊的基类，NX集合，免除其内容的验证，从而允许以任意非NeXus格式包含任何数据。

3.1.1. 多方法仪器

特别是在X射线源方面，一些仪器提供了多种可以并行使用的技术。例如，可以在SAXS/WAXS光束线上同时测量小角度散射和粉末衍射。我们建议将所有方法中的数据存储在单个文件中NX条目层次结构（图2). 所有探测器、日志等的所有信息都收集在这里NXentry公司组将数据保存在一起。特定于一种实验技术的信息与NX子条目. TheNX子条目遵循的层次结构NX条目，但它通常只链接到特定实验技术的应用程序定义所需的数据。该方案的要点是，人类和计算机用户都可以轻松定位特定方法的数据，同时保持实验的完整视图。

图2 使用多种方法的仪器的NeXus原始数据文件结构概述。

3.1.2. 扫描

扫描有各种形状和大小。几乎任何东西都可以根据任何东西进行扫描。另一个需要考虑的问题是，实际上，无法提前知道扫描中的最终扫描点数量，因为扫描可能会在计划的观察次数之前中断或终止。因此，标准化扫描是一个挑战。NeXus通过使用HDF5“无限维度”功能和下文所述的其他约定来应对这一挑战。使用HDF5无限尺寸功能，数据的一个轴可以无限扩展。因此，不需要预先声明数据数组的大小。数据可以根据需要沿无限维度附加到数组中。

扫描按照以下两种约定存储在NeXu中：

（i） 扫描中变化或收集的每个变量都作为阵列存储在NeXus波束线层次结构中的适当位置。阵列的第一个维度是扫描轴。这是实现中的无限维，每个扫描点的数据都附加到数组中。

（ii）NX数据组保存扫描期间变化或收集的所有变量的链接。这就产生了与人们习惯于扫描的表格表示法相当或更好的东西。探测器数据可以相对于任何扫描参数绘制，也可以相对于除此之外被认为值得记录的所有参数绘制。必要的数据都收集在NX数据组，直接或通过链接，以便通常不必搜索其他组来进行此绘图。

NeXus还支持多维扫描。这使得通过数据卷生成有意义的切片变得非常简单，即使使用NeXus不可知软件也是如此(例如 HDF视图; HDF集团，2014年b条).

3.2. 已处理数据文件层次结构

应用户社区的要求，NeXus创建了一个简化的结构，用于存储数据处理的结果，无论是简化还是分析。处理数据的NeXus结构概述如图3所示.

图3 NeXus处理数据文件的结构概述。

层次结构大大减少，因为将所有实验信息都带到数据缩减中并不重要。与原始数据文件结构相比，NX数据在已处理的文件结构中，是存储处理结果的位置，如果结果是多维数组，则是存储其关联轴的位置。

除了NX数据和NX示例组NX进程组提供了一个结构来存储有关处理的详细信息，例如所使用的程序、其版本、处理日期和其他元数据。这个NX进程组可以容纳其他NX参数组，是用于存储用于执行处理的程序的输入和输出参数的容器。

4.坐标系、部件定位和其他规则

为了减少数据量，通常需要知道波束线组件的准确位置和方向。首先需要一个参考坐标系。NeXus选择使用与中子束线模拟软件相同的坐标系麦克斯塔斯（威伦德鲁普等人。, 2004).

为了描述组件的位置和方向，NeXus存储的信息与晶体信息文件（CIF；霍尔和麦克马洪，2005年).成本加保险费、运费（和NeXus）存储从零点将坐标系调整到其实际位置。由于坐标变换是不可交换的，因此也必须存储变换的顺序。

读者可参考NeXus手册，了解有关轴、装置和数据存储特殊情况处理的更多规则。

5.基类

从NeXus文件层次结构的讨论中可以看出，NeXus以组的形式排列数据，组中有一个类型描述符和与之相关联的NeXus基类名称。从技术上讲，类名是HDF5属性的值NX_类.术语“基类”的用法与面向对象编程语言中的含义不同；特别是，没有继承。NeXus基类提供了一个全面的术语词典，可以用于每个类。字典中的术语由基类主题通用的概念和名称组成。每个术语的预期拼写和定义在基类中指定。既不期望也不要求提供基类中指定的所有术语。这些术语指定可以存储在组中的数据字段。数据字段可以具有简单类型（如整数、浮点、日期/时间、二进制），也可以是NeXus子组。基类定义还包含关于每个字段语义的非正式注释。允许使用其他名称的术语，但标准软件可能无法识别。

在基类级别，NeXus没有将某些字段标记为必填字段的机制。所有允许的字段都是可选的。必须根据应用程序的需要决定将它们中的哪些写入数据文件。这些决策可以以应用定义的形式进行标准化（见下文第6节).

NeXus基类用NeXus描述语言（NXDL）编码（NIAC，2014c（c）). NXDL只是XML文件的另一种形式，它指定了NeXus基类的内容。NXDL文件可以由人或软件解析，并且可以验证语法和内容。NXDL文件用于验证NeXus数据文件的结构。GUI（图形用户界面）工具的Java源代码已经准备好（NIAC，2014d日)进行此类验证。

6.应用定义

以NXDL表示的应用程序定义指定了给定应用程序领域的数据结构，例如科学技术或特定类型的仪器。数据结构由NeXus组的层次结构组成，每个组都指定了最小内容。因此，应用程序定义不同于基类定义，基类定义指定了可以使用的综合术语词典。

历史上，应用程序定义只针对一种仪器，如X射线反射计或直接几何中子飞行时间光谱仪。因此，应用程序定义最初被命名为“仪器定义”。然而，由于NeXus也可以用于处理数据，例如层析重建或动态散射定律S公司(问, ω)采用了更通用的术语“应用程序定义”。

7.贡献的定义

起草和批准申请定义的过程正在进行中（另见下文第8条). 目前，代表NIAC和IUCr委员会的科学家成本加保险费、运费标准已接近完成NeXus对大分子晶体学（MX）的应用定义。CBFlib（伯恩斯坦和埃利斯，2005;https://sourceforge.net/projects/cbflib网站和https://www.bernstein-plus-sons.com/software/CBF网站/)正在扩展以使用NeXus MX格式，这项工作将在另一篇论文中发表。针对减少小角度散射数据的另一个NeXus应用程序定义的工作也在进行中（canSAS，2014年)canSAS、NeXus和IUCr小角度散射委员会的科学家。

科学界提出的用新的应用定义和基类扩展NeXus的所有此类建议最初都是作为贡献定义添加到NeXus中的，无论是在孵化中还是作为非通用的特殊情况。NIAC（见治理）负责审查任何新的定义，并在批准和接受之前向作者提供反馈。

8.治理

NeXus的开发由NIAC监督（NIAC，2014b条). NIAC寻求国际社会的均衡代表性。大多数主要的中子、X射线和μ介子设施都任命了代表。其他设施也被邀请加入。

NIAC审查对NeXus基类和应用程序定义的任何拟议修改，并进行在线投票批准修改。存在大量候选NeXu应用程序定义，这些定义源于我们对所述技术的理解。对于其中的每一项，NeXus团队都寻求社区批准。

9.对NeXus的吸收

NeXus已经在许多设施中用作主要数据格式，包括SOLEIL（法国）、Diamond（英国）、SINQ（瑞士）、SNS（美国）、Lujan/LANL（美国）和KEK（日本）。其他设施包括ISIS（英国）、DESY（德国）和μSR（muon spin rotation/relaxation/resonance）社区正朝着NeXus的数据格式发展。在LBNL（美国），NeXus目前正在用于X射线自由电子激光（XFEL）系列晶体学数据。APS（美国）正在使用NeXus存储其部分数据收集。这个EPICS系统（河流，2014)区域探测器软件有一个插件，可以将采集的图像写入NeXus数据文件。此外，一些区域探测器的商业制造商现在将采集的图像写入NeXus数据文件。

NeXus的采用花费了一些时间。原因是，每当设施开始运行或进行重大翻新时，往往会选择NeXus。对于那些有从数据采集到数据分析的现有工作管道的设施，通常缺乏资源，无法将NeXus作为唯一的数据文件格式。

这反映在μ介子社区的经历中。对于ISIS源，2002年转向基于Windows PC的数据采集系统需要一种新的数据格式，这为开发新兴NeXus标准提供了一个理想的机会（Flannery，2003). 相比之下，PSI（瑞士）、TRIUMF（加拿大）和KEK的消息来源继续充分利用现有格式和软件。最近，欧盟的资助使社区能够将应用程序定义开发为μon数据的通用交换格式（Cottrell等人。, 2012).

无论是作为主格式还是中间格式使用，用户都可以从所有这些设施中写入的数据生成兼容的NeXus文件，从而提高NeXus在社区中的使用率。

10.向后兼容性

过去，NeXus支持使用NeXus应用程序编程接口（NeXus API或NAPI）读取和写入HDF4、HDF5和XML格式的数据文件。NAPI仍然可用，但除错误修复外已冻结。在与社区协商后，目前建议仅使用HDF5文件格式，使用标准HDF5工具来使用NeXus。预计这将成为NeXu未来软件开发和文件创建的基础。

11.总结

在过去的十年里，NeXus已经相当成熟，现在已经在许多设施中使用。NeXus具有足够的灵活性，可以容纳各种各样的仪器和科学应用，但其效率足以处理来自现代高速探测器的数据。更多信息，包括PDF格式的完整手册，可在项目网站上找到（NIAC，2014一). NIAC成员（NIAC，2014b条)欢迎与NeXus数据格式开发相关的通信。