taylorbell57
commented
8 months ago Do you mind attaching your ecf and epf files so that we have more information to troubleshoot with?
Closed cdfortenbach closed 5 months ago
taylorbell57
commented
8 months ago Do you mind attaching your ecf and epf files so that we have more information to troubleshoot with?
cdfortenbach
commented
8 months ago Here are the ecf and epf files that I was using when the run failed. I have tried a number of runs since then and still have the problem with 'white-fixed' params. I've tried using that mode with other orbital params with essentially the same result. Eureka_control_files.zip
taylorbell57
commented
5 months ago Sorry for the very significant delay - I now have much more available time and am trying to resolve a bunch of these older issues. I'll try to reproduce this today and see if I can fix the bug if it's still an issue. I assume you started with the MAST-provided _uncal files, based on your attached ECFs?
cdfortenbach
commented
5 months ago Glad you're back. In the interim I was able to find a way to work around this. It isn't critical now, but I think it would be helpful to have this functionality working in the future. I started with the Eureka! S2ecf, so I used the rateints files from MAST as a starting point.
taylorbell57
commented
5 months ago So I wasn't able to exactly reproduce your error, but I think I have some clues as to what was going wrong after looking at the plotted outputs, your attached EPF, and the text output you included above.
First, your t0 prior is off by 0.5 days; this is because the t0 you grabbed from Mancini et al. 2018 was likely 2,455,342.96982, and you just dropped the leading 24 while you're actually suppsed to subtract 2,400,000.5 (google "Modified Julian Date" for an explanation of how BJD and MBJD differ). You can quickly tell that this is what was wrong by looking at the fig5101_white_lc_dynestyStartingPoint.png plot that is made using the code that's currently on the main branch (I forget if those StartingPoint figures were made with version 0.10), as there is no transit shown.
This significantly wrong t0 prior, combined with the high precision of your broadband lightcurve, and your Gaussian prior on scatter_mult of 1.4 +/- 0.4, likely drove the fit into a very unusual/unphysical regime; my best guess is that scatter_mult went below zero.
If you subtract 0.5 from your t0 starting value and prior mean, that would probably be enough for the fit to at least not crash. Here is what the StartingPoint figure should look like.
However, as you can see from the updated StartingPoint figure, the initial guess for c0 is far too small (should be ~1.01), u1 and u2 are both far too large (should be ~0.05), and if you run the fit you'll see that the broadband lightcurve needs a scatter_mult value of around 5 which is very far away from the mean of your prior of 1.4 +/- 0.4; this will also result in a "Reduced Chi-squared" value that is not very close to 1.0 since your prior is too constraining in the scatter_mult term. Instead, uniform prior of 0.5 to 10 might suffice for these particular data. Your prior on ypos is also a bit too constraining, and increasing the prior uncertainty to 1 might constrain it less.
After making those five changes to your EPF (t0, c0, u1, u2, scatter_mult), I get a much closer starting point and end up with a half-decent final fit. The EPF changes I recommend (at least as a starting point, and for these particular data) are
t0 55342.46982 'white_fixed' 55342.46982 0.00051 N
u1 0.05 'free' 0.0 1.0 U
u2 0.05 'free' 0.0 1.0 U
ypos 0.0 'free' 0.0 1 N
scatter_mult 5 'free' 0.5 10 Uwhich gives you a better starting point:
In the future, I strongly recommend you use lsq before trying to use samplers like emcee or dynesty to first make sure your model is adequately able to fit the data before you spend a bunch of time using a sampler. I also strongly recommend looking at the StartingPoint figures as they'll help you craft better priors on your parameters. Additionally, setting run_tol to 0.001 is quite likely excessive and keeping it at 0.1 is most likely just fine (which will speed up your fits).
FAQ check
Instrument
Light curve fitting (Stages 4-6)
What happened?
Single change in S5_epf file causes code to crash during first, white-light curve fit. The change was to line item for param t0. Changed from 'free' to 'white_fixed'. Runs to completion otherwise.
Error traceback output
What operating system are you using?
Ubunto 18.04
What version of Python are you running?
Python 3.9.7
What Python packages do you have installed?
Code of Conduct