Multiprocessor BUGS


There is a version of OpenBUGS software family which runs on multiple processors. Each chain of the simulation can run on a seperate processor. There are some overheads in running OpenBUGS this way, however for computationally intense models good speed ups can be achieved. This multiprocessor version of OpenBUGS is called MultiBUGS , and is started by clicking on the MultiBUGS icon. The user interface of MultiBUGS is very similar to that of OpenBUGS.

Parsing and loading data are identical in MultiBUGS and single processor OpenBUGS. At compilation, one chain of the graphical model is compiled and then the graph writen out to multiple restart files, the seed of the random number generator being set differently in each file. Initial values for a particular chain are loaded by internalizing the chain from its restart file, setting the initial values and writing the chain back to its restart file. Initial values are generated by loading each chain from its restart file, generating inits and then writing back to file.

The first chain in a MultiBUGS simulation is updated in the MultiBUGS process. The second and any further chains are updating in separate processes running a stripped-down version of OpenBUGS. We call these processes SlaveBUGS, they just read in the appropiate restart file, do some iterations and then write out to the restart file again (there is no user interaction).

Monitors are set by reading each chain into MultiBUGS from its restart file, setting the desired monitor, and then writing the chain out again. (This is a bit slow for large models, but it should be possible to speed up). The results stored in the monitors can be quickly read from the restart files without having to load the chain into MultiBUGS.

A new set of monitors classes has been developed which can read stored monitor values from disc. These classes are implemented as wrappers round the standard monitor classes that OpenBUGS uses, with most methods just forwarding to the wrapped class. These disc-based monitors are implemented in modules whose name contains the word "Disc". Each of these disc based monitor modules is a "plug in"; their module just sets the factory object of the wrapped class so that it produces the wrapping class.

MultiBUGS is set up so that the GUI interface will respond to the user after every "refresh" iterations. The launching of SlaveBUGS takes about 0.2 seconds so "refresh" must not be set too small or the whole simulation will be slowed. By default "refresh" is set at 1000 in MultiBUGS. For example, running the seeds model with two chains on a dual-processor system, 10000 updates takes 6 seconds with "refresh" set at 1000 and 4 seconds with "refresh" set at 10000. Running the same model on a single processor, 10000 updates takes 7 seconds. MultiBUGS is intended for use in large, computationally-intensive models so the overhead due to each refresh should not be a serious problem.