FAQ

A: Do you use MCMC or Nested Sampling?

-> MCMC: check the chain and autocorrelation lengths. If the chain length is at least 30x the autocorrelation lengths, you can consider the fit converged.

-> Nested Sampling: if it's done, it has converged :)

A: If you give a params_star.csv file, then this happens automatically! There will be various additional files in the results folder, named *_derived_*, including tables, plots, and latex commands.

A: If you give the params_star.csv file, the following will automatically happen: the user-given stellar params are used to derive a normal prior on the stellar density. At each step in the MCMC/NS run, the stellar density is derived from R/a and P, and compared to the prior. Then the fit gets penalized with regards to the user-given prior.

A: There can be many reasons, so let's break it down:

1) Are you running MCMC or Nested Sampling?

-> if Nested Sampling, then one reason it might take very long is because the priors for some paramters are extremely wide (for example, the default priors for noise (uniform -15 0) and GP (uniform -15 15) are purposely way too large) . The Nested Sampling convergence time scales with prior space per dimension - so having e.g. 10 parameters that all have priors that are a factor of 10 too large will result in a 10^10 times longer convergence time. An easy and fast way to bypass this is running a simple MCMC fit to gauge where the posteriors lie, and then setting the Nested Sampling priors much closer around this expected value, e.g. at +-7 sigma.

-> if MCMC, the above is not an issue. But maybe you are running your chains much longer than needed?

-> often MCMC is quite a bit faster than Nested Sampling; but convergence is not guaranteed unless you make sure the chains are long enough.

2) Do you use multiprocessing==True and all your cores?

-> if not, this can speed things up! Almost linearly for MCMC (i.e. using 10 cores will make it almost 10 times faster), but not quite linearly for Nested Sampling (the speed gain saturates around 10 cores).

2) Do you use host_grid_[inst]==default?

-> if yes, a tweak to speed things up is to change host_grid_[inst] to "sparse" or "very_sparse"; the precision loss is negligible in most cases.

3) Do you use fast_fit==True?

-> if no, and you only care about a transit, turn it on.

-> if yes, another tweak is to decrease the fast_fit_width further -- but make sure it does not cut too close to the transits; it should be at least 3x the transit width.

4) How many data points do you have, and how many free parameters do you fit for?

-> generally, if there is a lot of high cadence photometric data and many free parameters, and you have already done your best with steps 1)-4), then there is not much else you can do. Sometimes it does take a few hours to converge, e.g. when fitting high-cadence Spitzer data, or 4 years of Kepler data.

A: This has nothing to do with allesfitter; it is because you are on Mac OS Catalina and are running Python >=3.7 with matplotlib >3.1.0. This is a known issue with this combination of OS and packages -- and has driven me crazy. See e.g. here: https://github.com/matplotlib/matplotlib/issues/15410. Suggested solutions from various forums:

1. Bypass the problem by running mcmc_fit() or ns_fit() only, then close the terminal, open a new terminal, and run mcmc_output() or ns_output() only. This is the only bypass that worked for me.

2. Downgrade to matplotlib = 3.1.0. This is the only real solution that worked for me.

3. Update to Python >= 3.8.2. However, Anaconda and other packages do not yet support Python >=3.8.2. So updating is at your own risk and might lead to other problems. This did not solve the problem for me, but allegedly worked for others.

4. Use import matplotlib; matplotlib.use('Agg') before importing allesfitter. This stops figures from being opened before they get saved. This did not solve the problem for me, but allegedly worked for others.

5. Use import multiprocessing; multiprocessing.set_start_method('forkserver', force=True) before importing allesfitter. This did not solve the problem for me, but allegedly worked for others.

6. Use import multiprocessing; multiprocessing.set_start_method('spawn', force=True) before importing allesfitter. This did not solve the problem for me, but allegedly worked for others.

A: This has nothing to do with allesfitter; it is because you are on Mac OS Catalina and are running Python >=3.7, and want to save pdf figures with matplotlib. This is a known issue with this combination of OS and packages -- and has driven me crazy. See e.g. here: https://github.com/uqfoundation/pathos/issues/153. The only solution that worked for me is to have a try-except statement, and catch the pdf-savefig and except it with an png-savefig.

A: This should not happen in allesfitter, because we have try/except catches for this, and revert to png if jpg is not available. Still, for future debugging: this has nothing to do with allesfitter; it is because newer versions of matplotlib need the package "pillow" to save jpg, which for some reason is not installed by default anymore. Use conda install pillow or pip install pillow and you can happily save jpg again.