TTV fit sampling behaves strangely for long light curves

[ssagear]

Hi, first off thanks for developing the exoplanet package! It is a really awesome and efficient tool.

I wanted to ask a question about the TTV fitting functionality. In the TTV tutorial, if I increase the length of the light curve to 180 days (but change nothing else), increasing the number of transit time dimensions to 21 and 15 for P1 and P2, I get strange results after sampling. I have uploaded my notebook here -- it is just a copy of the TTV tutorial with the line t = np.arange(0, 80, 0.01) replaced with t = np.arange(0, 180, 0.01) in the first cell.

Instead of the expected posteriors that match those in the tutorial, my corner plot looks something like this:

And the trace plot looks like this:

as if the sampler refuses to move across parameter space. I am able to run the tutorial notebook as-is, and I get the expected results.

It may be worth noting that with a light curve with length 175d, the sampler behaves as expected, but when increased to 180d, this issue occurs.

I've tried increasing the number of tuning steps, but this behavior still occurs seemingly no matter how many tuning steps I use (up to the order of 10^5 steps). I've also played around with setting initial_accept to ~0.5 and starting at a chosen test value instead of the MAP solution, but those don't seem to change the result either.

I first came across this behavior while attempting to fit the Kepler short-cadence light curve for Kepler-138 b, and I realized that the tutorial exhibits the same behavior when the light curve is long. I'm not sure if this is an exoplanet or a pymc3 issue, or perhaps I'm just missing something at the moment? But I was just wondering if you had any insight on why this could be happening. Thank you!

Version of exoplanet: 0.5.2 Operating system: macOS Monterey 12.4 Python 3.9.12; exoplanet installed via pip

[dfm]

I expect that the issue here is caused by the fact that when you increase the baseline it drastically increases the number of transits, and hence the number of parameters since there's one parameter per transit. When you're working with such a large number of parameters, there a number of things that you'll need to keep in mind, and it can be annoying to tune! So, I'd say that this isn't really a bug, and more of a conceptual point.

I expect that the primary issue that you're hitting here is related to using a dense mass matrix (that's the default when you use pmx.sample), since it'll try to tune a num_params x num_params matrix during burn in and you can end up with catastrophically bad results when the number of parameters is too large. The simplest thing to try first is to switch to pm.sample instead of pmx.sample since that will use a diagonal mass matrix by default. You might also try using the "parameter groups" feature in pymc3-ext: https://github.com/exoplanet-dev/pymc3-ext#parameter-groups, but that might be overkill!

Give that a shot and I can help debug if it doesn't work right away.

[ssagear]

Ah yes, using pm.sample instead of pmx.sample worked beautifully!! Thank you so much for the quick response and suggestions. It definitely makes sense that the problem occurs when there's a large # of parameters. I'll also look into the parameter groups feature for the future!