## The mysterious ‘Trap 66 (postcondition violated)’

February 14, 2011 by Aurélien

WinBUGS is renowned for its cryptic error messages. Recently, while trying to fit a logistic model, I have been getting the message ‘Trap 66 (postcondition violated)’. There is not much on the web on the possible causes for this. There are however a few mentions such as on page 10 of this document and on page 251 of this document. In both cases, variance priors are identified as the culprits. Indeed, in my case changing the prior on the random effects standard deviation from dunif(0, 100) to dunif(0, 10) solved my problem.

PS: This post seems to attract some traffic probably because it is a common problem with no clearly identified cause. It might help if people who have encountered this problem could leave a short description and how they solved it as a comment.

### Like this:

Like Loading...

*Related*

on March 24, 2011 at 5:01 pm |janamarieI had this very same problem and solved it by increasing the prior precision.

on August 1, 2011 at 2:57 pm |thegreatsaundiniI had this problem too, but actually overcame it by changing my initial values.

on August 10, 2011 at 11:21 am |MafaldaSame problem, same solution. Changed the prior on the standard deviation from dunif(0, 100) to dunif(0, 10).

on March 8, 2012 at 10:21 am |NEINEYes,it’s apear that the problem come from the prior distribution, so, the solution is to give more spesification to the priori and better initial the chians.

on April 28, 2012 at 11:36 am |SubbiahI too got the same problem and followed the above steps. Still i got GLM1 as a message and no more response from WinBUGS. Can anyone help? Thanks

on April 30, 2012 at 7:59 am |AurélienHard to tell without a reproductible example. Maybe you could ask on the BUGS list (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=bugs)?

on May 25, 2012 at 4:53 pm |ryanThis problem also commonly arises in models with boundary conditions on probabilistic nodes. It can often be overcome by switching the sampler form rejection to slice. Andrew Gelman also has suggestions on his blog.

on August 27, 2012 at 12:02 pm |ArmelleSame problem here, fitting a zero-inflated negative binomial model. The initial values were the problem. A mixture of 0 and 1 for the initials of the zero inflation u parameter solved the issue. (Note: Various gamma priors (with or without constraint) for the dispersion parameter didn’t solve the problem).

on December 16, 2013 at 1:57 pm |Pepijn VemerIntruiging. I tried to solve this problem by doing the same thing: making the prior standard error smaller. However, I kept running into problems. After a while I instead INcreased the prior from dunif(0,10) to dunif(0,100). So far (fingers crossed), this seems to have solved my problems.

It could be because I don’t model the standard deviation directly, but rather a tau, which is transformed into the standard deviation using pow(tau,-2), which I should make it bigger rather than smaller.

I went the opposite direction, because I noticed that right before the Trap 66 condition (I manage to replicate the problems several times), the offending standard deviation suddenly had a very high value (as these standard deviations tend to have every now and then) as evidenced by the trace. I hypothesized it actually tried to move beyond the boundaries I gave and therefore gave the error message. So far, so good.

I did initialize relatively close to zero though.

on January 20, 2014 at 8:09 pm |Pepijn VemerOK, so that didn’t really work. But I think I have figured it out by now. I also posted a blog about it. Hope you’ll find it helpful. http://aheblog.com/2014/01/08/solution-for-trap-66-postcondition-violated/

on January 21, 2014 at 9:32 amAurélienThanks. Hopefully, this will work in all cases!

on January 8, 2014 at 6:00 am |Solution for Trap 66 (Postcondition violated) | The Academic Health Economists' Blog[…] priors have been identified as the culprits. The suggested solutions I could find (for example here, here and here) all point towards those priors being too big. The standard advice is then to reduce […]

on January 27, 2014 at 11:57 am |Rubén AmorósI had this problem when changing a psi[…] ~ car.normal[…] to a psi[…] ~ car.proper[…].

The problem (solved by my PhD advisor, he rules!) was in the inits of psi. I was setting them as all zeroes. I substituted that by random uniforms between -0.1 and 0.1 and it got solved.

Hope it helps someone!