<div dir="ltr"><div>Dr. Ralphs and SYMPHONY team,</div><div><br></div><div>Our team has continued our efforts to use SYMPHONY, but we&#39;ve hit another  impasse.  We can consistently &quot;make&quot; SYMPHONY using the information you previously gave us, but we can&#39;t seem to make it work properly.</div><div>We start SYMPHONY in distributed memory parallel processing mode  from the command line as follows:</div><div>symphony_m_tm_cp -f &lt;configuration.file&gt; -F &lt;problem.file&gt; [-p #]</div><div>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 &quot;-p #&quot; 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.</div><div>When the configuration file sets max_active_nodes to any integer N &gt; 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&#39;s standard output will display the table of &quot;Time  Done  Queued  LB  UB Gap&quot; as normal; Time increments, but &quot;Done&quot; and &quot;Queued&quot; remain at 0 and 1, respectively.  As before, the presence or absence of &quot;-p #&quot; and value of # have no apparent effect.  When we force SYMPHONY to exit gracefully (Control-C, e while running), all outputs are 0 except:</div><div><br></div><div>Total Wallclock Time: the number of seconds we let SYMPHONY run</div><div>Ramp Up Time (TM): approximately the number of lp processes * wallclock time</div><div>Total User Time: on the order of 0.01</div><div>Number of created nodes: 1</div><div>Size of the tree: 1</div><div>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.</div><div>We don&#39;t know whether it&#39;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).</div><div>We&#39;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 &gt; 1.</div><div>We&#39;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.</div><div><br></div><div>We’ve also located a file named “&lt;SYMPHONY’s root folder&gt;/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?</div><div><br></div><div>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?</div><div><br></div><div>Many thanks in advance,</div><div>David, John, and Tom</div><div><br></div>
</div>