Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precision on timestamps in Tess data #18

Open
benmontet opened this issue Sep 5, 2019 · 6 comments
Open

Precision on timestamps in Tess data #18

benmontet opened this issue Sep 5, 2019 · 6 comments
Assignees
Labels
bug Something isn't working Priority: Medium Needs to be implemented, but not immediately

Comments

@benmontet
Copy link

Hello!

We've come across an issue in the timestamps in TessCut frames (TessCut is a wonderful service, by the way!)

When I look the astrocut file timestamps, there is a digitization that I can see in them when we plot the difference in time between consecutive frames. We think this is a floating point rounding error in the timestamps, somewhere they are being stored as 32-bit floats and since the time values have four digits before the decimal place, this limits the precision to ~10 seconds on any individual data point.

You can see what I mean in figure form at afeinstein20/eleanor#119. The code to reproduce this is below:

tc = fits.open('tess-s0001-4-3_97.842681_-68.044906_10x15_astrocut.fits')
plt.plot(np.diff(86400*tc[1].data['time']), '.')
plt.ylim(1795, 1805)
plt.xlabel('Cadence', fontsize=20)
plt.ylabel('Delta Time (sec)', fontsize=20)

image

The TASOC light curve times look proper, so we think it's a processing issue along the way rather than the way the telescope is recording data. If you think it's something upstream from astrocut where the bug is then I'm happy to work my way up the chain until we figure out where this is being induced.

Thanks so much!
Ben

@ceb8
Copy link
Collaborator

ceb8 commented Sep 12, 2019

Thanks for pointing this out!

Can you just clarify what you would expect to see if this bug was not present?

@ceb8 ceb8 self-assigned this Sep 12, 2019
@ceb8 ceb8 added bug Something isn't working Priority: Medium Needs to be implemented, but not immediately labels Sep 12, 2019
@benmontet
Copy link
Author

Yes of course! If the bug weren't present, the difference in time between cadences should be nearly constant. In the frame of the spacecraft, they should be exactly constant, plus then there will be a smooth correction due to changes in barycentric correction as the spacecraft orbits the earth---and there shouldn't be any structure on shorter timescales.

Here's a plot for two minute data binned down to 30 minute cadence. Note the y-scale, the change over an orbit is only 0.005 seconds or so!

image

@ceb8
Copy link
Collaborator

ceb8 commented Sep 20, 2019

Great, thanks! I'll put this on my list of things to fix.

@danhey
Copy link

danhey commented Jul 3, 2020

Hi @ceb8, just wondering if there's been any progress on this?

@ceb8
Copy link
Collaborator

ceb8 commented Jul 10, 2020

@danhey There has not been. Apologies. It's still on my list, I promise.

@ceb8
Copy link
Collaborator

ceb8 commented Aug 2, 2020

@danhey This is fixed in the code and on master, but it hasn't bubbled up to TESScut yet. Also, because of where the bug was, I will have to go back and fix all existing TESS FFI cubes on our systems, which will take a bit. I will keep you updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Priority: Medium Needs to be implemented, but not immediately
Projects
None yet
Development

No branches or pull requests

3 participants