Skip to content

Cluster best event each second

Timothy Davies requested to merge tdavies__cluster_best_each_second into spiir-O4-EW-development

Problem 1

Our current clustering code tries to cluster across multiple seconds. It effectively follows the single rule:
"Only select a trigger if there is no better trigger within the next second."

That has the consequence that if there is a chain of triggers, one after the other, second by second, that continuously increase in CohSNR, we won't select any until the end of the chain.

In principle that could reduce the number of uploads on the same event, but in practice it mostly reduces the amount of noise that we record, which confounds our theoretical ifar plots (which assume we select a trigger every second). In any event, if there were a real event causing triggers over several seconds and we could only upload one, we'd want to select the earliest significant trigger to minimize latency.

Besides that, it's ok to have a few uploads per event, especially if they're spaced out across multiple seconds and are continuously increasing in value. Preventing gracedb spam is more of a job for trigger_control, and even that seems to be insignificant.

Problem 2

The current clustering code also causes at least an extra second of latency. We start clustering only when we've collected enough data for the next 'clustering window'. But the clustering window is 1 second of data, just like the length of a buffer from postcoh.

So if the clustering window is lined up perfectly with our buffer, and the selected trigger is at the very start of the window, then we'll know that there's "no better trigger within the next second" and we can upload it.

But besides that edge case, we'll have to wait at least one additional second to collect data from the next second of buffers before 'selecting' the trigger.

Solution

Replace the clustering rule with
"Select the best trigger each second"

Code-wise there's a few more changes to make.

In combination with !171, we should have ifar plots that better match the theoretical line for poor fars. We should test on MDC and make sure we don't see large numbers of uploads for significant triggers.

Merge request reports