Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sector 13 PSF lc with very different looking segments #202

Open
rachelbf opened this issue Oct 2, 2020 · 5 comments
Open

Sector 13 PSF lc with very different looking segments #202

rachelbf opened this issue Oct 2, 2020 · 5 comments

Comments

@rachelbf
Copy link

rachelbf commented Oct 2, 2020

I'm using the latest version of eleanor with Python 3.7.
One of my s13 PSF light curves has this weird issue where the two segments look very different. This is NOT the case for the PCA light curve. Not sure what's going on here.
Screen Shot 2020-10-02 at 14 10 48

@benmontet
Copy link
Collaborator

Hi Rachel,

Thanks for your patience.

In cases like this, I recommend plotting the psf shape parameters (data.psf_a, psf_b, psf_c, psf_x, psf_y, psf_bkg). You'll see that there's a big jump where the parameters jump quite a bit at cadences 540-550 when you run with the default setup, which then lead to a much worse fit in the second orbit (psf_ll, which is the negative log likelihood of the fit at each cadence). Something very bad happens to the telescope pointing at those cadences (which you can see by plotting data.tpf at each cadence, the stars jump all over quickly) which causes the optimiser to fall into a local minimum rather than the global minimum and it's a narrow enough minimum to stick around there the rest of the second orbit.

You could remove those cadences from your arrays that you pass through to ignore them so the fitter never sees them and can't get caught in that fit, or by using a more complicated PSF model (possibly setting nstars=2 and fitting for that star in the corner as well) might also help it stay in the local minimum. I think I would recommend the first approach though!

Good luck!

@rachelbf
Copy link
Author

I was trying to figure out the cadence masking and passing. I was able to see the “jump” in the data from the plotting you recommended. While I’m able to get the TJD of the region that needs masking, I’m not sure how to get the cadences that you describe i.e. 540-550 (or are you just calculating that yourself?)
Once I have the new masked array, how do I pass it through the fitter? Idon’t see a way to do this within the API.

@benmontet
Copy link
Collaborator

Hi Rachel,

Remember that the PSF modeling doesn't care about times, it takes in an arbitary TPF and performs operations on the measured flux values, it doesn't know anything about the time of each observation (nor should it: the fit of the model to the data shouldn't depend on when the data were taken, two identical observations taken many days apart should in principle return the same model fit).

In this case, you are returned an array called data.psf_flux and all of the data.psf_N fit parameters. These are arrays with one value per cadenced observation, so cadences 540-550 are array elements 540-550. You can find them by slicing data.psf_flux[540:550] or view them compared to the other data by running something like plt.plot(data.psf_b) and inspecting the b parameter fits at x=540 to 550.

Once you have a masked array, you can pass in any arbitrary data into the data.psf_lightcurve object, it doesn't have to be a default TESS TPF. As long as you have an array of 2-D flux regions over many times, a similar array of flux errors, and an estimate of the background at every cadence for an initial guess (can be zero) (might be dangerous if it is) you can pass those into that function and use the PSF tools. I've even used this approach as a sneaky interface to do simliar PSF modeling on Kepler data. See the docstring that shows what parameters you can/should pass through here: https://adina.feinste.in/eleanor/api.html#eleanor.TargetData.psf_lightcurve; if each of the first three arrays are sliced in the same way as each other to exclude bad cadences, things should just work by then calling the psf_lightcurve function.

@rachelbf
Copy link
Author

Thanks for the help with this Ben! The solution has worked really well for most stars in sector 13.

However, there is this one star TIC 220437346 where the psf_flux is just an arrays of 0s. It seems to have all the other fluxes. I'm a little lost on what's going on here.

This is the line that I use to generate the fluxes
data = eleanor.TargetData(star, height=15, width=15, bkg_size=31, do_psf=True, do_pca=True, regressors='corner')

Here are the flux plots:
Screen Shot 2021-05-31 at 12 23 31

Here are the psf plots (which just seem to be straight lines):
Screen Shot 2021-05-31 at 12 24 00

@benmontet
Copy link
Collaborator

It looks like this is an extremely faint star, 18.5 mag in the TESS bandpass. Here, its PSF overlaps with many brighter stars, so the best fitting model (using a Gaussian approximation, mind you, which is demonstratably a poor fit to the data) actually is a negative Gaussian at this location to better fit the ridges from the other, nearby, brighter stars. So at every cadence here it's preferring a negative flux, but we force a hard boundary that flux must be nonnegative which is why it's stuck at zero.

You could do better by fitting multiple components here with the nstars keyword but remember this star is so faint the expected photon noise in each cadence is going to be close to 10%, so if you're looking for smaller signals than that you need a telescope bigger than 4 inches.

I always recommend checking out the documentation, the section titled 'good practices' says the following:

Note that PSF modeling is very much in beta and our current implementation has known issues for very faint stars (fainter than I ~ 15, generally).

Your star is more than 20 times fainer than that, so I would be very surprised if it worked well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants