I programmed a Bugs model (see below) and got this horrible and useless error message: Bugs opened a “Trap: incompatible copy” window, and there was nothing in the log window but this:
display(log)
check(C:\DOCUME~1\ANDREW~1\LOCALS~1\Temp\RtmpMCdEbN/pewpoststrat2.bug.txt)
No syntax error, no nothing. My first thought, of course, was that there was something wrong with the default directory, but when I copied the “schools” example over, it worked fine. So I went through the laborious process of debugging, stripping down the code until I could get it to run and then gradually adding back lines until it crashed. I still couldn’t figure out what was wrong so I brought Matt over and he figured it out at a glance.
Here was the original code:
model {
for (i in 1:n.state){
for (j in 1:n.inc){
m[i,j] ~ dpois (E.m[i,j])
E.m[i,j] ~ dlnorm (E.log.E.m, tau[1])
E.log.E.m <- a[i] + b[j] + log(offset) + log(pop[i,j]) - log(w.bar[i,j]) theta[i,j] <- E.m[i,j]*w.bar[i,j] } } for (i in 1:n.state){ a[i] ~ dnorm (E.a, tau[2]) c.a[i] <- a[i] - mean(a[]) } E.a ~ dnorm (0, .01) for (j in 1:n.inc){ b[i] ~ dnorm (E.b, tau[3]) c.b[i] <- b[i] - mean(b[]) } E.b ~ dnorm (0, .01) for (k in 1:3){ tau[k] ~ dgamma (a.tau, b.tau) sigma[k] <- 1/sqrt(tau[k]) } a.tau ~ dunif (0,10) b.tau ~ dunif (0,10) }
What was annoying is not that the code didn’t run–I did have a typo, after all–but that Bugs didn’t even get to the point of pointing that out.
P.S. Yeah, I know, Bugs is free so I shouldn’t really complain.
For those of us who aren't quite literate, what was the (ahem) bug?
Writing good error messages is hard because the computer might have a very different view of what went wrong from the user. So the programmer has to anticipate all the stupid things the user might do (no offence) and catch them before the error propagates down to a very low level of the program, where it is impossible to construct a useful error message.
I fed this into jags with some fake data, but the error message was not very helpful either. So I added line number information and it now reads
<pre>
RUNTIME ERROR:
Compilation error on line 20.
Cannot evaluate subset expression for b
</pre>
Then, when you have fixed that, you find the second bug.
<pre>
RUNTIME ERROR:
Compilation error on line 8.
Attempt to redefine node E.log.E.m[1]
</pre>
This is only in the development version, of course.
When I cut and pasted this code into a file, I added two lines, so "model" is on line 3 according to the above messages.
I've been running WinBUGS a lot lately using R2WinBUGS, and I've been getting the error you mention a lot. Here's how I track down errors like that.
1) WinBUGS blows up.
2) Open WinBUGS directly instead of through R2WinBUGS.
3) Load the code into WinBUGS.
4) Check model. If it blows up on the model check, there will be a (barely visible) error message on the lower left part of the WinBUGS frame and the cursor will stop at the offending point in the file. (It may be hard to find the cursor, but it's there if you stare at it long enough.)
5) If it compiles, load the data. If it blows up on loading, you'll get a message as before, and the (barely visible) cursor will point to the offending data.
6) Load inits (if there are any) and compile. If it blows up on the compile, you'll get an error message telling you what the problem is.
7) After that you'll just start getting those difficult to diagnose traps.
It's frustrating, but it's easier than writing the MCMC code from scratch.
just to clarify, i don't want to start up R and invent fake data:
1) in the first nested loop, it needs to be E.log.E.m[i,j] ?
2) the third for loop defines the prior for the b[i] but also tries to access all of b — "mean(b[])" — thereby confusing the compiler?
Martyn: Very nice. We should talk about taking my ideas for implementing redundant parameterization for hierarchical models and implementing in Jags.
AT, Fabian: The code had lots of bugs. The E.log.E.m thing, also I had indexes "i" in the "j" loop.
"BUGS sucks", but apparently not enough to get the user community behind JAGS as a replacement. What's it going to take?
Greg: Ideally someone will throw a couple million dollars at Bugs, or Jags, or whatever, and have a good open-source version. We all know pretty much what to do, or where to start. It just takes time and effort, and we're all basically doing it for free in our spare time.
Users are not happy with the stability and rough edges of BUGS ("if you only get one trap, your results are probably ok"), but we continue to use it. The only lesson I can take from this is "just good enough is good enough". (Background: I once supported a group that used BUGS and had the pleasure of meeting Martyn at the IceBUGS meeting a few years ago.)
BTW I'm a big fan of your books. I read the Bayes book several years ago and recently started on the multilevel/hierarchical book.
Dear Dr. Gelman:
Hope you a restful holiday!
I have a question re. using the R package: R2WinBUGS.
I read one of your discussion papers, the one entitled "Some thoughts on the BUGS package for Bayesian analysis" (19 May 2009), and notice that you mention BUGS doesn't perform well in the following situations: large scale datasets, multivariate structure, model containing regression coefficients, etc.
Yes, i run into the similar situation while calling BUGS from R: some of the model parameters even cannot converge.
However, if I run the analysis in WinBUGS directly, there is no such problem–each model parameter converges reasonably.
I wonder how I can deal with this situation: whether calling BUGS from stata or using "R2jags" will help me solve the problem?
Thanks in advance for reading my post and your any response is gratefully received!
Here is a different twist on the "Trap: incompatible copy" error. Within R I had been writing the model code to mymodel.bug file and then calling bugs() to run Winbugs. On two of my computers all worked as advertised but on the third I kept getting the above error when the script was on the check model file line. After uninstalling and reinstalling (R 2.9.1, Winbugs 1.4.3) I still got the error. However, if I changed to writing the model to mymodel.txt then no more incompatible copy error.
Andrew, I came across your post while googling the "Incompatiable Copy" error. None of the above suggestions worked for me, but what did the trick was specifying the optional argument for the bugs working directory in the bugs() function. For what its worth I run winbugs on a mac using darwine.