SGNL: Scalable Low-Latency Gravitational Wave Detection Pipeline for Compact Binary Mergers

TL;DR

SGNL tackles the need for fast, scalable low-latency gravitational-wave detection by reimplementing GstLAL’s core matched-filtering in a Python-based streaming framework (SGN) and leveraging GPU-accelerated, tensorized LLOID filtering with SVD-bank compression. The paper introduces pre-synchronization of time slices and multidimensional filtering to minimize latency, while preserving sensitivity and reliability demonstrated in a 40-day Mock Data Challenge. Key findings include a median GraceDB latency of $5.4$ s (a $42\%$ improvement over GstLAL’s $9.3$ s) and sensitivity comparable to GstLAL within statistical and systematic uncertainties, using a single checkerboard in the MDC. The SGNL platform offers a sustainable, extensible path toward broader parameter-space coverage and potential incorporation of ML techniques, enabling rapid, multi-detector gravitational-wave alerts for enhanced multi-messenger astronomy.

Abstract

We present SGNL, a scalable, low-latency gravitational-wave search pipeline. It reimplements the core matched-filtering principles of the GstLAL pipeline within a modernized framework. The Streaming Graph Navigator library, a lightweight Python streaming framework, replaces GstLAL's GStreamer infrastructure, simplifying pipeline construction and enabling flexible, modular graph design. The filtering core is reimplemented in PyTorch, allowing SGNL to leverage GPU acceleration for improved computational scalability. We describe the pipeline architecture and introduce a novel implementation of the Low-Latency Online Inspiral Detection algorithm in which components are pre-synchronized to reduce latency. Results from a 40-day Mock Data Challenge show that SGNL's event recovery and sensitivity are consistent with GstLAL's within statistical and systematic uncertainties. Notably, SGNL achieves a median latency of 5.4 seconds, a 42\% reduction compared to GstLAL's 9.3 seconds.

Figures (8)

• Figure 1: Workflow of the SGNL online inspiral pipeline. Data from multiple detectors are read in a single source element, including both strain and state vector channels. Invalid segments flagged by the state vector are gated from the strain data. The PSD is estimated, and data are whitened. Noise transients above a threshold are gated out. Conditioned data are synchronized across detectors and transferred to the GPU if in GPU mode. Each detector’s data are matched-filtered with a pregenerated SVD bank to produce SNR time series. SNR peaks are identified as triggers and combined into coincident events across detectors. Likelihood ratios and FAR are computed. Non-coincident triggers form background data and are saved to disk. The best events are sent to Kafka for aggregation and GraceDB alerts. Event candidates are saved to an SQLite database on disk.
• Figure 2: Overlapping and windowing scheme used in the PSD estimation and whitening process, including the behavior around a gap in the input data. In this example, N is set to four seconds of samples, and Z is set to one second. The top panel shows a simulated white noise input stream with a one-second gap between 0 and 1 second. Colored rectangles indicate six consecutive processing iterations (blue, orange, green, red, purple, and brown). Each two-second input block is multiplied by a Hann window of the same color (second panel), zero-padded to form a four-second FFT block, and transformed to estimate the PSD. The second panel illustrates the overlapping Hann windows, which sum to unity, while the third panel shows the overlapping Tukey windows applied after whitening and inverse FFT. The final panel shows the whitened output of each iteration, each lagging the input by two seconds, corresponding to the two-second latency introduced by the four-second FFT length configuration.
• Figure 3: Workflow of the whitening and PSD estimation in SGNL. Input data are first multiplied by a zero-padded Hann window, and an FFT is performed. Unlike GstLAL tsukada2017, downsampling is applied after the FFT, where high-frequency components are removed in the frequency domain. The resulting data are used both to generate the whitened output and to update the running PSD estimate. After whitening with the latest PSD, an inverse FFT is applied, followed by a Tukey window. The processed block is then combined with results from previous iterations using overlap-add, and the portion that no longer overlaps is output as the final whitened data.
• Figure 4: Diagram of the LLOID algorithm pipeline. The time evolution of the latest data sample at each processing stage is indicated alongside the transition arrows. Whitened data are downsampled to match the sample rates of each SVD bank. After downsampling, the output lags the input by $N_{\mathrm{down}}/f$ seconds. Each time slice is then filtered using the appropriately delayed, downsampled data, with an additional shift equal to the upsampling kernel length. Following filtering, the output timestamp is advanced by the time delay associated with that slice. The filtered outputs are multiplied by the SVD reconstruction matrices to produce the physical SNR streams at each sample rate. The lowest-rate SNR stream is recursively upsampled and added to the higher-rate streams, where each upsampling stage introduces a latency of $N_{\mathrm{up}}/f$ seconds. This pre-synchronization of delays and time shifts ensures that the upsample-and-add process remains fully aligned, eliminating additional buffering and enabling the LLOID algorithm to operate with zero latency.
• Figure 5: Overlapping and streaming behavior during the trigger and coincidence identification stage. Blue, orange, and green rectangles indicate iterations 0, 1, and 2 of the pipeline, respectively. Shaded regions mark the trigger-finding windows, and cross-hatched regions show the padding regions used for the $\xi^2$ calculation (350 samples in this example, corresponding to an autocorrelation length of 701 samples). The trigger-finding windows overlap by the sum of the maximum light-travel time between detectors (0.0273 s for an LIGO Hanford (H), LIGO Livingston (L), and Virgo (V) search) and a 0.005 s coincidence buffer. Each trigger finding window therefore spans one second plus the overlap interval. Input data are in one-second strides, thus the first window is shortened to produce output as soon as data become available, minimizing additional latency.