[Symphony] SYMPHONY with PVM

Alfred Pennyworth batcavecluster at gmail.com
Mon Mar 16 10:16:58 EDT 2015


Dr. Ralphs and SYMPHONY team,

Our team has continued our efforts to use SYMPHONY, but we've hit another
 impasse.  We can consistently "make" SYMPHONY using the information you
previously gave us, but we can't seem to make it work properly.
We start SYMPHONY in distributed memory parallel processing mode  from the
command line as follows:
symphony_m_tm_cp -f <configuration.file> -F <problem.file> [-p #]
When configuration.file either does not specifiy max_active_nodes or
specifies max_active_nodes to be 1, an instance of symphony_m_tm_cp will
start on the initiating machine and a single instance of symphony_lp_cg
will start on one of the machines currently running pvm (we have not
noticed a pattern in which machine is selected).  The presence of absence
of "-p #" on the command line has no apparent impact, regardless of the
value of #.  SYMPHONY will then solve the problem using a single processor
to do all LP solving tasks.
When the configuration file sets max_active_nodes to any integer N > 1, we
get a single instance of symphony_m_tm_cp on the calling machine as well as
N instances of symphony_lp_cg spread over the available machines.  However,
the problem is not solved.  The calling machine's standard output will
display the table of "Time  Done  Queued  LB  UB Gap" as normal; Time
increments, but "Done" and "Queued" remain at 0 and 1, respectively.  As
before, the presence or absence of "-p #" and value of # have no apparent
effect.  When we force SYMPHONY to exit gracefully (Control-C, e while
running), all outputs are 0 except:

Total Wallclock Time: the number of seconds we let SYMPHONY run
Ramp Up Time (TM): approximately the number of lp processes * wallclock time
Total User Time: on the order of 0.01
Number of created nodes: 1
Size of the tree: 1
In the latter case, we were expecting that SYMPHONY would use the
additional instances of symphony_lp_cg to simultaneously analyse multiple
nodes.  If this is how the parallel processing feature is meant to work, it
seems that the master process is starting the appropriate number of other
processes, but something is preventing the Tree Manager process from
assigning tasks to the LP processes.
We don't know whether it's relevant, but when we use lp_mach_num and the
associated parameters in the configuration file, SYMPHONY always starts the
expected number of instances of symphony_lp_cg and always exclusively on
the specified machine(s).
We've attempted to make and call SYMPHONY using most of the documented
compile time and run time parameters, and none (except as noted) have any
effect on SYMPHONY’s behavior whenever max_active_nodes > 1.
We've also attempted to configure and make SYMPHONY with the modules
divided in other configurations and have been unable to successfully make
an installation with executables other than clp, symphony,
symphony_m_tm_cp, and symphony_lp_cg.  We’ve used both config.site and
command-line options as described in the user manual to configure to try to
build SYMPHONY with the modules divided differently, but any configuration
that would lead to executables other than the above fails during the make
process.

We’ve also located a file named “<SYMPHONY’s root folder>/SYMPHONY/config”
that appears to be meant to control many of the same parameters as
config.site, notably use of PVM, static vs. shared libraries, and module
compilations (specifically SYM_COMPILE_IN_LP = FALSE).   We’ve re-compiled
and re-installed SYMPHONY after editing those parameters to match the ones
set in config.site.  We haven’t found any references to this configuration
file in the documentation; is it still used, or is it something carried
forward from a previous version?

Are we misunderstanding how SYMPHONY is meant to run in a distributed
memory parallel setup, or simply mis-calling or mis-configuring the
program?  Is there anything else we can do that might help identify or
solve the problem?

Many thanks in advance,
David, John, and Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/symphony/attachments/20150316/ad9ba8f2/attachment.html>


More information about the Symphony mailing list