HLT2与Sprucing

学习目标

• 在数据流课程的基础上进一步拓展相关知识
• 重点介绍与HLT2和Sprucing相关的资源

了解Moore的基础知识

LHCb高能触发器（HLT）由三个阶段构成：HLT1、HLT2和Sprucing，这些在数据流课程中已有详细介绍。在数据采集过程中，HLT无法存储所有事件，必须对需要保留的事件进行筛选，这一工作通过名为"触发线路"的事件选择算法完成。若每个阶段中任意一条线路做出正向决策（即线路"触发"或"生效"），事件就会被保留，否则将被丢弃¹。触发器的HLT2和Sprucing阶段包含了合作组的大部分触发线路（数千条），并运用数万个算法。

本课程重点介绍Moore------用于HLT2和Sprucing的应用程序，因为它是分析师与触发软件最常交互的接口。关于通过Allen实现的HLT1的更多信息，可参考Allen文档。

Moore文档 中有关于运行和开发Moore的详细内容。进行线路开发时，最好采用专家建议/提供的触发配置设置，这些设置经过精心选择，能最佳模拟预期的数据采集周期。若不确定合适的设置或应咨询的专家，建议联系相关的RTA/DPA工作组联络人。

HLT2线路的核心概念

对于每个事件，触发线路通常分为两个步骤：

• 尝试在事件中构建感兴趣的候选者，若存在则保留该事件。

• 若触发生效，会保存与事件相关的信息，包括找到的候选者。"相关信息"取决于线路和具体的物理应用场景。

因此，创建一条HLT2线路需要仔细定义这两个步骤。

构建感兴趣候选者所使用的工具，与"粒子组合器入门"课程中讨论的工具相同（如ParticleFilter和ParticleCombiner），而编写HLT2线路的基础知识（如正确语法等）可在Moore文档的"编写HLT2线路"部分查阅。

HLT2和Sprucing阶段存在严格的运行约束，所以一条线路必须能以高信号效率（尽可能）筛选出感兴趣的候选者，具备良好的纯度，并且通过控制在可接受范围内的速率和带宽来合理利用可用资源，同时不降低该阶段的吞吐量。

选择阶段的吞吐量

• 吞吐量指选择阶段每秒可处理的事件数量。
• 添加/开发性能良好的线路，应对该阶段的吞吐量无负面影响或影响可忽略不计。
• 线路对吞吐量产生负面影响的最常见原因，将在"线路的进一步考虑"中探讨。
• 可依据"时序与性能"中的建议进行评估。

信号效率

• 信号效率是在包含目标物理过程的模拟事件集中，线路正确筛选出的事件所占比例。
• 通过HltEfficiencyChecker进行评估。

纯度

• 纯度是在最小偏置事件（如数据采集时的事件）中，被选中的类信号事件所占比例。
• 高纯度等同于具备强背景抑制能力。
• 可以通过监测直方图和分析水平研究对数据和模拟进行评估。

速率

• 速率是数据采集过程中，线路每秒做出正向决策的次数。
• 一条高效、高纯度且筛选排他性衰变的线路，其速率与该衰变的真实信号速率非常接近。
• 关于如何计算特定衰变的真实信号速率，可参考"真实信号速率"中的说明。
• 1Hz的速率在单个数据采集年中约能保存1e8个候选者。纯度低会导致触发并处理数百万/数十亿个非信号候选者！
• 通过带宽测试基础设施进行评估。

持久性

• 线路的持久性指在事件中成功找到候选者时所保留的信息。
• 默认情况下，除触发线路的重建候选者外，不保留其他信息，每个保存事件的大小约为10kB。
• 可以选择保留事件中的更多信息，例如同一质子-质子相互作用产生的其他重建粒子、事件中所有重建的光子等。
• 但是，保留超出默认范围的信息必须逐案申请，并详细说明理由。
• 评估方式见下文"带宽"部分。

带宽

• 带宽是线路在数据采集过程中每秒写入的数据量。
• 与线路速率和线路定义的持久性直接相关。
• 以上述高效、高速率且筛选排他性B衰变的线路为例，若采用默认的最小持久性设置，在单个数据采集年中约会保存10TB的数据。
• 这就是为什么保留额外信息或申请添加高速率线路必须格外谨慎地说明理由。
• 这一决策需综合考虑预期分析的需求、线路速率以及可用的进一步修改预算，因此需要与相关的RTA/DPA工作组联络人商议。
• 通过带宽测试基础设施进行评估。

线路的进一步考虑

控制流顺序：对吞吐量的影响

以创建一条用于 \(B_s^0\to (D_s^- \to K^- K^+ \pi^-) \pi^+\) 衰变的线路为例。其（伪）代码大致如下：

from Moore.lines import Hlt2Line
def myLine(name="Hlt2WG_MyLine):
  bs = make_bs()
  return Hlt2Line(
    name=name,
    algs=[bs],
  )

其中，make_bs()是一个生成K介子和π介子的算法，先将它们组合成 \(D_s^-\) ，再组合成 \(B_s^0\) 。因此，从HLT2的角度来看，这条线路包含一个要运行的算法。

相反，考虑将其分为两个算法，如下所示：

from Moore.lines import Hlt2Line
def myLine(name="Hlt2WG_MyLine):
  ds = make_ds()
  bs = make_bs(ds=ds)
  return Hlt2Line(
    name=name,
    algs=[ds, bs],
  )

这样做的好处是，该线路会先尝试构建 \(D_s^-\) 候选者，只有成功后，才会继续尝试利用 \(D_s^-\) 候选者构建 \(B_s^0\) 候选者。这对物理指标（如效率或纯度）没有影响，但能让HLT2更早判断线路是否未能找到候选者，从而提高线路的吞吐量。

这也有利于代码模块化。这很有用，因为相关线路通常会共享算法，也是遵循代码设计指南的一部分。

组合学：对吞吐量的影响

继续以 \(B_s^0\to (D_s^- \to K^- K^+ \pi^-) \pi^+\) 为例。该衰变中的 \(D_s^-\) 有运动学要求（例如对组合的不变质量切割）。可按如下方式实现：

def make_ds():
  km = make_meson(species="km")
  kp= make_meson(species="kp")
  pim = make_meson(species="pim")
  return ParticleCombiner(
    [km, kp, pim],
    name="MyDsMaker",
    DecayDescriptor="[D_s- -> K- K+ pi-]cc",
    CompositeCut=F.math.in_range(
      minimum_ds_mass, F.MASS, maximum_ds_mass
    ),
  )

注意，在LHCb的单个事件中会产生大量π介子和K介子，在评估要求之前为每个三重态生成潜在的 \(D_s^-\) 候选者可能会耗费大量时间，进而影响选择阶段的吞吐量。

通过添加基于相关物理的切割来减少输入粒子的数量，可改善这一情况。例如，\(D_s^-\) 候选者产生的π介子和K介子是"分离的"，即它们并非直接来自质子-质子碰撞，而是后续产生的。因此，对相关量（如F.OWNPVIPCHI2）进行切割有助于区分"即时"介子和分离介子，从而减少组合次数，提高吞吐量。

通过在组合前对输入添加一些切割，也能改善组合学问题。常规的切割（composite_cut）是在组合输入后对候选者进行筛选，包括对输入进行耗时的顶点拟合（关于LHCb中组合的具体方式，可参考相关文档代码）。

可以添加一个额外的切割（combination_cut），在顶点拟合前对"原始组合"进行筛选，这样能节省时间并提高吞吐量。重要的是，由于combination_cut在顶点拟合前进行，一些运动学量在拟合前后会有所不同。因此，最佳做法是让composite_cut至少与combination_cut一样严格。

我们可按如下方式实现这两个建议：

def make_ds():
  ## Make input particles via a function with an implicit cut to remove prompt particles
  km = make_detached_meson(species="km")
  kp = make_detached_meson(species="kp")
  pim = make_detached_meson(species="pim")

  # A cut on relevant quantities, to be applied before the vertex fit
  combination_cut = ...
  # A tighter cut on the same quantities, to be applied on the actual candidate, i.e. after the vertex fit
  composite_cut = ...
  return ParticleCombiner(
    [km, kp, pim],
    name="MyDsMaker",
    DecayDescriptor="[D_s- -> K- K+ pi-]cc",
    CombinationCut=combination_cut,
    CompositeCut=composite_cut,
  )

预过滤器：对速率和吞吐量的影响

默认情况下，选择线路会对提供的所有事件运行包含的算法。但可通过使用hlt1_filter_code（以及Sprucing特有的hlt2_filter_code）进行修改，即要求前一阶段的线路在事件中做出正向决策后，选择线路才会运行。

这能提高吞吐量，因为算法的运行频率降低，但也可能产生物理和速率方面的影响，因为它可能会过滤掉线路本可找到候选者的事件。特定线路适用的hlt1/hlt2过滤器取决于具体的物理应用场景。若不确定，可与相关工作组商议。

例如，在 \(B_s^0\to (D_s^- \to K^- K^+ \pi^-) \pi^+\) 中，可添加HLT1过滤器"Hlt1.*Track.*MVADecision" ，确保只有当相关的HLT1线路（TrackMVA、TwoTrackMVA或TrackMuonMVA等）在事件中做出正向决策时，HLT2线路才会运行。由于分析师在分析过程中通常会对触发相关信息设置切割，以获得易于理解的触发效率，因此建议在触发线路中明确实现这些切割，以节省速率、带宽和吞吐量。

• 关于如何向触发线路添加预过滤器，可参考该测试脚本中的示例。

监测：了解纯度

在数据采集过程中，HLT2会自动生成监测图，这些图通常会提供给分析师，以便他们在数据经Sprucing处理并提供给分析师之前了解线路的性能。再以 \(B_s^0\to (D_s^- \to K^- K^+ \pi^-) \pi^+\) 为例，对于这条线路，默认监测会生成描述 \(B_s^0\) 候选者的直方图（如不变质量）。

然而，这些默认设置可能无法满足线路特定的物理需求，因此监测其他信息可能会很有帮助。例如，监测中间态或默认情况下未监测的特定相关变量。为此，有自定义监测可供使用。

监测中间态的一个常见场景是针对稀有候选者，因为即使在该事件中无法与 \(B_s^0\) 组合，每次成功找到 \(D_s^-\) 时，自定义监测都能进行数据填充。因此，监测中间态有助于在开发和数据采集过程中了解线路的性能。

编码指南

代码应清晰、易读且可维护，任何分析师都应能理解任意线路。应避免不必要的重复，同时鼓励使用代码注释和文档字符串。这不仅对后续分析师有帮助，还能通过减轻维护负担来防止错误和意外后果。

关于HLT2/Sprucing线路的代码设计，有两个资源可供参考，相关的RTA/DPA工作组联络人也会提供建议：

• 代码设计指南
• hlt2_guidelines:code

Sprucing线路

从设计而言，编写Sprucing的触发线路基本遵循上述关于HLT2线路的所有讨论，且在同一框架中运行。请记住，如数据流课程中所述，进入Turbo或TurCal流的HLT2线路无需编写相关的Sprucing线路，而是通过"直通"Sprucing进行处理。

值得注意的差异

• HLT2线路可采用要求特定HLT1线路决策的预过滤器。Sprucing线路也可采用相同的预过滤器，还能基于HLT2线路决策进行预过滤。

• HLT2线路的监测在数据采集期间运行，分析师也可在本地运行。Sprucing拥有相同的监测系统，但不在数据采集期间运行。因此，Sprucing监测仍然重要，但主要用于测试、验证和评估线路性能。

• Sprucing线路的语法与HLT2线路极为相似，以下是在HLT2和Sprucing中实现相同线路的近似真实示例：

HLT2Sprucing

@register_line_builder(all_lines)
@configurable
def z_to_mu_mu_single_nomuid_line(
    name="Hlt2QEE_ZToMuMu_SingleNoMuIDFull", prescale=1, persistreco=True
):
    """Z0 boson decay to two muons line, where one requires ismuon, for efficiency studies"""

    z02mumu = make_Z_cand_SingleNoMuID()
    monitor_z0 = qee_default_monitors(
        particles=z02mumu, linename=name
    )
    return Hlt2Line(
        name=name,
        algs=upfront_reconstruction() + [z02mumu, monitor_z0],
        prescale=prescale,
        persistreco=persistreco,
        hlt1_filter_code=["Hlt1SingleHighPtMuon"],
        monitoring_variables=("pt", "eta", "n_candidates"),
    )

@register_line_builder(sprucing_lines)
@configurable
def z_to_mu_mu_single_nomuid_sprucing_line(
    name="SpruceQEE_ZToMuMu_SingleNoMuID", prescale=1, persistreco=True
):
    """Z0 boson decay to two muons line, where one requires ismuon, for MuonID efficiency studies. passthrough after Hlt2QEE_ZToMuMu_SingleNoMuIDFull"""
  z02mumu = make_Z_cand_SingleNoMuID()
  monitor_z0 = qee_default_monitors(
        particles=z02mumu, linename=name
    )
    return SpruceLine(
        name=name,
        algs=upfront_reconstruction() + [z02mumu, monitor_z0],
        prescale=prescale,
        persistreco=persistreco,
        hlt1_filter_code=["Hlt1SingleHighPtMuon"],
        hlt2_filter_code=["Hlt2QEE_ZToMuMu_SingleNoMuIDFull"],
        monitoring_variables=("pt", "eta", "n_candidates"),
    )

总结

开发HLT2和/或Sprucing的触发线路需要考虑诸多因素，本课程旨在全面阐释这些条件，但无法涵盖所有内容。在开发过程中，若遇到本文档未给出满意解答的问题，可向相关的RTA/DPA工作组联络人咨询，他们至少能为您指引相关的专家团队。 (当然，非常欢迎对本课程提出补充/修改建议！)

---

1. 从技术角度而言，通过每个阶段的选择线路并非保存事件的唯一方式。在数据采集过程中，无论事件本身的信息如何，都有很小的概率保留事件。这些数据通常称为"直通"或"无偏"数据流，用于为编写当前触发器时未考虑/无法实现的未来研究思路提供无偏研究依据。 ↩