Mode die off

[caseylam]

Hi Josh,

I was wondering if you had suggestions about combatting mode death. In the documentation and on github, it's noted that not having enough live points could be a problem and lead to mode "die off". I had initially been running the DynamicNestedSampler with ninit_live = 1000, and changing ninit_live up to 5000 improved the issue. Bumping ninit_live up to 20000 improved it even further, but then the computer started complaining.

This is the traceplot when I used ninit_live = 1000. The two modes are in the "u0_amp" variable.

This is the traceplot when I used nint_live = 20000.

I've been using multinest, and it gives a similar behavior. If I understand correctly, this problem should only have two modes, so it seems like ninit_live = 1000 should be more than enough live points. Might you have any other suggestions on how to prevent mode death?

Thank you!

Casey Lam

[joshspeagle]

So there are two issues going on here. Your first problem is not actually an issue with dynesty, but rather with Jupyter: the default printing options dump text out every time, and with so many live points you are getting to the point where you're overwhelming the Jupyter notebook defaults on I/O rates. You can change those as described in the settings.

As for the "mode die-off", I think there is a bit of a misunderstanding. You actually characterize the modes just fine when sampling as far as I can tell. The colors on the plot indicate where the majority of the posterior mass is, which is what you're trying to integrate over. As expected, in both cases you do that just fine. The reason why your modes terminate as you move to the right (over time) is because, well, you've finished integrating over them and so you don't need to add any more samples! As expected, with more live points you are able to characterize the modes better, but you still find them in both cases.

Mode die-off refers to the particular case where a mode that you identify earlier in the run that contains a non-negligible chunk of the posterior mass abruptly dies because you remove the last live point that characterizes it. These will result in modes "appearing" as you add in more live points when you look at your posterior estimate, which is not what's going on here. More generally, it's actually totally normal for modes to go away pretty early -- a lot of problems have secondary minima, they're just such terrible fits compared to the global minimum that they disappear quite early during a run. These modes don't "die off" per see, but rather just are such poor fits they don't matter.

Does that seem like a reasonable answer?

[jluastro]

Thanks Josh... we sometimes see them die off before the bulk of the posterior mass. But with 1000 live points, it is fine. I think our concern was that the posteriors for the 2nd peak look quite different between 1000 and 20,000

[joshspeagle]

That's fair. You can always further check the robustness of the amplitudes by using some of the built-in utils to explicitly simulate posterior error via, e.g., simulate_run. It may also be the case that if the initial run mis-estimates the distribution it can propagate into the later batches when adding samples dynamically, especially if the samples are somewhat correlated. But the systematics tests you already seem to have done look very reasonable.

On a totally a separate note, for more aggressive mode tracking dynesty has the arguments vol_dec and vol_check which can be modified to prefer more aggressive/conservative ellipsoid decomposition of the posterior. The defaults are quite a bit more conservative than MultiNest to avoid "shredding" the posterior, so it's possible that changing those to be a bit more aggressive might help give better proposals and mode tracking.

Anyways, thanks for the question and hope this helps!