LALFrame returning one too few samples for non-integer-sample-rate start and duration
LALFrame seems to be dropping one sample at the end of a series when the start time of a request doesn't correspond to exact sample times (but the end time does).
Consider the following example:
- Channel: H1 h(ft)
- Sample rate: 16384 Hz
- GPS start time: 1381161647.6709 (provided by the user)
- Duration: 0.3291 ('to the end of the GPS second')
For this request the GPS interval of interest is [1381161647.6709, 1381161648.0).
However, given that the start time doesn't correspond to the time of an actual sample the actual returned interval should either start at 1381161647.670898432 (the sample before the given start time) or 1381161647.670959467 (the sample after).
However however, the end time of the request (given start + duration) does correspond to a sample time, so I would (perhaps naively) expect that to be respected.
So, with that logic (such as it is), the returned interval should either be
-
[1381161647.670898432, 1381161648.0), or [1381161647.670959467, 1381161648.0)
However, what is returned is actually [1381161647.670898432, 1381161647.999938959), i.e. rounding down to the sample immediately before the given GPS start time, not changing the duration, and then not returning the sample at 1381161647.999938959 which was inside the original requested GPS interval.
This can be seen using lalfr-stream:
$ lalfr-stream --frame-glob /ceph/mirror/frames/O4/hoft_C00/H1/H-H1_HOFT_C00-138/H-H1_HOFT_C00-1381158912-4096.gwf --channel H1:GDS-CALIB_STRAIN --start 1381161647.6709 --duration 0.3291
1381161647.670898432 1.48971851759985e-19
1381161647.670959467 1.52727804250614e-19
...
1381161647.999816889 4.99947215947662e-19
1381161647.999877924 5.01380915601143e-19One might expect to see one more data point here:
1381161647.999938959 4.93498923674786e-19I'm not really sure what the 'right' answer is here, but wanted to post in any case to see what other people think.
cc @jolien-creighton @ed-maros (LALFrame experts)