Looks like there is an OBO error in `tess_cloud.cutout_asteroid`

[christinahedges]

I think I'm finding an OBO error in tess_cloud.cutout_asteroid.

Either it's an OBO error in the column position, or it's an OBO error in time. Below is an example.

I'm also finding that the times in tess_cloud.cutout_asteroid do not match the times from TESSCut.

from tess_cloud import cutout_asteroid
import lightkurve as lk
import matplotlib.pyplot as plt

tpf = cutout_asteroid("3166")
stpf = lk.search_tesscut('358.6895230830988 -9.942252118010982', sector=2).download(cutout_size=(10, 10), quality_bitmask=None)

idx = 499

# TESS Cut
plt.figure()
plt.pcolormesh(stpf.column + np.arange(10), stpf.row + np.arange(10), stpf.flux[idx].value, vmin=0, vmax=500, cmap='viridis')
plt.gca().set_aspect('equal')
plt.title(f'TESSCut TPF\nTime: {stpf.time[idx].value}')

#tess_cloud
jdx = 100 
plt.figure()
plt.pcolormesh(c[jdx] + np.arange(10), r[jdx] + np.arange(10), tpf.flux[jdx].value, vmin=0, vmax=500, cmap='viridis')
plt.gca().set_aspect('equal')
plt.title(f'Moving TPF\nTime: {tpf.time[jdx].value}')

#tess_cloud
jdx = 99
plt.figure()
plt.pcolormesh(c[jdx] + np.arange(10), r[jdx] + np.arange(10), tpf.flux[jdx].value, vmin=0, vmax=500, cmap='viridis')
plt.gca().set_aspect('equal')
plt.title(f'Moving TPF\nTime: {tpf.time[jdx].value}')

[barentsen]

Good news: the off-by-one error in the pixel position should be solved via #8.

Regarding the time error: there is indeed a ~70 second mismatch between the times reported by TessCut and those populated by tess-cloud. The underlying reason is that TessCut uses BTJD values obtained from the TSTART and TSTOP header keywords in the FFI headers (i.e. time = (TSTART + TSTOP) / 2), whereas tess-cloud has been using the ISO UTC timestamps obtained from the DATE-OBS and DATE-END header keywords.

Using AstroPy/Lightkurve to convert DATE-OBS into TSTART yields a ~70 second error, which is the root cause of the time mismatch issue:

>>> import lightkurve as lk
>>> from tess_cloud import list_images
>>> hdr = list_images(sector=2)[0].read_header()

>>> tstart_from_utc = Time(hdr["DATE-OBS"], scale="utc", format="isot").btjd
>>> tstart = hdr["TSTART"]
>>> (tstart - tstart_from_utc) * 24 * 60 * 60
69.18435380575829

There are several possible solutions to fix this mismatch, but I would like to fix/understand the conversion error first. It is no doubt related to the conversion from/to UTC.

...to be continued.

[barentsen]

In the example above, replacing
tstart_from_utc = Time(hdr["DATE-OBS"]).btjd
with
tstart_from_utc = Time(hdr["DATE-OBS"]).tdb.btjd
resolves the offset.

The caveat is that AstroPy time objects make a distinction between a time's format (e.g. ISO, JD, MJD) and its scale (e.g. UTC, TDB). This can be confusing because the acronym "BTJD" refers both to a format (TJD) and to a scale (TDB), but it is implemented as an AstroPy time format.

...to be continued.

[barentsen]

I believe the time inconsistency will be addressed via lightkurve/lightkurve#1112

(to do: verify the fix)

[barentsen]

Update: #1112 was merged a few days ago and will be part of Lightkurve v2.0.11.