Dear Wayne,
> Here at the Upper Midwest Environmental Sciences Center we are evaluating
> the potential for developing a Linux-based BUGS. Our interest is in
> speeding up processing from what currently takes nearly 3 days per run
> (with final models historically averaging nearly one month of development
> time). We hope that by creating "LinBUGS" we might be able to implement a
> clustered-processing approach whereby we share the simulations across a
> number of computers.
Personally, I'd love to see a cross-platform WinBUGS. One can compile
Component Pascal to Java using the Gardens Point CP compiler, but the BlackBox
development environment is much more than the language itself.
> A simplistic approach would be running single chains
> on individual computers and then combining them post hoc. Another approach
> might be to actually split some of the processing within chains across
> multiple computers; it is this latter approach that would harness the power
> of clustered computing.
Usually, a single iteration doesn't take very long; I would have thought that
this kind of approach would scale poorly due to the need to synchronize across
multiple processors. Given that you want to try out different initial values,
and have poor mixing of chains, I would've thought that multiple independent
chains would be the way to go.
> Before we go off on some goose chase, I would like
> to hear from the BUGS community about this issue. If you have previously
> considered or implemented a clustered-computing approach for BUGS, please
> contact me.
A while back, I wrote a little Python script that does just that; it writes a
WinBUGS script, and then runs it on multiple processors - in this case,
Windows NT/XP/2000 machines running MPICH. My website is down at the moment,
but I can send you the script and woefully brief documentation. I would've
thought you could do much the same thing with R, although I haven't played
with parallelized R on Windows.
> Also, I'm rather interested in whether others feel processing
> time currently constrains the questions one might ask. We currently run
> our models on machines (1 gb RAM, 1.80 GHz processing speed) that aren't
> puny; each iteration takes on the order of 17 seconds. Because convergence
> on most of the spatial models I'm working with doesn't occur until
> somewhere around 18,000 iterations, that's 2.8 days in a single run.
Might your models benefit from some hard coding using the WinBUGS development
interface? At the moment, only functions can be hard coded, but if it's like
other scripting languages, hard coding the loops may help a lot.
Best
Simon Frost
> Thanks for any discussion this might generate,
>
> Wayne E. Thogmartin, PhD
> Statistician (Biology)
> USGS Upper Midwest Environmental Sciences Center
> 2630 Fanta Reed Road
> La Crosse, WI 54603
> 608.781.6309
> [log in to unmask]
> www.umesc.usgs.gov/staff/bios/wet0.html
>
> -------------------------------------------------------------------
> This list is for discussion of modelling issues and the BUGS software.
> For help with crashes and error messages, first mail [log in to unmask]
>
> To mail the BUGS list, mail to [log in to unmask]
> Before mailing, please check the archive at
www.jiscmail.ac.uk/lists/bugs.html
> Please do not mail attachments to the list.
>
> To leave the BUGS list, send LEAVE BUGS to [log in to unmask]
> If this fails, mail [log in to unmask], NOT the whole list
-------------------------------------------------------------------
This list is for discussion of modelling issues and the BUGS software.
For help with crashes and error messages, first mail [log in to unmask]
To mail the BUGS list, mail to [log in to unmask]
Before mailing, please check the archive at www.jiscmail.ac.uk/lists/bugs.html
Please do not mail attachments to the list.
To leave the BUGS list, send LEAVE BUGS to [log in to unmask]
If this fails, mail [log in to unmask], NOT the whole list
|