lightkurve icon indicating copy to clipboard operation
lightkurve copied to clipboard

Search_lightcurve produces results for two stars

Open bbrady-vassar opened this issue 1 year ago β€’ 4 comments

Problem description

In 2018, an astronomer named Ben found that searching for the star KIC 6507433 also produced results for KIC 006507427; this was brought up in issue #148 / #151. Today, a different astronomer named Ben is here to report a similar issue for the same star. What a coincidence!

Whereas the first Ben was trying to download KeplerTargetPixelFiles, I am trying to search lightcurves directly.

Example

from lightkurve import search_lightcurve
search_lightcurve('K03815.01', author="Kepler", cadence="long")

> SearchResult containing 31 data products.

This SearchResult includes quarters for both kplr006507427 and kplr006507433.

Other examples

Here is the full list of targets I've found that produce this problem:

  • Searching for K03815.01 produces results for kplr006507427 and kplr006507433
  • Searching for K00931.01 produces results for kplr009166862 and kplr009166870
  • Searching for K02370.01 produces results for kplr005385304 and kplr005385323
  • Searching for K03767.01 produces results for kplr008323753 and kplr008323764

Environment

Windows 11, lightkurve version 2.3.0, installed via pip

bbrady-vassar avatar Jul 27 '22 16:07 bbrady-vassar

Hi there! πŸ‘‹ Thank you for opening your first Lightkurve issue! πŸ™ One of our maintainers will get back to you as soon as possible. πŸ‘©β€πŸš€ You can expect a response within 7 days. πŸ“… If you haven’t heard anything by then, feel free to ping this thread. πŸ›ŽοΈ We love that you are using Lightkurve and appreciate your feedback. πŸ‘

github-actions[bot] avatar Jul 27 '22 16:07 github-actions[bot]

Hi @bbrady-vassar, I'm sorry that this has taken us so long to take a look at. I can confirm this behavior is still happening, and it's something we'd like to fix. We're going to dig into this. Thanks for raising!

christinahedges avatar Mar 24 '23 20:03 christinahedges

I started looking into this a bit and can confirm (a) this is an issue and (b) it's happening somewhere within the astroquery MAST query-- if I run the following to make the query more directly I still get both stars:

from astroquery.mast import Observations
import astropy.units as u
query_criteria = {"project":"Kepler", "radius":(0.0001 * u.arcsec).to(u.deg)}
obs = Observations.query_criteria(objectname='KOI-3815.01', **query_criteria)
obs[obs['obs_collection'] == 'Kepler']

The resulting table has two entries with target names kplr006507433 & kplr006507427 and distance of 0.0 for both. However, the RA and Dec for the two targets as given in the table are indeed 4 arcseconds apart. Maybe an issue with coordinate conversions somewhere inside the astroquery code...?

I got this behavior with astroquery versions 0.4.1 and 0.4.6.

megbedell avatar May 01 '23 17:05 megbedell

Some further digging... this isn't an astroquery bug, it happens at the MAST level. Searching the MAST Portal for the KOI, its coordinates, or even the KIC all return both stars with a distance of zero. See for example this query for KIC 6507433 (that's the correct target for the KOI) and this query for KIC 6507427 which give near-identical results containing both KICs at zero distance.

This source confusion issue does NOT happen if you search for those KICs through the dedicated Kepler Data Search & Retrieval portal, but that portal is deprecated and (I think) not accessible through astroquery.

I'm not sure there is a way to fix this without expert help from the MAST side, but I'd be happy to be proven wrong! πŸ˜„

megbedell avatar May 01 '23 18:05 megbedell