Draft.

This is an attempt to improve PyCBC Live's behavior in the presence of occasional quirks with frame files. It addresses #4800.

Standard information about the request

This is an improvement on existing behavior which could arguably be considered a bugfix. In normal observing conditions, this should bring no functional change.

This change affects the live search.

This change changes the low-latency frame file reading algorithm.

This change leads to a minor API breakage in the pycbc.frame module by occasionally changing the return value of a method.

Motivation

Before this change, the StrainBuffer class tries to read the strain channel first, and then it reads the state vector to check if the data is actually analyzable. We recently became aware that the strain channel may be entirely missing from the frame files when a detector is not in observing mode. With the existing code, this causes a repeated failure in reading h(t), which the code interprets as the frame files being absent, causing it to wait for the expiration of the frame file timeout. This behavior is not the most desirable: the strain channel is never going to appear, so the end effect is that the latency of the search in the other detectors is increased for no useful purpose.

Contents

The correct fix would be to catch the reading errors in a way that distinguishes between the frame files being absent, and the channel being absent. I am not doing this here for now, as I am not sure how to do it yet. I might look into this as a second step.

Instead, I am changing the order of the operations so that StrainBuffer reads the state vector first. Only if the state vector indicates usable data, then StrainBuffer proceeds to read h(t) as well. I think this is the most logical behavior, and it should effectively address the issue, assuming that the strain channel is only absent when the detector is not observing. If that assumption is violated (which would indicate a problem on the data generation side, upstream of PyCBC Live) then the code would still reach the frame file timeout, i.e. continue to behave as it currently does. As indicated above, I might address this too in a second step, or maybe in a followup PR.

GIven that checking the state vector is now the first operation, the burden of handling frame file timeouts moves from the StrainBuffer to the corresponding StatusBuffer. This adds a bit of complication to the PR.

Links to any issues or associated PRs

This addresses issue #4800.

Testing performed

Not tested yet, just a draft.

Additional notes

None.

• The author of this pull request confirms they will adhere to the code of conduct