Allesfitter stops after cryptic error about allesfitter HOT 10 CLOSED

Hi @jvines this error comes from ellc (https://github.com/pmaxted/ellc). All Python errors are caught by try/except in allesfitter, but this one comes from ellc's underlying C code, so we cannot catch it. It happens very rarely, but it can happen. The reason is always that you are sampling in non-physical areas of the parameter space, e.g. if a planet would lie within the star, and so on. If you email me your allesfit folder, I can look into your priors etc.

from allesfitter.

Okay then, I'll email you the params and settings files. Do you need anything else emailed??

from allesfitter.

I would need the whole folder, including the data and your previous trials (logs/plots/save file etc). If the data is private, I can't do much (happy to sign an NDA and promise I won't steal it). Or you can send me a minimum example with simulated data that replicates the error (but that's probably not possible).

from allesfitter.

I see, I'll anonymize the private data then and send them your way. I suspect what might be the issue now that you mention unphysical areas, but maybe it's best you check it out :) Thank you!

from allesfitter.

See also: #18
I think yours is a very similar case.

from allesfitter.

Hi ! I found that it was the eccentricity after all. After commenting it out I no longer got the error.

I've got a new question, though. Is there an easy way to retrieve the logz of a model?

EDIT: the error I was having was a simple typo...

from allesfitter.

Hi @jvines,

Glad to hear that and no worries -- 99% of all such issues are typos 👍 I already wrote a lot of typo-catching things into allesfitter. If you'd like to share what yours was, I can try to catch such typos in the future.

For future reference: Yes, ellc can crash with the "eanom" error if the eccentricity puts the planet's orbit through the star, which is unphsycial. To mitigate that, we include some simple pre-calculations in allesfitter, which skip ellc in such cases. Generally, you should be able to use eccentricity in your fits as long as you make sure your priors on it are physically reasonable.

To get logZ:
allesfitter.get_logZ(datadir)

You can also automatically return it when making the comparison plots:
allesfitter.ns_plot_bayes_factors(datadirs, return_logZ=True)

from allesfitter.

Hi,

I've got another question: is this error glimnega: error finding limit fatal?? I just got it in a run that's 50 hours in and I don't want to terminate it just because of it...

from allesfitter.

That is also an ellc error (in their C code), so I think it's best to ask Pierre Maxted directly: https://github.com/pmaxted/ellc/search?q=%22glimnega%3A+error+finding+limit%22

With Python, we have no means of catching/excepting any of ellc's C errors. That would have to be caught directly in ellc's C code and then, e.g., return a NaN model light curve instead of raising an error.

The only thing one can do in Python/allesfitter is setting physically plausible priors so these ellc crashes don't happen (they mostly happen for colliding bodies).

Side note: 50h is a very long time, I think I've never seen any allesfit take that long. Feel free to email me your files and I can check how to speed it up. See also https://www.allesfitter.com/faq#h.p_8OVje-veCXVa

from allesfitter.

I think the main reason why it's running extremely slow is because I was using 1000 nlive in order to make sure to capture any modus in the posterior space properly, at least that's been my experience before, and I am using quite wide priors, which are known to slow down the nested sampling significantly. I'll send you the files for you to take a look at, I didn't see the very_sparse option so I'll use it now that the run finished..

Going back to the error from ellc, it turns out it wasn't fatal :P

from allesfitter.