EMCEE walkers not exploring parameter space

[Paco-2000]

I'm trying to use the EMCEE sampler but I'm getting some weird results. The lnprobability plot isn't exploring the parameter space and remains constant at a very low probability.

I checked the trace plots and corner plot and they appear to be working as expected:

The results from the corner plot don't match existing literature of the system, but I'm assuming that it's normal since I didn't run the sampler for very long. I tried running it for 5000 iterations instead. While the corner and trace plots would behave like the ones above, the lnprobability plot changed a bit.

I tried troubleshooting this by running it with less parameters, changing the priors, increasing the range of the priors, running the sampler with/without flipped constraints... but the lnprobability plots were always constant at a negative probability. I would usually run the code using ellc to make it run faster. I tried running it without ellc but it's much slower and I don't have any results for that yet. Here's how I would initialize my distributions:

b.add_distribution({'sma@binary': phoebe.gaussian_around(0.1),
                    'incl@binary': phoebe.gaussian_around(2.0),
                    'q@binary': phoebe.gaussian_around(0.1),
                    'distance@system': phoebe.gaussian_around(160),
                    'teffratio@binary': phoebe.gaussian_around(0.05),
                    'requivratio@binary': phoebe.gaussian_around(0.05),
                    'requivsumfrac@binary': phoebe.gaussian_around(0.025),
                    'teff@primary': phoebe.gaussian_around(100),
                    'gravb_bol@primary': phoebe.uniform(low=0.9, high=1.0),
                    'gravb_bol@secondary': phoebe.uniform(low=0.32, high=1.0),
                    'irrad_frac_refl_bol@primary': phoebe.uniform(low=0.9, high=1.0),
                    'irrad_frac_refl_bol@secondary': phoebe.uniform(low=0.6, high=1.0),
                    'esinw@binary': phoebe.gaussian_around(0.01),
                    'ecosw@binary': phoebe.gaussian_around(0.01),
                    'sigmas_lnf@lc01': phoebe.gaussian_around(1)
                    }, distribution='ball_around_guess', overwrite_all=True)

b.set_value('init_from', 'ball_around_guess')

b.add_distribution({'sma@binary': phoebe.uniform(low=1.0, high=60),
                    'incl@binary': phoebe.uniform(low=0.0, high=90),
                    'teff@primary': phoebe.uniform(low=3000, high=25000),
                    'teff@secondary': phoebe.uniform(low=3000, high=25000),
                    'requiv@primary': phoebe.uniform(low=0.1, high=15),
                    'requiv@secondary': phoebe.uniform(low=0.1, high=15),
                    'q@binary': phoebe.uniform(low=0.0, high=1.0)
                    }, distribution='priors_from_external_source', overwrite_all=True )
b.set_value('priors', 'priors_from_external_source')

b.set_value('nwalkers', solver='emcee_solver', value=30)
b.set_value('niters', solver='emcee_solver', value=2500)

b.run_solver('emcee_solver', solution='emcee_sol')

Does anyone know why it's doing this? Is it possible that it's stuck on some local minimum?

[kecnry]

From the trace plots, it doesn't seem that the walkers themselves are stuck, but I am confused why it appears that lnprobabilities aren't affected by the changes in parameter values. Are the lnprobabilities truly identical or just very similar (by inspecting the array in b.get_value('lnprobabilities', solution='emcee_sol')?

Can you also try sampling the forward model over the initial distribution and ensure that the changes are resulting in differences to the synthetic model itself (maybe ellc is giving the same light curve back despite the change in parameter value which would explain lnprobability appearing to be stuck)? You can do that with something like:

b.run_compute(sample_from='ball_around_guess', sample_num=20, sample_mode='all', model='sampled_over_dist')
b.plot(model='sampled_over_dist', show=True)

[Paco-2000]

Sorry for taking so long, I'm running this on a remote cluster and sending the solutions back to my local machine which took me a while to get everything settled.

I checked if the values are truly constant and here's what I got:

I'm not sure if I ran the forward model properly because here's the model that I got:

I ran it a couple of times changing different things and got this every time.
Was I supposed to replace 'ball_around_guess' with 'emcee_sol'?

[Paco-2000]

Here's the plot without the data.

I'm getting my data in electrons / second and then normalizing it before sending it to Phoebe. I usually run plum_mode with dataset-scaled so I don't have to do the conversion to watts / m^2 for now

[kecnry]

Ok, it's good to see the model is varying, so at least the problem isn't in the ellc wrapper itself. I think the huge discrepancy in scales (75 orders of magnitude) between the synthetic model and observations is what is driving the lnprobabilities to be so extreme (they may not in fact be identical after 9 digits, but those first 9 digits might be dominated by this offset of 75 orders).

Is it pblum_mode to dataset-scaled now? If so, maybe there is a bug in the dataset scaling as it doesn't seem to be working when calling run_compute. And if not, then you should either set it or adjust the other scaling options and make sure the synthetic model drawn from your distributions and roughly agree with your observations.

[Paco-2000]

Pblum_mode wasn't set to dataset-scaled as I was getting some warnings suggesting I change it. I reran it with dataset-scaled now and there is some improvement although it's not perfect.

The lnprobability plot is no longer constant but it's seems that all of the walkers are stuck around the same solution every time

[kecnry]

Great - it looks to be working as expected! The lnprobability is still climbing significantly, even after 1000 iterations - so my suggestion would be to use optimizers first and really spend time constructing the initializing distributions so that you do not waste a lot of computation time during the burnin phase.

[Paco-2000]

Will do, thanks for your help!