"Trap 66" Error in simple logistic regression model

[Andrew Jebb]

I am running a relatively basic logistic regression model and keep encountering a "Trap 66 Postcondition" Error. In the trap dialog box, I believe I have identified the problem, as the module, "logFright " is at -Infinity when the error occurs.

Note: I can run this exact model in WinBUGS itself without any problem.

My model is simple:
1. The distribution is binomial with a logit link.
2. The Response box is "Outcome/1" which specifies a Bernoulli distribution where each observation where the event occurred is coded as a "1"  in my data set.
3. Priors are basically the default diffuse priors

From Googling this trap message in WinBUGS, it seems that it is mostly the result of an overly wide prior distribution for the a variance or precision parameter or bad starting chain values. However, since error this doesn't occur in WinBUGS, I am convinced that it is the initial values generated by BugsXLA that is causing the problem (and really slow sampling). I also tried reducing the variance parameter for each regression slope, but that was ineffective.

Will there be an update soon that allows for user-specified initial values? I am skeptical of the validity of the starting MCMC values provided by BugsXLA, perhaps because those generated by WinBUGS were typically poor and frequently caused errors.

Any other suggestions for resolving this?

[Phil Woodward]

Apologies as it is likely to be some time before I find the time to provide further updates to BugsXLA, although allowing user control of the initial values (and better default priors for log & logistic links) is top priority when I do.  The workaround is to alter the prior distribution that BugsXLA provides as the initial values are often proportional to these.  I didn't choose very good default priors for log or logit links, these being too wide. The SD parameter for the Normal priors on the logit scale can be greatly reduced from BugsXLA defaults without making them very informative.  Refer to books and articles by Gelman or Spiegelhalter and others for better guidance on more appropriate vague priors for logistic case.  A prior SD of the order 10 rather than 100 should still be quite vague - do some calculations to assess the prior credible range and use the posterior plotting tool in BugsXLA to compare the prior-posterior distributions for evidence of undue influence.  Hope this helps.

[Andrew Jebb]

Thanks for the response. Actually, I figured out where the problem lay, and it had nothing to do with the initial values or the variance of the prior distributions. It was that the sampler (I think) was sampling improper values for the log odds-ratio coefficients (i.e., negative values). After setting the priors for the logistic regression coefficients to a (positive) half-normal distribution, the analysis worked fine. Glad to hear that user specified initials is on its way!

[Andrew Jebb]

Actually, this isn't right; the coefficients in a logistic model should be able to be negative prior to taking the exponential function of them. Using a half-normal prior is skewing the results. I'm still unsure what's causing the error. Also, another oddity is that when I change the order of the levels of the factor that is my DV, there is a crash even when half-normal priors are specified. Any thoughts on this, Phil?

[Andrew Jebb]

Another note: it's not the priors for the coefficients or the ordering of the levels that makes it crash. It's the number of covariates. When any two are included, the model runs well. Adding in a third--no matter the combination--causes it to crash. From reading online, it seems that it's b/c the BUGS sampler is generating inappropriate values for the parameter Bernoulli parameter, p, that are either below 0 or above 1. Again, any recommendations, Phil?

[Andrew Jebb]

You know what, after waiting two days, I tried the exact model I was able to use in WinBUGS (normal priors with a mean of 0 and sd of 100) and it worked fine. Some bugs to work out, but it's good to know that if the model is coherent in WinBUGS alone to keep trying!