Account for barycentric time, light travel time, and spherical coordinates

[sefffal]

With high astrometric precision, we can no logner assume that the light we used to measure a position left the planet at the same time as the star.
Additionally, stars with significant motion the tangent plane approximation might break down.
Both of these effects should eventually be considered in the astrometry and image modelling codes.
They could be turned out automatically for a given star at the model creation stage.

[gotten]

https://github.com/sefffal/Octofitter.jl/blob/19cd9e74c763d6f75f056dfef9dc98efebfc39ca/OctofitterRadialVelocity/src/harps_dr1.jl#L11C9-L11C15

This wishlist item is (kind of) connected to the following inconsistency I noticed. There is currently an difference between the time systems used between the two HARPS RV sources that can be retrieved by the code. The code above uses (geocentric) mjdobs and the RV databank retrieval code uses barycentric (~heliocentric) BJD. For typical directly imaged planets there should not be noticeable change in 8 minutes light travel time on the RVs but for stellar binaries or short period planets (e.g. transiting) this might give a noticeable mismatch between model and observations with a period of 1 year. The HARPS DR1 release also has a column with drs_bjd for the startpoint in BJD that could be used for consistency.

It's a tricky aspect of combining observations from multiple sources that I am still figuring out. So I can't recommend on the best practice yet. GRAVITY astrometric data only has MJD-OBS in the header and it doesn't represent the midpoint of the data collection but the startpoint. The OBs are also much longer than the maximum of 8 minutes of correction. Open question: Are midpoint BJDs most ideal or are startpoint MJD-OBS good enough?

(no need to answer just want to have it written down somewhere)

[sefffal]

Hi @gotten, thanks for your comments.
Binaries and transiting planets are definitely applications I want to support.

I'll adjust the HARPS DR1 code to use drs_bjd right away.

For GRAVIY, this is an issue that is front of mind at the moment. I would welcome suggestions on if and how we can get BJDs there too.

[sefffal]

There is a separate but closely related issue of travel time correction for the exoplanet and the star, which I calculated could make a noticeable difference for some GRAVITY observations.

To correct for that, I think we need a two step process:

1. Given parameters and an epoch $t$, calculate the planets $z$ position in AU vs. the star
2. Calculate the light travel time delta given that distance
3. Re-calculate the planet's location at $t+\Delta t$.

One would have to iterate that procedure to get it perfect, but I expect that a single step is sufficient in all practical cases.

[sefffal]

I see three main remaining items here:

• [] Implement light travel time correction for planets
• [] Implement light travel time correction for stars due to the reflex motion of a planet
• [] Correct planet calculations for spherical coordinate

Most of these changes would go into PlanetOrbits.jl with a few changes here. They would only apply to AbsoluteVisual wrapped orbits.

The first two require the iterated Kepler solve, and some additional care when using eg solved position values for a planet to calculate the stars position (since they are no longer directly related due to different travel times.)

The coordinate correction is a more invasive change.
Formally, orbit properties like inclination, argument of periastron, and longitude of ascending node will now become defined as (i,omega,Omega) at a reference epoch tref.
Calculations of planet positions and velocities (posx, posy, posz, velx, vely, velz, radvel) would then take into account the shifted viewing angle of the system vs the reference epoch.
I think eg the radial velocity would just be multiplied by the cosine of the change in viewing angle.

These modifications would make Octofitter suitable for higher precision modelling of high RV / high proper motion stars, eg by transit timing.