Default search radius fails for some sources that were assigned custom apertures (bright stars, galaxies, TRAPPIST-1).

[gully]

Problem description

The default search_targetpixelfile() radius of 0.0001 arcsec fails for these bright high proper motion stars with custom apertures:

EPIC ID	Campaign	new name	N Custom Aps
229002496	10	Bright Stars.gam Vir	1
236607658	111	Bright Stars.36 Oph	1
236607658	112	Bright Stars.36 Oph	1
246721980	13	Bright Stars.rho Tau	2
247599022	13	Bright Stars.tau Tau	1

Example

import lightkurve as lk

lk.search_targetpixelfile(229002496) #Current default: radius=0.0001 arcseconds

Yields: No data found for target "229002496".

Expected behavior

This source has a proper motion of ~600 mas/yr. A larger radius finds the source:

lk.search_targetpixelfile(229002496, radius=3) #arcseconds

Yields:

SearchResult containing 2 data products.

 target_name            productFilename                         description                    distance     
------------- ----------------------------------- --------------------------------------- ------------------
ktwo200084004 ktwo200084004-c101_lpd-targ.fits.gz Target Pixel Long Cadence (KTL) - C10-1 2.1207652756154594
ktwo200084004 ktwo200084004-c102_lpd-targ.fits.gz Target Pixel Long Cadence (KTL) - C10-2 2.1207652756154594

Note that these sources were assigned custom apertures owing to their large saturation bleed trails, so their TPF files get indexed by 200084004, rather than through the conventional EPIC ID 229002496.

Environment:

• lightkurve version 1.0.0 dev:
• source:

[gully]

By-the-way. One exceptional case lends some clarity of what might be going on.

lk.search_targetpixelfile(246721980, radius=60) #arcseconds

Yields:

SearchResult containing 3 data products.

 target_name                      productFilename                                  description                   distance     
------------- ------------------------------------------------------- ------------------------------------- ------------------
    245860427 tess2018319095959-s0005-0000000245860427-0125-s_tp.fits                    Target pixel files                0.0
ktwo200173882                      ktwo200173882-c13_lpd-targ.fits.gz Target Pixel Long Cadence (KTL) - C13 35.649538945883066
ktwo200173851                      ktwo200173851-c13_lpd-targ.fits.gz Target Pixel Long Cadence (KTL) - C13 45.203225539092784

For unusual/esoteric/potentially-unintended target management reasons, this source was assigned two partially-overlapping custom masks of differing sizes: 25x25 and 39x39 pixels. The lightkurve search distances come up as 35 and 45 arcseconds, respectively, hinting that the RA, Dec metadata in the FITS header does not contain the original target's metadata, and instead chooses something like the central pixel's position at the epoch of the campaign. So while high proper motion may be part of the puzzle, the large angular separations may also/instead arise due to the process for populating metadata for custom apertures.

[barentsen]

One workaround we discussed is to have Lightkurve let the user know about nearby targets in the search error message. For example: No data found for target "229002496". Targets were found X arcseconds away; try increasing the search area using the `radius` keyword.

[gully]

Update--- this Issue affects many more custom sources than previous thought. Essentially all bight stars that were assigned oversized TPFs have affiliated custom aperture IDs; these custom apertures are sometimes-but-not always found with the default query radius in lightkurve's search.

[gully]

[gully]

[barentsen]

Thanks for these examples @gully, very interesting! Do you have a proposed solution for which you can post a "pseucode mock example"?

[barentsen]

(Also, it would be worthwhile to open astroquery and investigate the UserWarning raised. It doesn't make sense.)