# Turing.jl/MCMC: Chains getting stuck

**URL:** <https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696>\
**Category:** Probabilistic Programming\
**Tags:** diffeq, sciml\
**Created:** [March 10, 2022, 4:30pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696 "2022-03-10T16:30:24Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [March 10, 2022, 4:30pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/1 "2022-03-10T16:30:24Z")

</div>

I want ask for advice or insight as to why my MCMC chains could be stuck even when using HMC on a uni-modal posterior.

I’m doing parameter calibration of pedestrian models (systems of non-linear ODEs) using `Turing.jl`. If we generate synthetic data using the model, then inferring the parameters from this data over a short time period (\<1s) is a well-posed and well-conditioned problem, as there is little time for the pedestrians’ trajectories to be “chaotically” altered. However, extending the inference to times greater than a few seconds, the chains entirely fail to explore the parameter space and get completely stuck. That is to say, they still accept proposals, it’s just that these proposals are very close to each other, so the chain never moves.

I am confused as to why this would happen, given that I am using HMC (NUTS), which was specifically created to address the issue of non-exploration. The posterior in question looks like this:

![image](https://global.discourse-cdn.com/julialang/original/3X/3/c/3ce611754840bd4b4bb24ff12b78a980565c86c6.png)

Which doesn’t strike me as particularly difficult to identify. That said, I’m so new to MCMC that there could be something obvious that I’m missing. One thing I haven’t done is check the identifiability of my parameters using the relevant SciML tools.

Here’s what an example trace plot looks like for my problem:

 ![image](https://global.discourse-cdn.com/julialang/original/3X/2/7/27f3ad0624f0dd2e8f7114798eed51fd2f9c7e5b.png)

---

<div class="post-metadata">

**Author:** ![wc4wc4wc4](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wc4wc4wc4/32/23038_2.png) [@wc4wc4wc4](https://discourse.julialang.org/u/wc4wc4wc4)\
**Post date:** [March 10, 2022, 4:49pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/2 "2022-03-10T16:49:44Z")

</div>

I think that a MWE would be beneficial, otherwise it’s quite difficult to help.

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [March 10, 2022, 5:00pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/3 "2022-03-10T17:00:23Z")

</div>

I apologise for not having done so already. I will do my best, but I’ve been advised not to share too much of the code I’m using so I don’t know how useful it will ultimately be.

---

<div class="post-metadata">

**Author:** ![wc4wc4wc4](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wc4wc4wc4/32/23038_2.png) [@wc4wc4wc4](https://discourse.julialang.org/u/wc4wc4wc4)\
**Post date:** [March 10, 2022, 5:04pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/4 "2022-03-10T17:04:33Z")

</div>

Then simulate som data, if you cannot reveal the real data. I think that would make more people able to help.

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [March 10, 2022, 5:49pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/5 "2022-03-10T17:49:09Z")

</div>

What sort of data would be useful? I have saved some chains saved, and some data from the output of my ODE.

Edit: I think I misinterpreted your comment: It’s not the data that is not shareable, but the code itself cannot be shared publicly due to how the automatic code plagiarism detection works. I can _try_ to come up with a MWE but even then I’m not sure how useful it will be because the setup and model are quite particular.

---

<div class="post-metadata">

**Author:** ![PeetoomHeida](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/peetoomheida/32/23865_2.png) [@PeetoomHeida](https://discourse.julialang.org/u/PeetoomHeida)\
**Post date:** [March 10, 2022, 8:29pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/6 "2022-03-10T20:29:43Z")

</div>

Sorry for being off topic, but can you share the code to make the visualization of the posterior? I haven’t been able to figure out how to do so.

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [March 10, 2022, 8:53pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/7 "2022-03-10T20:53:34Z")

</div>

No worries, the code for creating the visualisations can be found here:  
[https://turing.ml/dev/docs/using-turing/sampler-viz](https://turing.ml/dev/docs/using-turing/sampler-viz)

There are a few things you need to change (names of variables) to get it to work for your model/chain, but it’s relatively straightforward.

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [March 10, 2022, 9:03pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/8 "2022-03-10T21:03:03Z")

</div>

I can’t believe this, but the chains getting stuck seemed to be an issue of type-instability. After I checked the code with `@code_warntype` I discovered that there were some global variables over which I had defined closures. Hence the return type of my Turing model was `Any`.

I think this had an effect on the \epsilon heuristic for the leapfrog integrator. I might submit an issue on the Turing repo to find out where this came from.

The speedup after fixing this was about 30 times btw…

Never use global variables, kids.

16/04 Edit: This did not fix the problem entirely, however it made it possible to run the simulations faster and diagnose possible problems. I think the chains getting stuck is an issue of the \epsilon heuristic being tricked by a very rough posterior.

---

<div class="post-metadata">

**Author:** ![Sahil\_Khan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sahil_khan/32/47573_2.png) [@Sahil\_Khan](https://discourse.julialang.org/u/Sahil_Khan)\
**Post date:** [January 30, 2025, 12:30pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/9 "2025-01-30T12:30:40Z")

</div>

I have similar issue posted [here](https://discourse.julialang.org/t/identical-samples-during-mcmc-run-in-turing-jl-with-nuts-algorithm/125361).

So, what exactly solved your issue?

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [January 30, 2025, 12:47pm UTC](https://discourse.julialang.org/t/turing-jl-mcmc-chains-getting-stuck/77696/10 "2025-01-30T12:47:00Z")

</div>

My method had a part that was undifferentiable and I was using NUTS which relies on gradients. It was never going to work in the first place and the fact that it even did a little bit is surprising.