[Symphony] SYMPHONY with PVM

[Ted Ralphs]

Hi guys,

I just made a release 5.6.10 that should fix this problem. Enjoy!

Cheers,

Ted

On Mon, Mar 16, 2015 at 10:16 AM, Alfred Pennyworth <
batcavecluster at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Symphony mailing list
> Symphony at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/symphony
>
>


-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/symphony/attachments/20150404/8bc2575c/attachment.html>