Interpreting WinBUGS traps and how to automate the program?

Question

First of all, does anybody know of a developer's guide for WinBUGS? The website is full of detailed examples for Doodles and documentation for the model language, but I have yet to find anything about how to interpret trap windows.

Secondly, has anybody found any ways to streamline the check/load/compile/init/monitor/update cycle? By that I mean, there doesn't seem to be any way to say "don't bother rechecking the model or putting any of the settings back to their defaults (!!!), just keep loading data from these files, inits from those files, and for each generate a new coda". Even the standard Windows shortcuts are neutered here, forcing the user to keep clicking and filling the same fields with the same values over and over. This might seem like a minor issue, but when you are doing many similar analyses one after the other, it gets old fast.

I'm at the point where I'm about to use TRON.EXE to send fake mouseclicks to the program, but before going to that extreme I'm hoping there is some native and more elegant way to automate repetitive WinBUGS tasks.

Answer 1

Well... that's WinBUGS at its normal :-) Unfriendly, showing traps that would scare of an experienced kernel hacker.. :-) I don't think there exist some guide to traps. I mean if WinBUGS creators wanted to put some effort in being more user friendly, they would probably first made the traps more understandable, so that no guide was necessary.

I was trying to do something similar - i.e. to customize WinBUGS behaviour. First, you can call WinBUGS from R using R2WinBUGS. That way you are able to do a lot automatization but not all. For example, I wanted to have something like progress information in WinBUGS. The problem is that WinBUGS UI gets stuck during update cycles. R2WinBUGS creates the script.txt command script and there is command update (<big number of cycles>). What I wanted here was to customize this script.txt to contain a lot of smaller update(..) commands instead of one big one. But, the problem is that R2WinBUGS generates this script itself and you cannot change it.

So the way to customize WinBUGS could be that you create your own wrapper that creates the script.txt and other files. I believe you could do a lot more customization to WinBUGS this way.

However, I'm not sure if WinBUGS is worth it. Its development has stopped and while favorited by many people, it remains rigid. You can try JAGS or CppBugs which seem to have much more promissing future.

Answer 2

For a wrapper around R2WinBUGS that adds lots of functionality to streamline serious WinBUGS use, see my package rube (http://www.stat.cmu.edu/~hseltman/rube/) which is not yet on CRAN.

Among other things, it gives plain English error messages rather than passing your model/data/inits along to WinBUGS when a trap error is certain. It also gives a highly useful summary of your model/data/inits for finding problems that cannot be automatically detected. Of course, it does not catch all trap errors.

Answer 3

Turns out I didn't RTFM enough on the second part of my question. It turns out that the section of the WinBUGS 1.4 manual entitled "Batch-Mode: Scripts" lists all the batch commands. All the important UI functionality has a batch-mode command. There was only a little trial-and-error in getting the arguments right (for example over.relax('true')). What really took me a while to sort out is that WinBUGS seems to have trouble with some Windows paths, but as long as everything is in a subdirectory of the directory where WinBUGS is installed, it runs okay.

It's still kind of messy to have to keep loading all these little files, but I wrote an R-script that uses functions from the BRugs package to create all the files, name them in a consistent pattern, and generate a script that will then initialize the model and load them, over and over again.

I'll leave this question open for a while, though, to see if anybody has any suggestions on where I can learn to make better use of traps.