Distributed-memory architectures

To compile a distributed application, it is necessary that PVM be installed either in the system path or in the directory pointed to by the environment variable PVM_ROOT (this can be your home directory if PVM is not already installed on your network). To install PVM yourself, the current version can be obtained at http://www.csm.ornl.gov/pvm/. It should compile and install without problems on most architectures. You will have to make a few modifications to your .cshrc file, such as defining the PVM_ROOT environment variable, but this is all explained clearly in the PVM documentation. Note that all executables (or at least a link to them) must reside in the $PVM_ROOT/bin/$PVM_ARCH directory in order for parallel processes to be spawned correctly. The environment variable PVM_ARCH is set in your .cshrc file and should contain a string representing the current architecture type. To run a parallel application, you must first start up the daemon on each of the machines you plan to use in the computation. How to do this is also explained in the PVM documentation.

To configure for a parallel build with the default parallel configuration, invoke the configuration script as follows:

 ./coinbrew fetch build SYMPHONY@\VER --with-pvm
Note that there are a number of different parallel configurations (see Chapter 4.3.3 for an overview of SYMPHONY's parallel modules). The default configuration is to build two parallel modules, the first consisting of the master, tree management, and cut management modules, while the second consisting of the node processing, and cut generation modules. To build in another configuration, there are four configure flags that control which modules run as separate executables and which are called directly in serial fashion. The variables are as follows:
–with-cg: If set, then the cut generator function will be called directly from the LP in serial fashion, instead of running as a separate executable. This is desirable if cut generation is quick and running it in parallel is not worth the price of the communication overhead.
–with-cp: If set, then the cut pool(s) will be maintained as a data structure auxiliary to the tree manager.
–with-lp: If set, then the LP functions will be called directly from the tree manager. When running the distributed version, this necessarily implies that there will only be one active subproblem at a time, and hence the code will essentially be running serially. In the shared-memory version, however, the tree manager will be threaded in order to execute subproblems in parallel.
–with-tm: If set, then the tree will be managed directly from the master process. This is only recommended if a single executable is desired (i.e. the three other variables are also set to true). A single executable is extremely useful for debugging purposes.
These variables can be set in virtually any combination, though some don't really make much sense. Note that in a few user functions that involve process communication, there will be different versions for serial and parallel computation. This is accomplished through the use of #ifdef statements in the source code. This is well documented in the function descriptions and the in the source files containing the function stubs.

Once configured, follow the build instructions in Section 2.1.1 to build the code. Note that this will also compile the sequential version. Make sure there are links from your $PVM_ROOT/bin/$PVM_ARCH subdirectory to each of the executables in your bin/ directory, as required by PVM. In order to keep track of the various possible configurations, executable and their corresponding libraries are named as follows. The name of each executable is symphony, along with a combination of the (abbreviated) names of the modules that were combined to produce that executable joined by underscores: m for the master module, tm for the tree management module, lp for the node processing module, cg for the cut generation module, and cp for the cut management module. For instance, in the default distributed configuration, the executables produced are symphony_m_tm_cp and symphony_lp_cg.

To test the parallel version, first start the PVM daemon by typing pvm on the command line and then typing quit. As above, invoke SYMPHONY using the sample MPS file called sample.mps included with the distribution. To specify the file name, use the -F command-line option, i.e., in the root directory, type

 bin/symphony_m_EXT -F SYMPHONY/Datasets/sample.mps

where EXT is the extension to be added according to the chosen configuration of the modules.