跳转至

LHCb 数据流

学习目标

  • 了解 LHCb 在第三轮运行（Run 3）中数据流的变更
  • 掌握高速触发器（HLT）与 Sprucing（修饰过程）的关键概念

LHCb 升级

在Run 1 & 2中，LHCb 不仅证明了自身是一个高精度的重味物理实验，而且将其核心物理项目扩展到了许多不同领域，如电弱物理和固定靶实验。同时因为其所以拥有的惊人的精度，也促成了超过500篇论文的发表，其中包括多项突破性发现，例如首次在粲夸克领域发现 CP 破坏（CP-violation in charm），以及首次观测到\(B_s^0\to \mu^+\mu^-\)衰变等。

为了达到更高的精度，该实验计划在LHCb升级计划结束前（包括Run 1、2、3和4），通过将瞬时亮度提高五倍，获取总共\(50~\mathrm{fb}^{-1}\) 的数据。为了能够应对更高的探测器占用率，实验将配备一套全新的径迹探测器，这些探测器具有更高的空间分辨率和更强的耐辐射能力。

实验的数据流大致可分为“在线”（online）和“离线”（offline）处理。“在线”处理，包括探测器响应与读出，以及数据被永久存储到磁带之前的两个高速触发器阶段。而“离线”处理，则是通过 Sprucing 应用程序访问存储的数据，处理后的结果也将被存储到磁盘并供物理分析人员使用。

在Run 3 中最重要的升级之一是移除了 LHCb 的 L0 硬件触发器。如下文所述，这给实验的在线和离线数据处理流程都带来了重大变化。这意味着所有子探测器的前端电子学和读出电子学都必须更换，以便能够以 \(40~\mathrm{MHz}\) 的束流对撞频率运行；同时，RICH1 探测器的光电探测器也需要更换。

LHCb 触发器系统升级

根据《LHCb升级实验技术设计报告》中的计算模型设计，当前的触发架构如下图所示：

online_dataflow.png

LHCb 的触发器系统已完成全面重新设计，移除了 L0 硬件触发器，转而采用全软件触发模式——这在大型强子对撞机（LHC）（详见：cern news）中是一项创新举措。原硬件触发器的速率限制为 \(1~\mathrm{MHz}\)，而随着亮度的提升，这一限制将成为瓶颈。硬件触发器要实现如此低的速率，只能依靠对相对粗糙的特征设置严格的触发阈值，但这对于全强子衰变模式而言效率极低。

由于 LHCb 选择的物理特征类型（具有特定拓扑的衰变、软强子等），这种速率缩减最好通过对事件的整体理解来实现，即重建事例内的径迹、顶点并合成复合粒子。因此，这需要采用软件触发器。然而，这并非易事，虽然移除 L0 触发器将为物理研究带来巨大益处，但它却要求整个探测器读出系统必须能够以束流交叉频率 \(40~\mathrm{MHz}\) 运行，而软件触发器的第一阶段（HLT1）必须在平均非空束流交叉频率 \(30~\mathrm{MHz}\) 下运行。因此，这是无疑是一个巨大的计算挑战！

软件触发器分两步实现： 1. HLT1：执行部分事例重建和简单的触发判定，以降低数据速率。 2. HLT2：执行计算量更大的完整重建和全面的触发选择。

在Run 3中，HLT1 在 GPU 上运行。由于其所需任务（这类任务的计算成本较高，例如重建径迹）具有高度可并行化的特性，这带来了处理能力的大幅提升。

HLT 架构

有关当前 HLT 架构的更多细节可参考论文The LHCb Upgrade I的第 10、11 章。为了完成事例选择，全软件的 LHCb 触发器必须获取所有子探测器的完整事例信息。因此，对于每一次非空束流的碰撞(频率为\(40~\mathrm{MHz}\))，都需要进行事例构建，即把同一束交叉束流内的全部数据片段拼装成完整事例。构建完成的事件随即递交给 HLT1 阶段的筛选，该进程利用GPU 来处理事例。

经过 HLT1 筛选后的事例随后被传递到数据存储缓冲区，供后续阶段读取。在 GPU 上运行 HLT1 也对代码开发提出了一些不同的要求。Allen 框架基于 CUDA GPU 编程平台，开发者必须保证 HLT1 算法具有最大并行度和线程安全，即并行进程访问内存时必须保证安全性。而有关如何为 HLT1 编写重建算法与选择线（selection lines）的文档，可见 Allen Gitlab project 项目的 README 及配套文档被 HLT1 选中的原始事例数据先进入缓冲区暂存，之后再进行探测器对齐和校准，再由 HLT2 才能处理它们即便使用 GPU，HLT1 仍仅做部分重建以满足吞吐量需求，这包括不进行强子识别以及对磁场和探测器物质条件使用简化的模型。

由于 LHCb 升级后的绝大部分物理分析并未保留离线重建所需的信息，因此在线重建必须达到离线级质量。这一质量得以实现，关键在于探测器在 HLT2 处理事件之前，缓冲区中的 HLT1对筛选事例进行了实时对齐和校准。为了确定对齐和校准参数，HLT1 会专门挑选用于对准与标定的样本事例。如果没有这一步，下文描述的持久性模型将无法实现，并且每 LHC second 内可保存的事例（及其物理产出）将大幅减少。有关实时对齐和校准的更多信息，见Upgrade Alignment TWIKI。

高级触发器的第二/最后阶段（HLT2）与 HLT1 不同，其吞吐量限制较小，可以在 CPU 上执行。HLT2 更精确的物质相互作用模型，执行强子识别以及其他在 HLT1 无法完成的重建工作。得益于实时对准与标定，HLT2 的重建质量可媲美传统离线重建，从而彻底省去离线重建步骤。

重建后的事例会通过成千上万条不同的物理选择线进行评估，每条选择线都是一系列算法的序列，用于定义一个事例是否包含感兴趣的对象，从而决定其是否应保留用于离线处理和分析HLT1（第一级触发系统）的设计主要受吞吐量限制，需达到 \(30~\mathrm{MHz}\) 的处理速度；而 HLT2（第二级触发系统）的性能则更多受带宽约束，即每 LHC second 写入永久存储的数据量。带宽直接对应磁带存储成本，从而对 LHCb 的物理产出形成财务约束，从而限制了 LHCb 能够进行的物理分析范围。为了应对这一问题，升级方案引入“持久化模型”，压缩单事例体积，以在相同带宽下保存更多事例、扩大物理范围。

用于评估事例的选择线被分流（streamed），即依据选择线的最终物理或技术用途，把结果写入不同的输出文件，从而最小化总数据量，同一流内的所有选择线共享底层逻辑并记录相似的事件信息。对于物理分析，主要有两个流：Turbo 流和 Full 流。这两个流都移除了原始的探测器信息（rawbanks）。持久性模型的示意图见下图(摘自Computing Model of the Upgrade LHCb experiment的技术报告)。 persistency_cartoon.png

在 HLT2 之后不再保留原始数据块（rawbanks）减少了平均事例大小，从而降低了对 HLT2 总带宽的占用，但这的代价是失去离线重建能力。可以认为，每一次数据缩减都是在离线分析的灵活性与在线物理研究范围之间做出的权衡。Full 流保留所有重建的对象，而 "pure" Turbo 流只保留与感兴趣候选体相关的重建对象。与 Full 流相比，这进一步减少了平均事例大小。而 "pure" Turbo 指的是极端的压缩情况，但存在一种折中方案，即一个选择可以保留一些额外信息（重建的或原始的）以及其候选体信息。这种折中方案被称为 Turbo "Selective Persistence" 。由于 Turbo 流能显著降低带宽占用，因此在可能的情况下，它被作为基准方案，并预计占总数据量的三分之二，任何额外的持久化都必须有充分的物理依据。

在设计/评估一条选择线时，应针对其具体目标决定置于 Turbo 还是 Full 流。此外，需留意两种流在离线处理阶段 Sprucing 应用中的差异（见下文）。有关如何开发 HLT2 选择线、如何分流、如何验证效率与数据率的详细教程，请参考 Moore documentation。

离线数据处理

如下图所示，离线数据处理包含两个主要步骤：

  1. Sprucing是一个离线筛选阶段，其功能与 HLT2 (二级触发) 类似。

  2. relevant section of the starterkit 是一种集中化的方式，用于通过 relevant section of the starterkit生成可供物理分析直接使用的元组。 offline_dataflow.png

由HLT2筛选并迁移至离线系统的信息永久存储在磁带上，随后由 Sprucing 应用程序进行进一步处理。Sprucing 的输出以“流”的形式保存在 Worldwide LHC Computing Grid 的磁盘上，可供分析人员访问。数据首先保持 HLT2 阶段的分流方式，区分为 Full 流, Turbo 流以及其他校准/技术流；随后再按物理兴趣（大致对应各物理工作组）进一步细分。

  • Turbo 流： 默认通过直通式精梳 (passthrough Sprucing) 进行处理。这主要涉及原始数据块 (rawbanks)的重组及压缩操作，总体上减小了存储文件的大小，但不执行任何事件筛选。

  • Full 流：因保留全部重建对象，需通过专门编写的 Sprucing 选择线对事例执行额外的过滤、组合与筛选。HLT2 与 Sprucing 的选择线共享同一套代码库，因此筛选线可以在两者之间灵活互换。在此阶段，Full流中每个事件存储的信息量也会被减少，默认遵循纯Turbo模式，即仅保留信号候选体信息，从而减少保存到磁盘的数据量。因此，与HLT2类似，这是一种权衡，但这是在WLCG存储容量与离线分析（如DaVinci及后续分析）的灵活性之间的权衡。之所以必要，原因在于，磁盘可承载的总带宽远低于磁带，必须进一步压缩。

对 Full 流事件进行此额外处理步骤具有双重好处：

  1. 包容性触发 → 排他性筛选（提高触发灵活性）： HLT2 阶段可部署包容性触发（如服务于多种不同物理分析的拓扑触发），然后通过Sprucing为多个排他性筛选提供输入。此外，某些因实时性要求无法在 HLT2 运行的复杂触发，也可在 Sprucing 离线实现。
  2. 可回溯安全（保障物理无损性）：它提供了一定程度的安全性保障，通过Re-Sprucing活动对HLT2 Full 流输出进行重新处理，使得Sprucing中的任何筛选在长期来看都可以是物理无损的，因为数据在应用新写或新优化的选择线前，始终可被重新取回与审查。

由于HLT2后的 Full 流必须经过 Sprucing 阶段进一步处理，而 Turbo 流可直接透传，因此 Turbo 流数据比 Full 流数据能更快地被分析人员访问。然而，2024 年的 Sprucing 活动已实现与取数几乎同步运行，Full 流的延迟已非常短暂。