benmontet
commented
4 years ago Hey Tyler,
Thanks for your detailed post, it's certainly easier to diagnose things the more information we have, so definitely erring on the side of including too much information rather than too little is the way to go!
Going through these one at a time:
Issue 1: Yes, this is something that we've seen before for users using Windows. As far as I know it only happens with Windows machines, I've never heard of this from someone using something unix-based. I don't understand the architecture differences well enough to be able to give you good insight as to how to fix it, and neither of us have windows machines to test out possible fixes, so unfortunately I don't have a good fix for you. I have two unsatisfying options for you. One of those is to run the code inside some sort of a try/except statement so it handles the bad cases gracefully and automatically re-runs, and the other is to do your data creation inside a Google Colab (or equivalent), and then either do your analysis there or save the output .fits files, transfer them to your local machine and then do your analysis with those. But if you (or anyone else reading this) do find a solution we'd happily accept a pull request that sorts it!
Issue 2: That's a weird one! When you copy that link where it's throwing the error into a web browser and try to go there, you get the same issue (where normally it would download the data). And indeed, changing the sector number to 16 and running the same link works absolutely as expected. So this is something with TESSCut, which we use behind the scenes to get the TESS data in the north. Have you had this issue for multiple days? The TESS folks are in the midst of re-processing much of the data, so it's possible that they're just doing sector 17 right now and so that sector is temporarily unavailable. If this has been going on for a few days, the best approach is to contact the folks at MAST, either through email (archive at stsci dot edu) or twitter (MAST_News), let them know you're having an issue with the TESSCut API, and include that specific mast.stsci.edu/tesscut/.... query that is giving the 400 error.
Issue 3: this is another Windows specific issue. When you run the system with tc=False (which says don't use TESSCut, use our postcard system to get the data, which at present only works for sectors 1-13) eleanor uses a 'pointing model' behind the scenes to determine what pixels in your aperture the star falls on throughout the sector, and for some reason on Windows machines it doesn't automatically figure out the right file structure for where this pointing model is stored. If you print eleanor.Source().pointing (as star.pointing or whatever you saved your Source() object as + dot pointing) you should get back a big table of pointing information, and I would guess you will get None. In this case, the fix is just adding in one or two more lines of code. In between your calls to Source() and TargetData(), if you set star.pm_dir to be properly the directory that the postcard information---including the pointing model---was downloaded into, that will fix this. The variable star.postcard will include the name of the postcard which you will need to parse to get the right location. Adding that fix will get you on your way (and this should only be an issue when you run with tc=False). This one is the same issue as #171 so hopefully the information in that discussion will help as well.
Good luck! There is a lot of scattered light from the Earth in the North and supernovae tend to be relatively quite faint compared to the stars we normally look at, so happy to talk through more artisanal detrending/systematics removal if you run into issues getting good quality light curves for your targets.
tylerbarna
I'm currently investigating the viability of using eleanor to identify Type Ia supernova lightcurves at or around their peak luminosity as part of a senior thesis, and I've recently encountered a few issues that I wanted to seek some clarification on. (Note: The issues I've encountered are generally similar to those mentioned in issue #171 . However, there are a few ways in which the issues I'm running into differ and I've compiled a bit more information about potential causes of these issues)
For context, I'm running the latest development version of eleanor on python 3.7.6 with a jupyter notebook. I'm using a Windows 10 machine (Version 1909) with an Intel 9700K, 32GB of RAM, and an NVME SSD.
Issue 1
I'll start off with the issue I suspect may be more specific to my machine and/or Windows. When I first installed eleanor, I was having trouble with eleanor.Source() encountering an error when first being run for a new target.
When I run
from the quickstart tutorial, I receive the following error:
When using eleanor.Source(), this issue almost always resolved itself upon being run a second time. Through some experimentation I have found that, when using eleanor.multi_sectors() to observe an object present in n sectors, it seems the code will only successfully execute after being run n+1 times. I also found that I am able to replicate the issue by clearing the cached files in the ./eleanor/ folder. From what I can tell, it seems there's an issue with eleanor.Source() where it attempts to read or modify the cached fits file before it's been entirely written to the disk. I've mostly been able to work around this by running the code multiple times, but I figured it was worth mentioning.
Issue 2
This issue is fairly specific, and I'm not entirely sure if it's an issue with eleanor, MAST, or something else. When I run the following code
I receive this error
Of all the targets I've been working with, this is the only one that returns that error, and retrieving this source for other sectors works fine if the files are cached. This also occurs when using eleanor.multi_sectors() to retrieve data from all the sectors the target is present in,
Issue 3
Finally, this is probably the most vexing problem I've encountered. When I first ran the quickstart tutorial, the results were as expected, with the correct lightcurve being generated with the correct aperture. From there, I attempted to replicate the lightcurves in Figure 3 of Vallely et al. (2019). When I use eleanor to find a lightcurve for ASASSN-18tb, I get the following result
While Figure 3 in Vallely et al. is measuring electron counts, the above plot is still not consistent with their results. Investigating this further, I plotted the TPF and aperture.
I found this aperture to be very odd, as I had thought the TPF was centered on the target itself. Additionally, when attempting to find the two reference stars used to subtract the background light from the supernova in Vallely et. al, I found that the two stars had essentially the same flux as the supernova when they should have roughly half the magnitude.
Upon checking their apertures, I found two familiar apertures
I'm unsure why these three objects are behaving this way; the TESS magnitudes found by eleanor are fairly close to the ones reported in the paper, so I believe eleanor is correctly identifying the targets, but otherwise the results don't match up at all despite the authors stating they found their process found the same results as the ones found by eleanor. This issue persists even after restarting the kernel, restarting jupyter, or restarting the system, and clearing the cache also has no effect.
My apologies for the lengthy post, I thought that these issues were connected somewhat and I wanted to provide as much information as possible. Thank you