A major obstacle to debugging cluster-based parallel
applications is the lack of a terminal, thus precluding direct use of
debug and browser. This set of functions consists of
two groups, one for ``quick and dirty'' debugging, that writes
debugging information to disk files, and the other for more
sophisticated work that deals with the terminal restriction. For both
methods, make sure setclsinfo has been called.For ``quick and dirty'' debugging, there is dbsmsg, which prints
messages to files, invoked from within code running at the cluster nodes.
There is one file for each member of the cluster,
e.g. dbs.001, dbs.002 and so on, and dbsmsg writes
to the file associated with the worker invoking it. Initialize via
dbsmsgstart.
The more elaborate debugging tool, dbs, is the only one in this
partools package requiring a Unix-family system (Linux, Mac). To
discuss it, suppose you wish to debug the function f in the file
x.R. Run, say, dbs(2,xterm="xterm",src="x.R",ftn="f").
Then three new terminal windows will be created, one for the cluster
manager and two for the cluster workers. The cluster will be named
cls. Automatically, the file x.R will be sourced by the
worker windows, and debug(f) will be run in them.
Then you simply debug as usual. Go to the manager window, and run
your parallel application launch call in the usual way, say
clusterEvalQ(cls,f(5)). The function f will run in each
worker window, with execution automatically entering browser mode. You
are now ready to single-step through them, or execute any other browser
operation.
If xterm is NULL, you will be prompted to create the terminal
windows by hand (or use existing ones), and run screen there as
instructed. Terminal works on Macs; label the windows by hand,
by clicking "Shell" then "Edit".
When finished with the debugging session, run killdebug from the
original window (the one from which you invoked dbs) to quit the
various screen processes.