Issues 1099, 1317: Modifying margin from 100" to using PSF for user-entered coordinates and updating coordinates with proper motion

[tamimfatahi]

100" may seem too large of a bound for some equipment, which may lead to incorrect user-entered coordinates that EXOTIC would validate. Instead, this PR uses the PSF to help create the bounds.

As talked about before with @rzellem, it has bounds of 1 PSF. However, after testing, it seems as though it is too constraining. I recommend we do something larger, just as we do in our PSF fitting routine where the max goes up to 6.

Closes issue #1099 and issue #1317

[tamimfatahi]

Added in the ability to use proper motion to update the target star's coordinates at the time observed.

[tamimfatahi]

Just as a heads up - parameters not entered (distance, PM RA, PM DEC) will have a value of 0 if gathering params from the JSON file that do not exist. Therefore, proper motion will not be accounted for properly.

[jpl-jengelke]

Review complete. Please merge upon resolving comments. This must be tested with all merges in develop. Thanks.

[IraLeeBell]

I've created this test for nea.py. You can run it from the /exotic/api/ folder: https://gist.github.com/IraLeeBell/ac3f7202f29f9b3a3c45e8725dd2e1e7

Perhaps it wouldn't hurt to have a test for each of the api files as I've done here (separate from this PR).

[IraLeeBell]

I'm getting the following error/warning when the correct pixels are selected. I wanted to test this first, before testing the incorrect pixels. I note that EXOTIC is calculating the pixel coordinates at [0,0]. I can confirm that this data set is a valid set, which produces a good light curve and will result in PSF photometry. Also, I can confirm that a plate solution is found when getting this warning.

[IraLeeBell]

Quick script to determine whether a FIT file has a plate solution in the header (per convo w/ @tamimfatahi ): https://gist.github.com/IraLeeBell/f272dabddec4585c3f9563dde68241c8

[tamimfatahi]

I've created this test for nea.py. You can run it from the /exotic/api/ folder: https://gist.github.com/IraLeeBell/ac3f7202f29f9b3a3c45e8725dd2e1e7

Perhaps it wouldn't hurt to have a test for each of the api files as I've done here (separate from this PR).

Agreed. I'd place the tests in the tests/ directory such as the one you created. Maybe even add in pytest if you can and we can have it run every single time someone opens a PR.

[tamimfatahi]

Quick script to determine whether a FIT file has a plate solution in the header (per convo w/ @tamimfatahi ): https://gist.github.com/IraLeeBell/f272dabddec4585c3f9563dde68241c8

I believe we currently use astropy to determine whether a FITS file has a plate solution. If that isn't the best way, please let me know.

[tamimfatahi]

I'm getting the following error/warning when the correct pixels are selected. I wanted to test this first, before testing the incorrect pixels. I note that EXOTIC is calculating the pixel coordinates at [0,0]. I can confirm that this data set is a valid set, which produces a good light curve and will result in PSF photometry. Also, I can confirm that a plate solution is found when getting this warning.

For some reason, the archive isn't giving the distance to WTS-2 when querying as its value is 0.0. It does scrape its proper motions though. That's why you're getting such an off value. I updated the code to handle for the error. You should get a warning like this:

Warning: Cannot properly account for proper motion due to missing values in:
Distance (pc). Please re-run and fill in values in initialization file to account for proper motion

Thanks for that catch! Please see how the code handles the change now. You can also add in the parameters through the updated initialization file.

[IraLeeBell]

Confirming new warning showing when distance in parsecs is set to 0.0 in the inits.json file.

[IraLeeBell]

Confirming that when manually entering the parsecs in the inits.json file, we kick off the check_parameters if different is true process.

[ivenzor]

I believe EXOTIC use is_celestial from astropy.wcs import WCS

wcs_file = check_wcs(inputfiles[0], exotic_infoDict['save'], exotic_infoDict['plate_opt'])

def check_wcs(fits_file, save_directory, plate_opt, rt=False):
    wcs_file = None

    if plate_opt == 'y' and not rt:
        wcs_file = get_wcs(fits_file, save_directory)
    if not wcs_file:
        if search_wcs(fits_file).**is_celestial**:
            log_info("Your FITS files have WCS (World Coordinate System) information in their headers. "
                     "EXOTIC will proceed to use these. "
                     "NOTE: If you do not trust your WCS coordinates, "
                     "please restart EXOTIC after enabling plate solutions via astrometry.net.")
            wcs_file = fits_file

    return wcs_file


def search_wcs(file):
    with warnings.catch_warnings():
        warnings.simplefilter('ignore', category=FITSFixedWarning)
        header = fits.getheader(filename=file)
        return WCS(header)
        # return WCS(fits.open(file)[('SCI', 1)].header)

[IraLeeBell]

And most importantly, now confirming that when parsecs are manually entered and we adopt the parameters and the coordinates are incorrect for the target star, the correct coordinates are suggested.

[IraLeeBell]

Just ran through a flow with exoplanet WTS-2 b and EXOTIC ran as expected. All files present, looks good.

[jpl-jengelke]

Please see comments

[jpl-jengelke]

Please take a quick look at the comments and they should be able to be cleared readily.

[jpl-jengelke]

Looks great!