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

FPP is NaN and NFPP is 0.0 #9

Closed
martindevora opened this issue Jun 26, 2021 · 8 comments
Closed

FPP is NaN and NFPP is 0.0 #9

martindevora opened this issue Jun 26, 2021 · 8 comments

Comments

@martindevora
Copy link
Contributor

martindevora commented Jun 26, 2021

Hi, I'm having trouble getting NaN values for FPP and empty probs for all the scenarios. I document my case in this file:
example.zip

Am I doing anything wrong? As far as I knew, I needed to bin the curve because many points caused the algorithm to return this NaN and 0.0 values. However, now I'm binning the curve to only 250 points and yet finding this result.

Thanks in advance for your help.

@exo-pt
Copy link

exo-pt commented Jun 26, 2021

Hi, the solution is, as Steven already said, in the binning of the folded lightcurve. But 250 seems to be too much.
After also struggling with NaN values, since I use bins=100, no more problems. And I use Triceratops a lot...
I'm afraid I can't explain why this works, but it does...
I tried your file with bins = 100 and got:
image

@martindevora
Copy link
Contributor Author

Interesting. Thanks for your answer. The only thing that concerns me is the fact that using only 100 points to represent the transit with some baseline could be not enough to properly compare it to any given model. What do you think?

@exo-pt
Copy link

exo-pt commented Jun 26, 2021

I'm not an expert, but quoting Steven in example.ipynb of this repository:
"If you have a lot of data points, I recommend binning your light curve down to ~100 to save time. Binning your data is poor practice when fitting light curves for a planet's parameters, but it doesn't yield significantly different results for our purposes"

@martindevora
Copy link
Contributor Author

Don't know why I read 1000 instead of 100. Thanks for pointing it out.

@martindevora
Copy link
Contributor Author

That still doesn't explain why we can't use more points, but I'll stick to that number of bins given it makes the algorithm work properly most of the times.

@ernewton
Copy link

I have been having similar problems, though it might not be related. In my case, the code only sometimes returns NaNs (I assume because whatever is producing NaN is part of the random draw process). Some combinations of lightcurves and contrast curves seem more likely to produce NaNs. In particular, I seem to be getting the most NaNs when I use the more constraining contrast curve; 8 of the FPPs out of the loop of 20 I just ran are NaN.

@stevengiacalone
Copy link
Owner

I've run into that issue with contrast curves too and have come up with a solution, but I haven't pushed it to the repo yet. I'm hoping to update the code with a fix for both of these within the next ~2 weeks.

@stevengiacalone
Copy link
Owner

Okay, these issues should be resolved with the latest update (1.0.9), which I just pushed. You should now be able to run the code with all of your data points (I'm sure there is an upper limit, but I have't encountered it) and any contrast curve. I'm going to close this thread, but definitely open it again if you continue to run into these issues.

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

4 participants