Closed gotten closed 8 months ago
Closed as no code changes are needed.
Should drop the following comment: https://github.com/wbalmer/backtrack/blob/930c57124dea87df3f73430150265ce07949746a/backtrack/backtrack.py#L177
Thanks for double checking this!
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?).
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.
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 inbacktrack
before callingapp_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.