Incorrect TIC ID returned using get_lightcurvefile

Problem description

When using lightkurve to retrieve TESS data, search_lightcurvefile (and search_targetpixelfile) return the wrong TIC ID, even when ‘TIC’ is included in the target name or when ‘TESS’ is specified as the mission.

Example

import lightkurve as lk
lk.search_lightcurvefile('TIC 734501845')

I get the following output:

SearchResult containing 3 data products.

target_name                     productFilename                     description  distance
----------- ------------------------------------------------------- ------------ --------
  350741703 tess2018263035959-s0003-0000000350741703-0123-s_lc.fits Light curves      0.0
  350741703 tess2018292075959-s0004-0000000350741703-0124-s_lc.fits Light curves      0.0
  350741703 tess2018319095959-s0005-0000000350741703-0125-s_lc.fits Light curves      0.0

Expected behavior

I expected to get light curve files for TIC 734501845, but I received a list of files for TIC 350741703.

Environment

• platform: Ubuntu 19.04
• lightkurve version: 1.2.0
• installation method: conda

[barentsen]

I am inclined to follow the philosophy that “every search is a cone search” (consistent with the MAST portal), and teach users how to mask the search result if further filtering is required. I think it’s easier to explain and document.

Similar to Gully’s example, this would’ve worked if a target had been observed under the identifier TIC 734501845:

import lightkurve as lk
search = lk.search_lightcurvefile('TIC 734501845')
search[search.target_name == '734501845'].download_all()

[scfleming]

This brings up an interesting decision for the lightkurve development: one could avoid this by using Observations.query_criteria() and matching directly on mission name and target names if given a KIC/EPIC/TIC ID, instead of doing a cone search. That would always provide the user with light curves or target pixel files for exactly that star ID only. But, if a user isn’t aware of a case where the mission’s data might be under a different ID than they expect, for whatever reason, then they would not discover that by doing a cone search. Perhaps the default of doing a cone search, but with a “–exact” option that would instead match directly on the IDs and not do a cone search could cover both scenarios, but may add more complexity than you want.