rzellem / exotic Goto Github PK

Getting the WCS for the source .FITS file inputted.

Right now, Rob has somewhat arbitrarily coded the aperture sizes that EXOTIC steps through. Should be in sigma values (3,4,5, etc.) at the very least.

E.g., .fts

Create separate functions that will get inputted data from users whether in init.txt file or command line and verify the inputs are correct from the command line for complete reductions.

Also, change the order in which time/airmass/etc. is sorted so that the user gets the opportunity to enter pixel coordinates after their imaging data has a plate solution.

When EXOTIC is being used to purely model the data alone (i.e., someone has done the multi-object photometry on another data reduction software package), we need to ask the user for the units of their timing data and then convert it, if necessary, to BJD_TDB units for accurate modeling in EXOTIC. EXOTIC will also need to get the lat/long of the telescope and RA/DEC of the target (as is currently being done in the "main" portion of the code).

Add a wider range of apertures based on the PSF width in the first image (Radius~2-5 sigma should be sufficient at increments of 0.1 or 0.25 pixels)

Currently, annulus sizes are varied to estimate the background flux but this can be done with a fixed annulus size and by masking out pixels brighter than the Nth (e.g. 25th) percentile as a way of automatically masking out stars within the annulus. There's no need to loop through various annulus sizes

Currently we scrape for the limb darkening parameters for the V-band, but some users will be observing in other bands. Need to scrape these based on the user's input.

This should be put off until the end of the summer.

If interested in making real-time fitting routines using the Python bokeh package, please DM @rzellem .

UnboundLocalError: local variable ‘directoryP’ referenced before assignment.

TL;DR: the variable directoryP is being called before it is even initialized. Need to check the code to make sure that it is initialized before calling it.

EXOTIC is big due to the inclusion of sample data. Perhaps we should host the sample data elsewhere so people do not need to download them every time they update EXOTIC via the zip files.

Binner fails when n==1; also needs to take into account the uncertainties of each individual datapoint. Should pass to binner() the uncertainties as well to fix.

Need to add a cosmic ray filter to EXOTIC.

Talk to @rzellem for more details, but essentially code up a small Python function that calculates the required exposure time for the MicroObservatory based on archival data.

0 arguments initiate an interactive mode
1 argument loads init file
N arguments runs without interactive mode

for the full set of arguments type:
python exotic.py -h

Currently in the MCMC, only the airmass coefficients, mid-transit time, and transit depth are free to be explored with the sampler. Can explore allowing more free parameters to more accurately retrieve final parameters.

Currently we scrape the EXOFAST limb darkening parameters; need to explore adding LDTK into EXOTIC to calculate it ourselves.

All interns observe the same transit simultaneously, reduce data with EXOTIC, and upload results to AAVSO Exoplanet Database.

Move planetary system parameters into the init.txt file. Have EXOTIC then check these values against the NASA Exoplanet Archive and raise an exception if they do not match. If the user does not supply them, then proceed as usual by scraping them from the Archive automatically and then asking user for agreement.

Also double check that the x,y pixel coordinates of the target star agree with the plate solution of the image.

The MicroObservatory has requested that we develop a tool to allow their users to fit (by eye) their photometric transit lightcurves with a model. An easy way to do this is to extract the model lightcurve function from EXOTIC and then wrap it in Bokeh, an interactive plotting tool, and then to add some sliders to allow the user to tweak the mid-transit time and transit depth to fit their data "in real time".

https://exoplanetarchive.ipac.caltech.edu/docs/TAP/usingTAP.html

Make a GUI for EXOTIC

Right now, if a user has >200 datapoints, EXOTIC will automatically bin down the data to reduce the MCMC runtime. Should make this an option for the user in case they really do want to reduce the data as-is.

EXOTIC_on_Gdrive.docx

C:\Program Files\Python37\lib\site-packages\skimage\feature\__init__.py:43: skimage_deprecation: Function ``register_translation`` is deprecated and will be removed in version 0.19. Use ``skimage.registration.phase_cross_correlation`` instead.
  removed_version='0.19')

^ Repeated hundreds of times during the phase.

Using the plate solving, confirm that the user has not accidentally selected a variable star as the comparison star. Or if they do, at least raise an exception.

Need an environment setup for windows people - issue with astroalign and compiling C code without setting up environment paths before hand

1. Native Windows
2. Anaconda

Better troubleshooting for common installation problems

In README.md, the link to Sample-Data is wrong, should be https://github.com/blaserethan/EXOTIC/blob/master/sample-data/HAT-P-32bDec202017.zip

Per Martin's suggestion, make the edges of the plot area and the labels in black. Right now, they look like they are in grey.

Some users do not know the pixel scale. However, we can directly calculate it due to the plate solution. Now recommend just automatically calculating the pixel scale after doing the plate solution and asking the user to check.

Currently the MCMC is hard-coded to run for 100,000 iterations and does no "real-time" convergence tests. Could explore stopping the MCMC after it has achieved convergence by the Gelman-Rubin statistic or the other built-in samplers.

Right now, if a user enters an AAVSO-support limb darkening coefficient that is NOT listed on the EXOFAST website (http://astroutils.astronomy.ohio-state.edu/exofast/limbdark.shtml), then an error will be raised.

Perhaps we allow the user to enter an AAVSO-supported LD coefficient. But if it is not on the EXOFAST website, we allow them to choose the appropriate one from the list...?

It looks that the tracking of your Celestrons is not perfect. We should explore on-chip guiding, where any changes in the location of a bright field star (or the target itself) are compensated by sending movement commands to the telescope mount. Could be part of the real-time data reduction code.

Modify git ignore file to exclude .DS_STORE files in all dirs.

Right now, users are getting an error if they input "HAT-P-32b" instead of having a space between the host star name and the planet letter. If they input the planet name in this manner, an error is raised. Maybe have EXOTIC correct the planet name to add the space and then have EXOTIC ask the user to check the changed name.

For example:

User inputs "HAT-P-32b"
EXOTIC sees the lack of a space and says to the user:
"Did you mean HAT-P-32 b? (y/n)" or something similar
Then the user can confirm.

Right now, when the user inputs a planet name that is not on the NASA Exoplanet Archive, EXOTIC asks the user to type in "manual" - instead, @rzellem recommends that if the user types in a planet name that is not recognized in the NASA Exoplanet Archive, EXOTIC asks the user to check their spelling or to confirm that this is a planet candidate. If it is a candidate (and therefore not listed in the Archive), the user has to manually input the planetary parameters.

Otherwise, right now when the user inputs the word "manual", EXOTIC crashes.

From EXOTIC user: "When inputting the Dec for the target star, the program isn't recognizing that I've placed a + in front of the coordinates, and I'm unable to move forward in the process. I've attached a screenshot for you to look at.
On my first attempt I had forgotten to type the +.
On the second attempt I did type the +, but it returned an error message that I had forgotten it.
On the third attempt, I tried putting a space between the + and the number 46.
On the fourth & fifth attempts, I tried using different + keys, one from at the top of the keyboard and the other from over on the number pad, to see if that would make a difference. It didn't."

Align FITS files before photometric extraction.

Might be part of the GUI issue, but breaking out separately just in case.

Right now, the Celestrons do a fairly good job on guiding on our stars. However, after ~10 minutes, they start to fall off the detector. Therefore we need to track on the target star (or nearby bright star) to tell the telescope mount to slew the stars back to the center of the field. @pearsonkyle has a star tracking code that we use at Palomar and it can be adapted to the Celestrons.

Right now, some users are finding that if they accidentally type in the, e.g., output path incorrectly, that EXOTIC will fully crash. This is particularly annoying as EXOTIC will fully run to the end and then fail just before saving all of its output.

Recommend that we check all directories at the very beginning of the code and then throw the user an error message if anything is wrong. That way they have the chance to fix things before they break.

Create a log to store issues in case the user closes EXOTIC or it crashes.

Need content for how to get involved in Exoplanet Watch including how to conduct your own observations or how to reduce data that is from a robotic telescope.

Many of the prompts cause errors that cause the user to lose all their progress if the value they enter is in an incorrect format, for example, a float instead of an int. These could easily be fixed with some checking and some try/catch. Also, there is no way to re-enter a value if, for example, the user makes a mistake. We could make a prompt wrapper and check for a "back" command as well as incorrect values so that the user is reprompted instead of an error being thrown. Would it be ok for me to make a PR with some quality-of-life improvements like these?

If nova.astrometry.net throws an error when requesting a session (such as website being down), inform the user and continue on with reducing data. Also, look into ASTAP since users do plate solve through there and see how well it works with EXOTIC when searching for coordinates. If it works, great! If not, add the ability to read off the file's information.

A user's computer can open only so many fits files before its memory is filled. The default is typically set to a very low number. Need to increase this number.

1. check if the image has WCS info in the header already

2. if yes, then ask if they want to trust the WCS info

3. if no (either they do not have WCS info or they do not want to trust the WCS info), ask the user if they want to use astrometry.net

4. if yes, then proceed as usual

5. if no, then make sure you have a boolean that triggers to skip the parts of all of the following code that uses the WCS info

Currently the final light curve plot is not visually friendly. Maybe turn current black points to grey to bring out the blue, binned points?

Might help users keep their EXOTIC up to date.

Need to update EXOTIC installation and use instructions and point to them on the Wiki page (or copy them there as well). Also need more instructions on how to use EXOTIC on the Google Collab.