Repository navigation
Looks like there is an OBO error in tess_cloud.cutout_asteroid #4
Description
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}')
Activity
barentsen commentedon Jul 20, 2021
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
TSTARTandTSTOPheader keywords in the FFI headers (i.e.time = (TSTART + TSTOP) / 2), whereas tess-cloud has been using the ISO UTC timestamps obtained from theDATE-OBSandDATE-ENDheader keywords.Using AstroPy/Lightkurve to convert
DATE-OBSintoTSTARTyields a ~70 second error, which is the root cause of the time mismatch issue: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 commentedon Jul 20, 2021
In the example above, replacing
tstart_from_utc = Time(hdr["DATE-OBS"]).btjdwith
tstart_from_utc = Time(hdr["DATE-OBS"]).tdb.btjdresolves 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 commentedon Jul 21, 2021
I believe the time inconsistency will be addressed via lightkurve/lightkurve#1112
(to do: verify the fix)
barentsen commentedon Jul 27, 2021
Update: #1112 was merged a few days ago and will be part of Lightkurve v2.0.11.