Update interact.py

[vbkostov]

Some targets, including high-proper motion stars, show a mismatch between the cross-hair and the star's position on interact_sky(). The mismatch is also present for all or most of the nearby stars.

Examples include "duplicate" or "split" IDs (e.g. TIC 150391195), high-proper stars (e.g. TIC 228760807), and other targets that do not have duplicates, splits, or high proper motion (e.g. TIC 294183478).

This is a proposed solution, where interact.py uses the GaiaDR3 catalog instead of the GaiaDR2 catalog to plot stars' positions, both for TESS and for Kepler/K2. The result is an effectively exact match between the cross-hair and the target's position for low proper-motion stars, and much closer match for high-proper motion stars.

Also, the proper motion correction is not applied due to a bug. This is now fixed and the correction is properly implemented.

[christinahedges]

@vbkostov this is a great PR, if you can add in KIC/EPIC and make sure the proper motion is applied I'll review again!

[gully]

Nice! 👍

[orionlee]

I apologize for the belated reply.

• The crux of the fix for the cross-hair is to use the Gaia DR3's proper motion, instead of the proper motion embedded in the tpf file.

  • it'll work for most cases, but for the case that the closest Gaia DR3 match is not the target, the cross-hair will probably off in some weird way, as it's based on coordinate of the tpf file, but corrected by the proper motion of a different star in from Gaia DR3.
  • Overall, it's probably better than the current solution, but I want to call it out just in case.

• Regarding the source of Gaia DR3, it is changed from the mirror in Vizier to MAST.

  • what would be the reason of the switch? If the goal is just using Gaia DR3, replacing I/345/gaia2 with I/355/gaiadr3 should suffice.
  • If there are reasons to switch away from Vizier, consider to use the official ESA source, e.g., via https://astroquery.readthedocs.io/en/latest/gaia/gaia.html . I recall some time back someone from astroquery suggested us use ESA rather than the mirrors.
    • It wasn't done because it was not a priority. Additionally, using Vizier could make codes easier if we ever expand to support the plotting from multiple catalogs (there was a suggestion of plotting both Gaia and VSX some time back).

• Testing: it'd be great if we have the results of at least 3 targets (each of TIC, KIC, EPIC) posted to the PR.

[orionlee]

Some targets, including high-proper motion stars, show a mismatch between the cross-hair and the star's position on interact_sky().

A second thought, I wonder if we should allow the mismatch between cross-hair and the star's position, as the current cross-hair accurately reflects the position used by the mission operation. Any mismatch could help to diagnose some problems.

For example, I just came across TIC 464378628, a star with very high proper motion (~2600 mas/yr in GAIA, but has no proper motion data in TIC catalog.

The cross-hair is off by about 1 pixel from the actual star position (red arrow above).

In this case, the mismatch helped me to identify some of the issues associated with SPOC lightcurves / TCEs.

1. The TCEs (e.g., sector 66 TCE1) consistently produces a red flag on TIC centroid offset TicOffset-rm. Upon seeing the SkyView above, I realized that the warning is not an issue, because the TIC position used by TCEs is the inaccurate crosshair, i.e., one without proper motion.
2. It also made me realize because of the inaccurate TIC position used, the aperture used is also slightly off.

---

The comparable Swarthmore Finding Chart also uses the logic similar to the current one, i.e., it surfaces the mismatch. It does show a warning "TIC entry matching entered name is not closest to the center coords."

---

A side note: for this target TIC 464378628, if one employs the logic proposed by this PR (plotting cross-hair based on the RA/DEC from the tpf file, with the proper motion of the closest Gaia entry), the cross-hair would still be way off (in a different direction).

[Nschanche]

@rebekah9969 is working on PR #1366 that will incorporate the PM for all targets in the TPF. This could be used to show both the fixed TIC location and the expected location at the time of observation.

[orionlee]

Nschanche, so is it the plan that once #1366 is done, it will replace the current search-neighbor-Gaia DR2 logic in interact.py?