Closed cmillion closed 6 years ago
The problem is related to `dbasetools.fGetTimeRanges' and has two components.
'fGetTimeRanges' queries the aspect solution tables to estimate the time ranges during which a specific source was "on" the actively observing detector (as defined by the detsize
parameter). You can pass a time range to it (as a two-element trange
) to limit the temporal extent of the search. This gets called when the skypos
parameter is passed to dbasetools.compute_exptime()
, which is how gAperture computes exposure time in a bin. But 'fGetTimeRanges' was not taking into account that the initial or final times of trange
might fall between two valid aspect timestamps, and so should be set as the true initial or final timestamps returned by 'fGetTimeRanges' always returned timestamps from the aspect file, so some fraction of a second could be missed on either side of each time bin.
The aspect solutions have one second resolution. fGetTimeRanges
fails to include the final second in a classic failure-to-include-the-edge style bug.
The exposure time calculation during light curve creation in v1.28.7 erroneously returns less exposure time in a bin than the equivalent call to
dbasetools.compute_exptime()
. The bug is testable / reproducible with the following code, in which all of theprint()
statements should return True.