Category: Uncategorized

It took a couple days — lotta ins, lotta outs, lotta whathaveyous — but users may now generate a light curve object by inputting either a TOI number of a TIC ID!

There are a few outstanding issues. One is that, at present, downloading a K2 target by way of its EPIC ID is still causing problems. If various catalog queries fail you may have difficulties detrending, etc. The user may have to triage these issues using the mystery_solver() method and calling additional methods manually to update object attributes.

At this point there are just a few loose ends left. For one, TESS sectors really need to be treated as two separate sectors for the purposes of detrending. That’s yet to be implemented. And when you download a TESS target that’s not identified by the TOI or TIC number it’s still downloading unnecessary files and not deleting them. Still a bit to do!

For some unknown number of objects, the light curve files may be identifiable through a given target ID but NOT found in SIMBAD. For example, the TESS target TOI-216 can be downloaded by inputing it’s 2MASS identifier, 2MASS J04555525-6315362. HOWEVER, this identifier is mystifyingly NOT available in the SIMBAD catalog. Therefore, you can download the light curve just fine, but querying the target’s properties (the duration of the transit, the period of the planet, etc), will fail, because aliases cannot be identified through SIMBAD and thus the name of the target cannot be found in the catalog supplied by NASA Exoplanet Archive.

Up until now, this was resulting in a fatal error, which was rather irritating in this case since the light curve was clearly available, but you could not access the light curve object. This behavior has now been resolved by adding a try statement for a number of methods (find_transit_quarters, get_properties, get_neighbors). If these function calls fail, you’ll get a big warning message, but fortunately, the light curve object is still available to the user.

This is still a bit frustrating, since the detrend method relies on being able to query the catalog. But I think the solution is simply to manually define additional object attributes manually in this case. In the present case, for example, we’ve done:

toi216 = MoonpyLC(targetID='2MASS J04555525-6315362', telescope='tess'

And we should have no problem calling toi216.times, toi216.fluxes, etc. But detrending will fail. To solve this, try invoking the new mystery_solver(tau0, period, duration_hours) method which will attempt to manually generate all necessary functions for the detrend. Initial testing suggests you will be able to detrend following supplying these values.

Two significant changes with this update.

1. Up till now, two methods (get_properties() and find_neighbors()) were both using virtually identical code, and when I made changes they really needed to be applied in both places. This was terribly confusing and inefficient. Now that code is housed in the new find_planet_row() method, which queries the planet lists to identify the appropriate row where the target planet lives.
   
2. Utilizing the new find_aliases method, the user can now identify the planet in the TESS catalog using any valid SIMBAD identifier (TIC support and TOI support still not yet available but coming soon!). This is important because it’s not always obvious to the user which name a planet may be listed under (although you can probably guess in most cases).
   
   For example: If I want to download the light curve for TOI-101.01, I cannot (yet!) use TOI-101 as my targetID. Instead, I will need to use it’s more famous name, WASP-46 (or WASP-46b). But suppose your target has other names, too? You can use any of them if they’re listed in SIMBAD. For example, WASP-46 also goes by the catchy nom de plume “2MASS J21145687-5552184”. Before if you typed this in you would have received an error. No more! Now, if you really want to type that whole thing in (or, more likely, you’re feeding in a list of star IDs), MoonPy will utilize the find_aliases() method to dig through all known aliases until it finds the moniker cataloged in the… catalog. That is, WASP-46.

An Exception that occurs when the detrending algorithm has an empty quarter/sector was fixed by saving the flux_detrend and error_detrend arrays as the ordinary flux and error arrays (that is, if they can’t be detrended, they’re just not detrended). The solution required allowing these to pass through and now when the new light curve is saved they’re saved with a new quality flag == 2**21 or 2097152. If you see this flag you know the quarter/sector hasn’t been detrended. (Also, your flux values will be far away from 1!). I hope this handling will avoid further problems down the road. For now it seems to be working OK.

This blog is designed to be a companion to the user notes on GitHub. Specifically, it will be used to update in more detail major changes arriving in the code as they happen, maybe walk through example usage and outputs. Whatever seems useful!