gAperture returns photons that are gapped and non-monotonic in time

[dmopalmer]

When I use gAperture to retrieve photons, those photons have the following behavior:

1a) A block of photons from t0 to t0+~80s 1b) A block of (a smaller number of photons) photons, also from t0 to t0+~80 a gap in time of ~40 s 2a) A block of photons from t0+~120 to t0+~200s 2b) A block of (a smaller number of photons) photons, also from t0+~120 to t0+~200 a gap in time of ~40 s etc.

There may be some reason why the data look like that (e.g. GALEX has a 2-minute data accumulation cycle and its buffers tend to get full after 80 s), but I am unfamiliar with its mode of operations and data formats and don't know how to check that.

Replication code:

import numpy as np
import matplotlib.pyplot as plt

# install gPhoton and gatspy with pip
from gPhoton import gAperture

# Boyajian's star
target = 'KIC8462852'
ra = 301.5644
dec = 44.45684

# representative time range
trange = [995690600.0, 995691000.0]

step_size = 20. # the time resolution in seconds
phot_rad = 0.0045 # in deg
ap_in = 0.0050 # in deg
ap_out = 0.0060 # in deg

aperture_result = gAperture(band='NUV', skypos=[ra, dec], stepsz=step_size, radius=phot_rad,
                              annulus=[ap_in, ap_out], verbose=3, csvfile=target+ "_lc.csv",
                              trange=trange,
                              overwrite=True)

photons = aperture_result['photons']

assert np.all(photons['flag'] == 0)
t = photons['t']

plt.plot(t,',')
plt.ylabel("Time")
plt.xlabel("Photon index")
plt.title("Photon times are gapped and non-monotonic")
plt.savefig("/tmp/jumpback.png")

[scfleming]

This sounds like it might be an observation done in "petal pattern", a mode of dithering the spacecraft that often operated at these time scales, but we'll investigate. In general, it is expected to have multiple gaps during an observation where no photon events are recorded.

[cmillion]

Yes. This observation appears to be in "petal pattern" mode. In this mode, the detector bore sight was shifted slightly ~12 times during an eclipse to spread the (possibly detector-damaging) flux from bright sources out around the detector more. In theory, petal pattern mode would be indistinguishable in terms of effective exposure time from normal MIS "dither" mode visits of ~1600s depth. In practice, and for reasons that I was never able to identify or fix in the original software, the mission pipeline was unable to get any sort of astrometric lock during the fast slews in between each petal with which to generate a refined aspect solution. Hence, there is no refined aspect solution during those slews, and gPhoton does not return photons observed during those time periods, leading to the cadence that you've observed. gPhoton uses the aspect table as an input to the exposure time calculation, so these gaps are correctly accounted for

You can see the petal pattern in detector space with plt.plot(aperture_result['detxs'],aperture_result['detys'],'.') or by plotting the photon 'xi' and 'eta' positions.

Petal pattern observations are not as easy to analyze for sub-visit variability for two reasons: (1) the cadence issue as noted, and (2) the jump in detector-space comes with a corresponding jump in relative response / flat field, and unknown-unknowns in the GALEX flat can create false variability. (Which is identifiable as a correlation between the variation observed and detector position, e.g. 'detrad.') For normal dither mode data, this false variability also tends to be pretty regular and periodic, so it's potentially sort of correctable or filterable post hoc; petal pattern doesn't have that. It's still possible to use petal pattern for sub-visit studies, but I would be especially careful about interpreting as real any variability that wasn't absolutely obvious. (e.g. I'd probably want several unflagged light curve bins >3 sigma.)

It might be possible to generate new aspect corrections to recover the "lost" exposure time during the slews, at least well enough to do photometry with large apertures. It's a long term goal of mine, but I don't currently have time or support to work on it. If someone else wants to try, that would be great. I can explain how I'd start.

[dmopalmer]

That explains the gaps.

This particular data does show a petal pattern (xi,eta data in a dozen blobs around a circle, where each blob is a different block of photons from 80 second of a 120 s interval, with slow movement within the blob.)

What causes the a,b blocks where each time interval is followed by the same time interval with fewer photons? Are they, perhaps, the aperture vs. annulus events for each 120 s pointing? (And if so, is there some flag in the result to let me split them?)

[cmillion]

There's nothing I can think of that would be an obvious cause of that, but the code doesn't enforce time-orderedness in the photons anywhere as far as I recall because it would add a little bit of overhead to do it on the server-side (in SQL) and you can just do a pretty fast np.sort() on the client side if you want that behavior.

There are no aperture vs. annulus flags. The photon list includes every event within the outer edge of the background annulus and requested time ranges. If you want to separate by aperture vs. annulus, you should do a cut based on angular separation from the target position (skypos). For an example, this is done in code in the quickmag() function in curvetools.py.