[論文レビュー] arXiv : Track Reconstruction in the ALICE TPC using GPUs for LHC Run 3

D. Røhr, Marten Ole Schmidt+2 more|arXiv (Cornell University)|Nov 28, 2018

Particle physics theoretical and experimental studies参考文献 7被引用数 6

ひとこと要約

本論文は、LHC Run 3におけるALICEの50 kHz継続的Pb-Pb衝突率下で、リアルタイムかつ高スループットなトラッキングを実現するため、OpenCLおよびCUDAを活用したGPUアクセラレーションを施したTPCトラック再構築アルゴリズムを提示している。この手法は、時間的・空間的依存性を持つキャリブレーションおよびエントロピー最適化リフィットを統合することで、オンライン処理制約を満たしつつオフライン品質の分解能を実現し、20倍のデータ圧縮と1ミリメートル未満の分解能を達成した。

ABSTRACT

In LHC Run 3, ALICE will increase the data taking rate significantly to continuous readout of 50 kHz minimum bias Pb-Pb collisions. The reconstruction strategy of the online offline computing upgrade foresees a first synchronous online reconstruction stage during data taking enabling detector calibration, and a posterior calibrated asynchronous reconstruction stage. We present a tracking algorithm for the Time Projection Chamber (TPC), the main tracking detector of ALICE. The reconstruction must yield results comparable to current offline reconstruction and meet the time constraints like in the current High Level Trigger (HLT), processing 50 times as many collisions per second as today. It is derived from the current online tracking in the HLT, which is based on a Cellular automaton and the Kalman filter, and we integrate missing features from offline tracking for improved resolution. The continuous TPC readout and overlapping collisions pose new challenges: conversion to spatial coordinates and the application of time- and location dependent calibration must happen in between of track seeding and track fitting while the TPC occupancy increases five-fold. The huge data volume requires a data reduction factor of 20, which imposes additional requirements: the momentum range must be extended to identify low-$p_{ m{T}$t looping tracks and a special refit in uncalibrated coordinates improves the track model entropy encoding. Our TPC track finding leverages the potential of hardware accelerators via the OpenCL and CUDA APIs in a shared source code for CPUs, GPUs, and both reconstruction stages. Porting more reconstruction steps like the remainder of the TPC reconstruction and tracking for other detectors will shift the computing balance from traditional processors to GPUs. We give an overview of the foreseen tracking in Run 3 and discuss the track finding efficiency, resolution, treatment of continuous readout data, and performance on processors and GPUs.

研究の動機と目的

• LHC Run 3の50 kHz継続的Pb-Pb衝突率下で、ALICEのTPCにおけるリアルタイムで同期されたオンライントラッキングを実現すること。
• 現在のハイレベルトリガー（HLT）と同等の厳しい時間制約を満たしつつ、オフライン品質のトラック分解能を達成すること。
• オンライン再構築パイプラインに、時間的・空間的依存性を持つキャリブレーションなどの欠落していたオフライン機能を統合すること。
• TPCの占有度が5倍に上昇し、重複衝突が生じる状況下でも、データ量を20倍に圧縮すること。
• CPUおよびGPUの両方で実行可能であり、オンラインおよびオフライン再構築段階をカバーする、OpenCLおよびCUDAを用いた統合型ソフトウェアスタックの開発

提案手法

• 既存のHLTオンライントラッキングパイプライン（セルフオートマトンおよびカルマンフィルタベース）に、オフライン品質のキャリブレーションおよび分解能向上を追加する。
• 重複するイベントに対応するため、トラックシーディングからトラックフィッティングまでのパイプラインで、座標変換および時間的・空間的依存性を持つキャリブレーションを実施する。
• 高占有度状態下での低-$p_{\rm T}$ループトラックの同定を可能とするために、運動量範囲を拡張する。
• トラックモデルのエントロピー符号化と再構築忠実度を向上させるために、キャリブレーション未適用座標での特別なリフィットを導入する。
• OpenCLおよびCUDA APIを用いて、CPUおよびGPUの両方で実行可能な共有ソースコードベースを実装し、ハードウェア間での移植性とパフォーマンスの移植性を確保する。
• 将来的に、TPCのフル再構築や他の検出器のトラッキング処理などの追加ステップのGPUへの移行を想定し、GPU中心のコンピューティングを指向する再構築パイプラインを設計する。

実験結果

リサーチクエスチョン

• RQ1 ALICEのRun 3において、50 kHz継続的衝突率下でオンラインTPCトラック再構築が、どのようにオフライン品質の分解能を達成できるか？
• RQ2 HLTの既存のセルフオートマトンおよびカルマンフィルタパイプラインに、オフライン品質のキャリブレーションおよび分解能を統合するために、どのような変更が必要か？
• RQ3 高占有度および重複衝突環境下でも、トラック再構築の正確性を保持しつつ、データ量を20倍に圧縮するにはどうすればよいか？
• RQ4 キャリブレーション未適用座標でのエントロピー最適化リフィットが、トラックモデル品質の向上に果たす役割は何か？
• RQ5 OpenCLおよびCUDAによるGPUアクセラレーションによって、オンラインおよびオフライン段階にわたりスケーラブルかつ統一された再構築が、どの程度実現可能か？また、将来的な検出器システムに対しても同様に適用可能か？

主な発見

• 提示されたトラッキングアルゴリズムは、HLTの厳しい時間制約を満たしつつ、オフライン品質の分解能を達成し、50 kHzでのリアルタイム処理を可能にした。
• オンラインパイプラインに時間的・空間的依存性を持つキャリブレーションを統合することで、高占有度状態下でもトラック再構築の正確性が顕著に向上した。
• 運動量範囲の拡張およびエントロピー最適化リフィットにより、20倍のデータ圧縮が達成され、低-$p_{\rm T}$トラックの同定が保持された。
• OpenCLおよびCUDAの使用により、CPUおよびGPU両方で実行可能な統合型ソフトウェアスタックが実現され、再構築段階全体にわたる移植性とスケーラビリティが確保された。
• アルゴリズムは、TPCトラッキングを越えて、ALICEのRun 3アップグレードにおける他の再構築ステップや検出器へのGPUアクセラレーションの拡張が可能であることを示した。
• パフォーマンスベンチマークの結果、GPUアクセラレーションにより、継続的データ取得に必要なスループットと遅延が達成され、計算ワークロードがGPU中心のアーキテクチャへシフトした。