Skip to content
Snippets Groups Projects

Optimize line subtraction median array length updates for high latency

In order to mitigate "oversubtraction" of spectral lines and the unwanted narrow-band impact on nearby frequencies in h(t), we use a rather long (4096 seconds) running median to estimate the TFs used to reconstruct the subtraction signal from the witness channels. However, at times when those TFs undergo significant secular change (e.g., thermalizations at the beginnings of lock stretches), this could lead to ineffective subtraction. Therefore, we use a method that detects secular changes in the TFs and adjusts the length of the median accordingly. During stable times, the full 4096s are used. When significant secular change is detected, this is temporarily reduced to 128s. Once the TFs become stable again, the median grows until it again reaches 4096s.

It occurred to me that, when I first implemented this method, I assumed that it would only be used in low latency. This means that, when the running median is shortened to 128s, it uses only the most recent 128s of data, dropping older data. In high latency, since we use future data to estimate TFs, this is not desirable behavior. In this case, we want to retain the oldest data in the running median; that is, the data that is temporally closest to the data we are subtracting. This MR should ensure that, regardless of whether we are doing low-latency or high-latency subtraction, the data that is retained in the running median during these times is the appropriate data.

Here is an example of a time at H1 when there were several thermalizations during which the line subtraction running medians were temporarily shortened due to secular changes. Here is a spectrogram from before the fix: H1_DCS-CALIB_STRAIN_NOLINES_spectrogram_10-1000Hz_1410805216-30102_beforefix Here is a spectrogram from the same stretch of data calibrated (and line subtracted) with this update: H1_DCS-CALIB_STRAIN_NOLINES_spectrogram_10-1000Hz_1410805216-30102

If carefully compared, an improvement can be seen in the 15-20 Hz region.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply
Loading