Sanity check of Epoch transformation code & impact of use of JD_UTC instead of JD_TT

[gotten]

I sanity checked some of the lines calling NOVAS (because I always had a feeling of doubt regarding the Epoch transformation).

Good:

• app_star indeed uses ICRS @ epoch J2000.0 (see NOVAS user guide C3.1 section 3.3 and page C-59 for text that explicitly mentions this). Since Gaia DR3 is ICRS epoch J2016.0, we correctly transform the epoch only (transform_cat(option=1,...)) from ICRS J2016.0 to ICRS J2000.0 in backtrack before calling app_star. When Gaia DR4+ uses a different Epoch this hard-coded value needs to be updated.

Potential mistake that likely doesn't have a measurable impact:

• app_star wants JD TT (terrestrial time) as input. Unclear what Exogravity and other instruments use as definition; probably UTC, which is typically about a minute away from JD_TT. Considering we collect data over 1+ hours and just assign a single Julian Date this effect should be negligible. Could be interesting to calculate how much of a positional shift we would get at scales of 1 min - 1 hour - 1 day as a sanity check.

Issue can be closed without code change but I wanted to document this in a public place.

[gotten]

Closed as no code changes are needed.

[gotten]

Should drop the following comment: https://github.com/wbalmer/backtrack/blob/930c57124dea87df3f73430150265ce07949746a/backtrack/backtrack.py#L177

[wbalmer]

Thanks for double checking this!

[gotten]

Could be interesting to calculate how much of a positional shift we would get at scales of 1 min - 1 hour - 1 day as a sanity check.

I simulated the difference in observed separation between Barnard's star and a infinitely far background object 1" above it in mean coordinates at J2016.

Then I generated offsets for 1 second, 1 minute, 1 hour and 1 day later.

As expected, Barnard's star which has a pm of -10000 mas/year (in the fastest dimension) shows a shift in the separation between foreground and background object of about 20 microarcseconds in the fastest dimension, which is on par with 10000 mas/365.25/24/60.

A more typical object like Beta Pic in terms of PM and parallax shows a maximum shift of about 0.6 microarcseconds in 1 minute. In an hour it is almost noticeable at the best precisions of GRAVITY with a signal of 35 microarcsec per dimension. So approximating a full hour of observations with a single JD might not be ideal (depending on the signal we are looking for).

Also it is safer to implement the conversion from JD_UTC to JD_TT (TT = UTC + ΔAT + 32.184s) (see NOVAS user guide section 3.2 for more talk about this time difference) to make sure we are not impacted by this for the fastest moving stars.

astropy.time.Time(jd_utc,scale="utc",format="JD").tt.jd should give the correct jd_tt time for use with app_star. jd_utc's will come from our observations. For the JD_UTC corresponding with 2016.0 this should be 2457388.5 which converts to JD_TT 2457388.500789167, which is 68.184 seconds later (precise to microseconds according to astropy?).

[tomasstolker]

The Gaia query can return the ref_epoch of a target, so we could set the epoch that is needed for the transformation based on the value that is queried. Then it would only be needed to adjust the MAIN_GAIA_TABLE at the top of the file.