Make JD timestamps in all files barycentric-corrected.

[scfleming]

JD timestamps should be expressed as BJD_TDB time standard. An (IDL-based) explanatation of this can be found here: http://astroutils.astronomy.ohio-state.edu/time/

There must be a python package that can do this accurately, perhaps even in the astropy package.

[cmillion]

Relevant: http://hoggresearch.blogspot.com/2011/04/barycentric-time.html

[cmillion]

A jumping off point: http://trac.astrometry.net/browser/trunk/projects/time-domain/bmjd.py

[cmillion]

There is no simple way to do this. I found a number of half solutions, but none that can be quickly adapted for our purposes. There is discussion about adding this into AstroPy (assuming Earth as the object), but they haven't been implemented. And Lang's code has substantial bit rot (mostly because the horizons package doesn't appear to exist anywhere).

I'm confident that I can do this either by writing my own interface to Horizons to get the ephemerides or by building on one of the partly finished ones (like https://github.com/mihok/horizon-jpl and https://gist.github.com/Juanlu001/5944478). Keeping with our philosophy of only requiring mature package dependencies would suggest that I do the former with the option of maybe subbing in an astropy solution if one ever comes about.

I suggest that we bump this from v1.20 into its own milestone, though.

[scfleming]

Agreed, let's push this to a future build.

[scfleming]

This link: http://lcogt.net/observatory/data/pipeline/time-corrections/ plus the two papers listed below, are good references to the problem.

[scfleming]

Astropy v1.2 has barycentric corrections now, which we might be able to use as a jumping off point if we want to try to correct to BJD rather than JD times (http://docs.astropy.org/en/latest/time/index.html#time-light-travel-time):

Barycentric and Heliocentric Light Travel Time Corrections The arrival times of photons at an observatory are not particularly useful for accurate timing work, such as eclipse/transit timing of binaries or exoplanets. This is because the changing location of the observatory causes photons to arrive early or late. The solution is to calculate the time the photon would have arrived at a standard location; either the Solar system barycentre or the heliocentre.

Suppose you observed IP Peg from Greenwich and have a list of times in MJD form, in the UTC timescale. You then create appropriate Time and SkyCoord objects and calculate light travel times to the barycentre as follows:

from astropy import time, coordinates as coord, units as u ip_peg = coord.SkyCoord("23:23:08.55", "+18:24:59.3", ... unit=(u.hourangle, u.deg), frame='icrs') greenwich = coord.EarthLocation.of_site('greenwich') times = time.Time([56325.95833333, 56325.978254], format='mjd', ... scale='utc', location=greenwich) ltt_bary = times.light_travel_time(ip_peg) If you desire the light travel time to the heliocentre instead then use:

ltt_helio = times.light_travel_time(ip_peg, 'heliocentric') The method returns an TimeDelta object, which can be added to your times to give the arrival time of the photons at the barycentre or heliocentre. Here, one should be careful with the timescales used; for more detailed information about timescales, see Time Scale.

The heliocentre is not a fixed point, and therefore the gravity continually changes at the heliocentre. Thus, the use of a relativistic timescale like TDB is not particularly appropriate, and, historically, times corrected to the heliocentre are given in the UTC timescale:

times_heliocentre = times.utc + ltt_helio Corrections to the barycentre are more precise than the heliocentre, because the barycenter is a fixed point where gravity is constant. For maximum accuracy you want to have your barycentric corrected times in a timescale that has always ticked at a uniform rate, and ideally one whose tick rate is related to the rate that a clock would tick at the barycentre. For this reason, barycentric corrected times normally use the TDB timescale:

time_barycentre = times.tdb + ltt_bary

[cmillion]

Interesting. It looks like they don't have any support for spacecraft observations. This was the real bottleneck before, because getting the appropriate ephemeris required some archaic telnet machinations to the JPL Horizons server.

[scfleming]

There might be an API to JPLEPHEM or Horizons server somewhere outside this package, I haven't looked, but it's probably a common request.

[cmillion]

I just did a quick search and confirmed that the situation seems to still be basically where it was a few years ago, which is that there are a few undeveloped packages with the intention of being Python API's to Horizon, but none with any kind of maturity. A very recent post on StackExchange suggests just using telnet machinations.