%===========================================================================%
%                                                                           %
% This file is part of the documentation for the SYMPHONY MILP Solver.      %
%                                                                           %
% SYMPHONY was jointly developed by Ted Ralphs (ted@lehigh.edu) and         %
% Laci Ladanyi (ladanyi@us.ibm.com).                                        %
%                                                                           %
% (c) Copyright 2000-2011 Ted Ralphs. All Rights Reserved.                  %
%                                                                           %
% SYMPHONY is licensed under the Eclipse Public License. Please see         %
% accompanying file for terms.                                              %
%                                                                           %
%===========================================================================%

\label{parameter_file}
Parameters can be set in one of two ways. Some commonly-used parameters can be
set on the command line. To see a list of these, run \BB\ with no command-line
arguments. Other parameters must be set in a parameter file. The name of this
file is specified on the command line with ``\texttt{-f}''.  Each line of the
parameter file contains either a comment or two words -- a keyword and a
value, separated by white space. If the first word (sequence of
non-white-space characters) on a line is not a keyword, then the line is
considered a comment line. Otherwise the parameter corresponding to the
keyword is set to the listed value. Usually the keyword is the same as the
parameter name in the source code. Here we list the keywords, the type of
value that should be given with the keywords and the default value. A
parameter corresponding to keyword ``K'' in module ``P'' can also be set by
using the keyword ``P\_K''.

To make this list shorter, occasionally a comma separated list of parameters
is given if the meanings of those parameters are strongly
connected. For clarity, the constant name is sometimes given instead
of the numerical value for default settings and options. The
corresponding value is given in curly braces for convenience.

\subsection{Global parameters}
\begin{description}
\item[\ptt{verbosity} -- integer (0).] 
\sindex[p]{\GP!verbosity}
Sets the verbosity of all modules to the given value. In general,
the greater this number the more verbose each module is. Experiment
to find out what this means.

\item[\ptt{random\_seed} -- integer (17).] 
\sindex[p]{\GP!random\_seed}
A random seed.

\item[\ptt{granularity} -- double (1e-6).]
\sindex[p]{\GP!granularity}
Should be set to ``the minimum difference between two distinct
objective function values'' less the epsilon tolerance. E.g., if every
variable is integral and the objective coefficients are integral then
for any feasible solution the objective value is integer, so {\tt
granularity} could be correctly set to .99999.

\item[\ptt{upper\_bound} -- double (none)]. 
\sindex[p]{\GP!upper\_bound}
The value of the best known upper bound.

\item[\ptt{probname} -- string (empty string).]
\sindex[p]{\GP!probname}
The name of the problem name.

\item[\ptt{infile\_name} -- string (empty string).]
\sindex[p]{\GP!infile\_name}
The name of the input file that was read by ``-F'' or the ``-L'' flag.

\end{description}

\subsection{Master module parameters}
\begin{description}

\item[\ptt{M\_verbosity} -- integer (0).] 
\sindex[p]{\MP!M\_verbosity}

\item[\ptt{M\_random\_seed} -- integer (17).]
\sindex[p]{\MP!M\_random\_seed}
A random seed just for the Master module.

\item[\ptt{upper\_bound} -- double (no upper bound).] 
\sindex[p]{\MP!upper\_bound}
This parameter is used if the user wants to artificially impose an
upper bound (for instance if a solution of that value is already
known).

\item[\ptt{lower\_bound} -- double (no lower bound).] 
\sindex[p]{\MP!lower\_bound}
This parameter is used if the user wants to artificially impose a
lower bound.

\label{upper_bound_estimate}
\item[\ptt{upper\_bound\_estimate} -- double (no estimate).] 
\sindex[p]{\MP!upper\_bound\_estimate}
This parameter is used if the user wants to provide an estimate of the
optimal value which will help guide the search. This is used in
conjunction with the diving strategy \htmlref{\tt
BEST\_ESTIMATE}{diving_strategy}.

\item[\ptt{tm\_exe, dg\_exe} -- strings (``tm'', ``dg'').] 
\sindex[p]{\MP!tm\_exe} 
\sindex[p]{\MP!dg\_exe} 
The name of the executable files of the TM and DG modules. Note that
the TM executable name may have extensions that depend on the
configuration of the modules, but the default is always set to the
file name produced by the makefile. If you change the name of the
treemanager executable from the default, you must set this parameter
to the new name.

\item[\ptt{tm\_debug, dg\_debug} -- boolean (both {\tt FALSE}).] 
\sindex[p]{\MP!tm\_debug}
\sindex[p]{\MP!dg\_debug}
Whether these modules should be started under a debugger or not (see
\ref{debugging-PVM} for more details on this).

\item[\ptt{tm\_machine} -- string (empty string).] 
\sindex[p]{\MP!tm\_machine}
On which processor of the virtual machine the TM should be run. Leaving this
parameter as an empty string means arbitrary selection.

\item[\ptt{do\_draw\_graph} -- boolean ({\tt FALSE}).] 
\sindex[p]{\MP!do\_draw\_graph}
Whether to start up the DG module or not (see Section \ref{IGD} for
an introduction to this).

\item[\ptt{do\_branch\_and\_cut} -- boolean ({\tt TRUE}).] 
\sindex[p]{\MP!do\_branch\_and\_cut}
Whether to run the branch and cut algorithm or not. (Set this to {\tt
FALSE} to run the user's heuristics only.)

\item[\ptt{mc\_search\_order} -- integer ({\tt MC\_FIFO}).] 
\sindex[p]{\MP!mc\_search\_order}
Use the fifo (MC\_FIFO) or lifo (MC\_LIFO) searh order during the multi
criteria solution procedure.

\item[\ptt{mc\_warm\_start} -- boolean({\tt FALSE}).] 
\sindex[p]{\MP!mc\_warm\_start}
Whether to solve the corresponding problem of each iteration from a warm 
start loaded from a base iteration (which is the first iteration where 
gamma = 1.0 and tau = 0.0) or from scratch. Currently, this option is 
supported if only the supported solutions are desired to be found.

\item[\ptt{trim\_warm\_tree} -- boolean({\tt FALSE}).] 
\sindex[p]{\MP!trim\_warm\_tree}
Whether to trim the warm start tree before re-solving. This consists of 
locating nodes whose descendants are all likely to be pruned in the resolve 
and eliminating those descendants in favor of processing the parent node 
itself.

\item[\ptt{mc\_compare\_solution\_tolerance} -- double({\tt 0.001}).] 
\sindex[p]{\MP!mc\_compare\_solution\_tolerance}
If the difference between the objective values of two solutions to be compared,
during the bicriteria solution procedure, are less than this tolerance, then 
assume them to be equal. 

\item[\ptt{mc\_binary\_search\_tolerance} -- double({\tt 0}).] 
\sindex[p]{\MP!mc\_binary\_search\_tolerance}
The tolerance to be used to differentiate the gamma values if binary search 
is used during the bicriteria solution procedure. A value greater than zero
will cause the binary search to be activated.

\item[\ptt{prep\_level} -- integer({\tt 5}).]
\sindex[p]{\MP!prep\_level}
Determines the level of preprocessing that should be done on the current MILP
instance. A level of less than $0$ means that no preprocessing will be done.
At level $2$ basic presolve routines are used. At higher levels more advanced
routines are deployed. At level $5$, valid implications are derived.

\item[\ptt{prep\_dive\_level} -- integer({\tt 5}).]
\sindex[p]{\MP!prep\_dive\_level}
When a variable has been modified by preprocessing, then these changes can be
used to improve other variables and constraints in the instance as well. This
parameter controls how many times can we recursively try to improve the
instance if a change is made.

\item[\ptt{prep\_impl\_dive\_level} -- integer({\tt 0}).]
\sindex[p]{\MP!prep\_impl\_dive\_level}
In some advanced preprocessing routines, a variable or constraint is modified
to check what implications can be derived from that change. When such an
implication is derived, it can recursively lead to more implications. This
parameter controls how many levels of recursion are allowed.

\item[\ptt{prep\_impl\_limit} -- integer({\tt 50}).]
\sindex[p]{\MP!prep\_impl\_limit}
Determines the maximum number of implications that can be derived from
preprocessing.

\item[\ptt{prep\_do\_probing} -- integer({\tt 1}).]
\sindex[p]{\MP!prep\_do\_probing}
Determines if probing is used while preprocessing. Probing is not yet
implemented and this parameter does not have any effect.

\item[\ptt{prep\_verbosity} -- integer({\tt 1}).]
\sindex[p]{\MP!prep\_verbosity}
Determines the verbosity of messages from the preprocessing stage. Higher
levels will produce more verbose messages.

\item[\ptt{prep\_reduce\_mip} -- boolean ({\tt 1}).]
\sindex[p]{\MP!prep\_reduce\_mip}
If some variables and constraints have been eliminated in preprocessing and if 
\ptt{prep\_reduce\_mip} is $1$, then the memory allocated for these deleted
variables and constraints is freed. Otherwise, these are retained in the
instance but are never used.

\item[\ptt{prep\_probing\_verbosity} -- integer({\tt 0}).]
\sindex[p]{\MP!prep\_probing\_verbosity}
Determines the verbosity of messages from probing stage. Probing is not yet
implemented and this parameter does not have any effect.

\item[\ptt{prep\_probing\_level} -- integer({\tt 1}).]
\sindex[p]{\MP!prep\_probing\_level}
Determines the maximum level of probing that is carried out before
preprocessing is stopped. Probing is not yet
implemented and this parameter does not have any effect.

\item[\ptt{prep\_display\_stats} -- boolean ({\tt 0}).]
\sindex[p]{\MP!prep\_display\_stats}
Determines if statistics on how many of each type of changes were made in the
preprocessing stage are displayed ($1$) or not ($0$).

\item[\ptt{keep\_row\_ordered} -- integer({\tt 1}).]
\sindex[p]{\MP!keep\_row\_ordered}
When the value of this parameter is {\tt 1}, a row ordered matrix is also
retained for use after the preprocessing stage. This capability is not yet
implemented and this parameter does not have any effect.

\item[\ptt{prep\_do\_sr} -- boolean ({\tt 0}).]
\sindex[p]{\MP!prep\_do\_sr}
When the value of this parameter is {\tt 1}, additional preprocessing is
performed by solving an LP with one constraint. This procedure is not
thoroughly tested.

\item[\ptt{max\_sr\_cnt} -- integer({\tt 5}).]
\sindex[p]{\MP!max\_sr\_cnt}
This parameter controls the number of single-constraint LPs that are solved
for each constraint in the preprocessing stage. This procedure is not
thoroughly tested.

\item[\ptt{max\_aggr\_row\_cnt} -- integer({\tt 0}).]
\sindex[p]{\MP!max\_aggr\_row\_cnt}
This parameter is not used and has no effect.

\item[\ptt{prep\_iter\_limit} -- integer({\tt 10}).]
\sindex[p]{\MP!prep\_iter\_limit}
Determines the maximum number of times preprocessing can be done on an
instance. If an instance has been modified by preprocessing, then the new
problem can be preprocessed again to get an even better formulation. This
parameter puts a limit on the number of times such preprocessing can be done.

\item[\ptt{write\_mps} -- boolean ({\tt 0}).]
\sindex[p]{\MP!write\_mps}
Determines if an MPS file be written after all preprocessing has been
performed. This can be used for debugging or if the user wants to save the
preprocessed instance.

\item[\ptt{write\_lp} -- boolean ({\tt 0}).]
\sindex[p]{\MP!write\_lp}
Determines if an LP file be written after all preprocessing has been
performed. This can be used for debugging or if the user wants to save the
preprocessed instance.

\item[\ptt{prep\_time\_limit} -- integer({\tt 50}).]
\sindex[p]{\MP!prep\_time\_limit}
Determines the maximum time in seconds that can be spent in preprocessing.

   %double            etol; 
   %double            single_row_rlx_ratio;
   %char              do_aggregate_row_rlx; 
   %double            max_aggr_row_ratio;   
   %int               keep_track; 

\end{description}

\subsection{Draw Graph parameters}
\begin{description}

\item[\ptt{source\_path} -- string (``.'').] 
\sindex[p]{\DP!source\_path}
The directory where the DG tcl/tk scripts reside.

\item[\ptt{echo\_commands} -- boolean ({\tt FALSE}).]
\sindex[p]{\DP!echo\_commands}
Whether to echo the tcl/tk commands on the screen or not.

\item[\ptt{canvas\_width, canvas\_height} -- integers (1000, 700).]
\sindex[p]{\DP!canvas\_width}
\sindex[p]{\DP!canvas\_height}
The default width and height of the drawing canvas in pixels.

\item[\ptt{viewable\_width, viewable\_height} -- integers (600, 400).]
\sindex[p]{\DP!viewable\_width}
\sindex[p]{\DP!viewable\_height}
The default viewable width and height of the drawing canvas in pixels.

\item[\ptt{interactive\_mode} -- integer ({\tt TRUE}).] 
\sindex[p]{\DP!interactive\_mode}
Whether it is allowable to change things interactively on the canvas or not.

\item[\ptt{node\_radius} -- integer (8).] 
\sindex[p]{\DP!node\_radius}
The default radius of a displayed graph node.

\item[\ptt{disp\_nodelabels, disp\_nodeweights, disp\_edgeweights} -- integers
(all {\tt TRUE}).] 
\sindex[p]{\DP!disp\_nodelabels}
\sindex[p]{\DP!disp\_nodeweights}
\sindex[p]{\DP!disp\_edgeweights}
Whether to display node labels, node weights, and edge weights or not.

\item[\ptt{nodelabel\_font, nodeweight\_font, edgeweight\_font} -- strings
(all ``-adobe-helvetica-...'').] 
\sindex[p]{\DP!nodelabel\_font}
\sindex[p]{\DP!nodeweight\_font}
\sindex[p]{\DP!edgeweight\_font}
The default character font for displaying node labels, node weights and edge
weights. 

\item[\ptt{node\_dash, edge\_dash} -- strings (both empty string).] 
\sindex[p]{\DP!node\_dash}
\sindex[p]{\DP!edge\_dash}
The dash pattern of the circles drawn around dashed nodes and that of
dashed edges.

\end{description}

\subsection{Tree Manager parameters}
\label{tm_params}
\begin{description}

\item[\ptt{TM\_verbosity} -- integer (0).] 
\sindex[p]{\TP!TM\_verbosity}
The verbosity of the TM module.

\item[\ptt{lp\_exe, cg\_exe, cp\_exe} -- strings (``lp'', ``cg'',
``cp'').] 
\sindex[p]{\TP!lp\_exe}
\sindex[p]{\TP!cg\_exe}
\sindex[p]{\TP!cp\_exe}
The name of the LP, CG, and CP module binaries. Note: when running in
parallel using PVM, these executables (or links to them) must reside
in the \ptt{PVM\_ROOT/bin/PVM\_ARCH/} directory. Also, be sure to note
that the executable names may have extensions that depend on the
configuration of the modules, but the defaults will always be set to
the name that the makefile produces.

\item[\ptt{lp\_debug, cg\_debug, cp\_debug} -- boolean (all {\tt
FALSE}).] 
\sindex[p]{\TP!lp\_debug}
\sindex[p]{\TP!cg\_debug}
\sindex[p]{\TP!cp\_debug}
Whether the modules should be started under a debugger or not.

\item[\ptt{max\_active\_nodes} -- integer (1).] 
\sindex[p]{\TP!max\_active\_nodes}
The maximum number of active search tree nodes---equal to the number of
LP and CG tandems to be started up.

\item[\ptt{max\_cp\_num} -- integer (0).] 
\sindex[p]{\TP!max\_cp\_num}
The maximum number of cut pools to be used.

\item[\ptt{lp\_mach\_num, cg\_mach\_num, cp\_mach\_num} -- integers
(all 0).] 
\sindex[p]{\TP!lp\_mach\_num}
\sindex[p]{\TP!cg\_mach\_num}
\sindex[p]{\TP!cp\_mach\_num}
The number of processors in the virtual machine to run LP (CG, CP)
processes. If this value is 0 then the processes will be assigned to
processors in round-robin order. Otherwise the next \ptt{xx\_mach\_num} lines
describe the processors where the LP (CG, CP) modules must run. The
keyword -- value pairs on these lines must be {\bf TM\_xx\_machine} and the
name or IP address of a processor (the processor names need not be distinct).
In this case the actual processes are assigned in a round robin fashion to the
processors on this list.\\
\\
This feature is useful if a specific software package is needed for
some module, but that software is not licensed for every node of the
virtual machine or if a certain process must run on a certain type of
machine due to resource requirements.

\item[\ptt{use\_cg} -- boolean ({\tt FALSE}).]
\sindex[p]{\TP!use\_cg}
Whether to use a cut generator or not. 

\item[\ptt{TM\_random\_seed} -- integer (17).] 
\sindex[p]{\TP!TM\_random\_seed}
The random seed used in the TM.

\item[\ptt{unconditional\_dive\_frac} -- double (0.0).] 
\sindex[p]{\TP!unconditional\_dive\_frac}
The fraction of the nodes on which \BB\ randomly dives
unconditionally into one of the children.

\label{diving_strategy}
\item[\ptt{diving\_strategy} -- integer ({\tt BEST\_ESTIMATE}\{0\}).] 
\sindex[p]{\TP!diving\_strategy}
The strategy employed when deciding whether to dive or not. \\
\\
The {\tt BEST\_ESTIMATE}\{0\} strategy continues to dive until the
lower bound in the child to be dived into exceeds the parameter
\htmlref{\texttt{upper\_bound\_estimate}}{upper_bound_estimate}, which is 
given by the user. \\
\\
The {\tt COMP\_BEST\_K}\{1\} strategy computes the average lower bound
on the best \htmlref{\texttt{diving\_k}}{diving} search tree nodes and
decides to dive if
the lower bound of the child to be dived into does not exceed this
average by more than the fraction \htmlref{\texttt{diving\_threshold}}{diving}.
\\
\\
The {\tt COMP\_BEST\_K\_GAP}\{2\} strategy takes the size of the gap
into account when deciding whether to dive. After the average lower
bound of the best \htmlref{\texttt{diving\_k}}{diving} nodes is computed, 
the gap between
this average lower bound and the current upper bound is computed.
Diving only occurs if the difference between the computed average
lower bound and the lower bound of the child to be dived into is at
most the fraction \htmlref{\texttt{diving\_threshold}}{diving} of the gap.\\
\\
Note that fractional diving settings can override these strategies.
See \htmlref{below}{fractional_diving}.

\label{diving}
\item[\ptt{diving\_k, diving\_threshold} -- integer, double (1, 0.05).] 
\sindex[p]{\TP!diving\_k}
\sindex[p]{\TP!diving\_threshold}
See above.

\label{fractional_diving}
\item[\ptt{fractional\_diving\_ratio, fractional\_diving\_num} --
integer (0.02, 0).]
\sindex[p]{\TP!fractional\_diving\_ratio}
\sindex[p]{\TP!fractional\_diving\_num}

Diving occurs automatically if the number of fractional variables in
the child to be dived into is less than \ptt{fractional\_diving\_num}
or the fraction of total variables that are fractional is less than {\tt
fractional\_diving\_ratio}. This overrides the other diving rules.
Note that in order for this option to work, the code must be compiled
with {\tt FRACTIONAL\_BRANCHING} defined. This is the default. See the
makefile for more details.

\item[\ptt{node\_selection\_rule} -- integer ({\tt LOWEST\_LP\_FIRST}\{0\}).] 
\sindex[p]{\TP!node\_selection\_rule}
The rule for selecting the next search tree node to be processed. This rule
selects the one with lowest lower bound. Other possible values are: {\tt
HIGHEST\_LP\_FIRST}\{1\}, {\tt BREADTH\_FIRST\_SEARCH}\{2\} and {\tt
DEPTH\_FIRST\_SEARCH}\{3\}.

\item[\ptt{load\_balance\_level}] -- integer (-1).] 
\sindex[p]{\TP!load\_balance\_level}
A naive attempt at load balancing on problems where significant time
is spent in the root node, contributing to a lack of parallel
speed-up. Only a prescribed number of iterations ({\tt
load\_balance\_iter}) are performed in the root node (and in each
subsequent node on
a level less than or equal to \ptt{load\_balance\_level}) before
branching is forced in order to provide additional subproblems for the
idle processors to work on. This doesn't work well in general.

\item[\ptt{load\_balance\_iter}] -- integer (-1).] 
\sindex[p]{\TP!load\_balance\_iter}
Works in tandem with the \ptt{load\_balance\_level} to attempt some
simple load balancing. See the above description.

\item[\ptt{keep\_description\_of\_pruned} -- integer ({\tt DISCARD}\{0\}).] 
\sindex[p]{\TP!keep\_description\_of\_pruned}
Whether to keep the description of pruned search tree nodes or not.
The reasons to do this are (1) if the user wants to write out a proof
of optimality using the logging function, (2) for debugging, or (3) to
get a visual picture of the tree using the software VBCTOOL.
Otherwise, keeping the pruned nodes around just takes up memory. 

There are three options if it is desired to keep some description of
the pruned nodes around. First, their full description can be written
out to disk and freed from memory ({\tt KEEP\_ON\_DISK\_FULL}\{1\}). There
is not really too much you can do with this kind of file, but
theoretically, it contains a full record of the solution process and
could be used to provide a certificate of optimality (if we were using
exact arithmetic) using an independent verifier. In this case, the
line following \ptt{keep\_description\_of\_pruned} should be a line
containing the keyword \ptt{pruned\_node\_file\_name} with its
corresponding value being the name of a file to which a description of
the pruned nodes can be written. The file does not need to exist and
will be over-written if it does exist.

If you have the software VBCTOOL, then
you can alternatively just write out the information VBCTOOL needs to
display the tree ({\tt KEEP\_ON\_DISK\_VBC\_TOOL}\{2\}). 

Finally, the user can set the value to of this parameter to {\tt
KEEP\_IN\_MEMORY}\{2\}, in which case all pruned nodes will be kept in
memory and written out to the regular log file if that option is
chosen. This is really only useful for debugging. Otherwise, pruned
nodes should be flushed.

\item[\ptt{keep\_warm\_start} -- boolean ({\tt FALSE}).]
\sindex[p]{\TP!keep\_warm\_start}
Turning this parameter on will have exactly the same impact with 
setting the \ptt{keep\_description\_of\_pruned} to 
{\tt KEEP\_IN\_MEMORY}\{2\}. This will allow SYMPHONY to keep all the
necessary information obtained from the branching tree of the original 
problem to be able to warm start after a parameter or problem data 
modification. Thus, if it is intended to warm start later, the user 
should set this parameter before solving the original problem.

\item[\ptt{warm\_start\_node\_limit} -- integer ({\tt SYM\_INFINITY}).]
\sindex[p]{\TP!warm\_start\_node\_limit}
Setting this parameter will start the warm start routine using only the 
first \ptt{warm\_start\_node\_limit} nodes generated during the 
previous solve procedure. The rest of the tree will be trimmed. 

\item[\ptt{warm\_start\_node\_ratio} -- double ({\tt 0.0}).]
\sindex[p]{\TP!warm\_start\_node\_ratio}
Setting this parameter will start the warm start routine using only the 
first \ptt{warm\_start\_node\_ratio}\% of the nodes generated during the 
previous solve procedure. 

\item[\ptt{warm\_start\_node\_level} -- integer ({\tt SYM\_INFINITY}).]
\sindex[p]{\TP!warm\_start\_node\_level}
Setting this parameter will start the warm start routine using all the
nodes above the level \ptt{warm\_start\_node\_level} of the 
tree generated during the previous solve procedure. The rest of the tree 
will be trimmed. 

\item[\ptt{warm\_start\_node\_level\_ratio} -- double ({\tt 0.0}).]
\sindex[p]{\TP!warm\_start\_node\_level\_ratio}
Setting this parameter will start the warm start routine using all the
nodes above the level \ptt{warm\_start\_node\_level}\% of the 
warm start tree depth. The rest of the tree will be trimmed

\item[\ptt{logging} -- integer ({\tt NO\_LOGGING}\{0\}).] 
\sindex[p]{\TP!logging}
Whether or not to write out the state of the search tree and all other
necessary data to disk periodically in order to allow a warm start in
the case of a system crash or to allow periodic viewing with VBCTOOL.

If the value of this parameter is set to {\tt FULL\_LOGGING}\{1\},
then all information needed to warm start the calculation will written
out periodically. The next two lines of the parameter file following
should contain the keywords \ptt{tree\_log\_file\_name} and {\tt
cut\_log\_file\_name} along with corresponding file names as values.
These will be the files used to record the search tree and related
data and the list of cuts needed to reconstruct the tree.

If the value of the parameter is set to {\tt VBC\_TOOL}\{2\}, then
only the information VBCTOOL needs to display the tree will be
logged. This is not really a very useful option since a ``live'' picture
of the tree can be obtained using the \ptt{vbc\_emulation} parameter
described below.

\item[\ptt{logging\_interval} -- integer (1800).] 
\sindex[p]{\TP!logging\_interval}
Interval (in seconds) between writing out the above log files.

\item[\ptt{warm\_start} -- boolean (0).] 
\sindex[p]{\TP!warm\_start}
Used to allow the tree manager to make a warm start by reading in
previously written log files. If this option is set, then the two line
following must start with the keywords {\tt
warm\_start\_tree\_file\_name} and \ptt{warm\_start\_cut\_file\_name}
and include the appropriate file names as the corresponding values.

\item[\ptt{vbc\_emulation}] -- integer ({\tt
NO\_VBC\_EMULATION}\{0\}).] 
\sindex[p]{\TP!vbc\_emulation}
Determines whether or not to employ the VBCTOOL emulation mode. If
one of these modes is chosen, then the tree will be displayed in
``real time'' using the VBCTOOL Software. When using the option {\tt
VBC\_EMULATION\_LIVE}\{2\} and piping the output directly to VBCTOOL, the
tree will be displayed as it is constructed, with color coding
indicating the status of each node. With {\tt
VBC\_EMULATION\_FILE}\{1\} selected, a log file will be produced which
can later be read into VBCTOOL to produce an emulation of the
solution process at any desired speed. If {\tt VBC\_EMULATION\_FILE}
is selected, the the following line should contain the keyword {\tt
vbc\_emulation\_file\_name} along with the corresponding file name
for a value.

\item[\ptt{price\_in\_root} -- boolean ({\tt FALSE}).] 
\sindex[p]{\TP!price\_in\_root}
Whether to price out variables in the root node before the second
phase starts (called {\em repricing the root}). 

\item[\ptt{trim\_search\_tree} -- boolean ({\tt FALSE}).] 
\sindex[p]{\TP!trim\_search\_tree}
Whether to trim the search tree before the second phase starts or not. Useful
only if there are two phases. (It is very useful then.)

\item[\ptt{colgen\_in\_first\_phase, colgen\_in\_second\_phase} --
integers (both 4).] 
\sindex[p]{\TP!colgen\_in\_first\_phase} 
\sindex[p]{\TP!colgen\_in\_second\_phase} 
These parameters determine if and when to do
column generation in the first and second phase of the algorithm. The
value of each parameter is obtained by setting the last four bits.
The last two bits refer to what to do when attempting to prune a node.
If neither of the last two bits are set, then we don't do
anything---we just prune it. If only the last bit is set, then we
simply save the node for the second phase without doing any column
generation (yet). If only the second to last bit is set, then we do
column generation immediately and resolve if any new columns are
found. The next two higher bits determine whether or not to do column
generation before branching. If only the third lowest bit is set, then no
column generation occurs before branching. If only the fourth lowest bit is
set, then column generation is attempted before branching. The default
is not to generate columns before branching or fathoming, which
corresponds to only the third lowest bit being set, resulting in a
default value of 4.

\item[\ptt{time\_limit} -- double (-1.0).] 
\sindex[p]{\TP!time\_limit}
Number of seconds of wall-clock time allowed for solution. When this
time limit is reached, the solution process will stop and the best
solution found to that point, along with other relevant data, will be
output. A time limit less than 0.0 means there is no limit.

\item[\ptt{node\_limit} -- integer (-1).] 
\sindex[p]{\TP!node\_limit}
Number of nodes allowed to be analyzed during the solution. When this
node limit is reached, the solution process will stop and the best
solution found to that point, along with other relevant data, will be
output. A node limit less than 0 means there is no limit. 

\item[\ptt{gap\_limit} -- double (-1.0).] 
\sindex[p]{\TP!gap\_limit}
Target gap limit allowed for solution. When the gap between the lower and 
the upper bound reaches this point, the solution process will stop and the 
best solution found to that point, along with other relevant data, will be
output. A gap limit less than 0 means there is no limit.

\item[\ptt{find\_first\_feasible} -- boolean (FALSE).]
\sindex[p]{\TP!find\_first\_feasible}
Whether to stop after finding the first feasible solution or not. 

\item[\ptt{sensitivity\_analysis} -- boolean (FALSE).] 
\sindex[p]{\TP!sensitivity\_analysis}
If the user wants to do the rudimentary sensitivity analysis, which will 
give a lower bound for the problem modified by the right hand side, then, 
this parameter has to be set before solving the original problem. If it 
is set, SYMPHONY will keep the necessary information from the solution 
processes of the original problem to be able to do the sensitivity analysis 
later.  

\end{description}

\subsection{LP parameters}

\begin{description}

\item[\ptt{LP\_verbosity} -- integer (0).]
\sindex[p]{\LPP!LP\_verbosity}
Verbosity level of the LP module.

\item[\ptt{set\_obj\_upper\_lim} -- boolean ({\tt FALSE}).] 
\sindex[p]{\LPP!set\_obj\_upper\_lim}
Whether to stop solving the LP relaxation when it's optimal value is
provably higher than the global upper bound. There are some advantages
to continuing the solution process anyway. For instance, this results
in the highest possible lower bound. On the other hand, if the matrix
is full, this node will be pruned anyway and the rest of the
computation is pointless. This option should be set at {\tt FALSE} for
column generation since the LP dual values may not be reliable otherwise.

\item[\ptt{try\_to\_recover\_from\_error} -- boolean ({\tt TRUE}).]
\sindex[p]{\LPP!try\_to\_recover\_from\_error}
Indicates what should be done in case the LP solver is unable to solve
a particular LP relaxation because of numerical problems. It is
possible to recover from this situation but further results may be
suspect. On the other hand, the entire solution process can be
abandoned.

\item[\ptt{problem\_type} -- integer ({\tt ZERO\_ONE\_PROBLEM}\{0\}).] 
\sindex[p]{\LPP!problem\_type}
The type of problem being solved. Other values are {\tt
INTEGER\_PROBLEM}\{1\} or {\tt MIXED\_INTEGER\_PROBLEM}\{2\}.
(Caution: The mixed-integer option is not well tested.)

\item[\ptt{cut\_pool\_check\_frequency} -- integer (10).] 
\sindex[p]{\LPP!cut\_pool\_check\_frequency}
The number of iterations between sending LP solutions to the cut pool
to find violated cuts. It is not advisable to check the cut pool too
frequently as the cut pool module can get bogged down and the LP
solution generally do not change that drastically from one iteration
to the next anyway.

\item[\ptt{not\_fixed\_storage\_size} -- integer (2048).]
\sindex[p]{\LPP!not\_fixed\_storage\_size}
The {\em not fixed list} is a partial list of indices of variables not
in the matrix that have not been fixed by reduced cost. Keeping this
list allows \BB\ to avoid repricing variables (an expensive operation)
that are not in the matrix because they have already been permanently
fixed. When this array reaches its maximum size, no more variable
indices can be stored. It is therefore advisable to keep the maximum
size of this array as large as possible, given memory limitations.

\item[\ptt{max\_non\_dual\_feas\_to\_add\_min},]
\item[\ptt{max\_non\_dual\_feas\_to\_add\_max},]
\item[\ptt{max\_non\_dual\_feas\_to\_add\_frac} 
-- integer, integer, double (20, 200, .05).] 
\sindex[p]{\LPP!max\_non\_dual\_feas\_to\_add\_min}
\sindex[p]{\LPP!max\_non\_dual\_feas\_to\_add\_frac}
These three parameters determine the maximum number of
non-dual-feasible columns that can be added in any one iteration
after pricing. This maximum is set to the indicated
fraction of the current number of active columns unless this numbers
exceeds the given maximum or is less than the given minimum, in which
case, it is set to the max or min, respectively.

\item[\ptt{max\_not\_fixable\_to\_add\_min},]
\item[\ptt{max\_not\_fixable\_to\_add\_max},]
\item[\ptt{max\_not\_fixable\_to\_add\_frac} -- integer, integer, double (100,
500, .1) ] 
\sindex[p]{\LPP!max\_not\_fixable\_to\_add\_max}
\sindex[p]{\LPP!max\_not\_fixable\_to\_add\_frac}
As above, these three parameters determine the maximum number of new
columns to be added to the problem because they cannot be priced out.
These variables are only added when trying to restore infeasibility
and usually, this does not require many variables anyway.

\item[\ptt{mat\_col\_compress\_num, mat\_col\_compress\_ratio} -- integer,
double (50, .05).] 
\sindex[p]{\LPP!mat\_col\_compress\_num}
\sindex[p]{\LPP!mat\_col\_compress\_ratio}
Determines when the matrix should be physically compressed. This only
happens when the number of columns is high enough to make it
``worthwhile.'' The matrix is physically compressed when the number of
deleted columns exceeds either an absolute number {\em and} a specified
fraction of the current number of active columns.

\item[\ptt{mat\_row\_compress\_num, mat\_row\_compress\_ratio} -- integer,
double (20, .05).] 
\sindex[p]{\LPP!mat\_row\_compress\_num}
\sindex[p]{\LPP!mat\_row\_compress\_ratio}
Same as above except for rows.

\item[\ptt{tailoff\_gap\_backsteps, tailoff\_gap\_frac} -- integer, double
(2, .99).] 
\sindex[p]{\LPP!tailoff\_gap\_backsteps}
\sindex[p]{\LPP!tailoff\_gap\_frac}
Determines when tailoff is detected in the LP module.
Tailoff is reported if the average ratio of the current gap to the
previous iteration's gap over the last \ptt{tailoff\_gap\_backsteps}
iterations wasn't at least \ptt{tailoff\_gap\_frac}.

\item[\ptt{tailoff\_obj\_backsteps, tailoff\_obj\_frac} -- integer, double
(2, .99).] 
\sindex[p]{\LPP!tailoff\_obj\_backsteps}
\sindex[p]{\LPP!tailoff\_obj\_frac}
Same as above, only the ratio is taken with respect to the change in
objective function values instead of the change in the gap.

\item[\ptt{ineff\_cnt\_to\_delete} -- integer (0).]
\sindex[p]{\LPP!ineff\_cnt\_to\_delete}
Determines after how many iterations of being deemed ineffective a
constraint is removed from the current relaxation.

\item[\ptt{eff\_cnt\_before\_cutpool} -- integer (3).] 
\sindex[p]{\LPP!eff\_cnt\_before\_cutpool}
Determines after how many iterations of being deemed effective each
cut will be sent to the global pool.

\item[\ptt{ineffective\_constraints} -- integer
({\tt BASIC\_SLACKS\_ARE\_INEFFECTIVE}\{2\}).]
\sindex[p]{\LPP!ineffective\_constraints}
Determines under what condition a constraint is deemed ineffective in
the current relaxation. Other possible values are {\tt
NO\_CONSTRAINT\_IS\_INEFFECTIVE}\{0\},  {\tt
NONZERO\_SLACKS\_ARE\_INEFFECTIVE}\{1\}, and \\
{\tt ZERO\_DUAL\_VALUES\_ARE\_INEFFECTIVE}\{3\}.

\item[\ptt{base\_constraints\_always\_effective} -- boolean ({\tt TRUE}).]
\sindex[p]{\LPP!base\_constraints\_always\_effective}
Determines whether the base constraints can ever be removed from the
relaxation. In some case, removing the base constraints from the
problem can be disastrous depending on the assumptions made by the cut
generator.

\item[\ptt{branch\_on\_cuts} -- boolean ({\tt FALSE}).]
\sindex[p]{\LPP!branch\_on\_cuts}
This informs the framework whether the user plans on branching on cuts
or not. If so, there is additional bookkeeping to be done, such as
maintaining a pool of slack cuts to be used for branching. Therefore,
the user should not set this flag unless he actually plans on using
this feature.

\item[\ptt{discard\_slack\_cuts} -- integer ({\tt
DISCARD\_SLACKS\_BEFORE\_NEW\_ITERATION}\{0\}).]
\sindex[p]{\LPP!discard\_slack\_cuts}
Determines when the pool of slack cuts is discarded. The other option
is {\tt DISCARD\_SLACKS\_WHEN\_STARTING\_NEW\_NODE}\{1\}.


\item[\ptt{first\_lp\_first\_cut\_time\_out},]
\item[\ptt{first\_lp\_all\_cuts\_time\_out},]
\item[\ptt{later\_lp\_first\_cut\_time\_out},]
\item[\ptt{later\_lp\_all\_cuts\_time\_out} --
double (0, 0, 5, 1).]
\sindex[p]{\LPP!first\_lp\_first\_cut\_time\_out}
\sindex[p]{\LPP!first\_lp\_all\_cuts\_time\_out}
\sindex[p]{\LPP!later\_lp\_first\_cut\_time\_out}
\sindex[p]{\LPP!later\_lp\_all\_cuts\_time\_out}
The next group of parameters determines when the LP should give up
waiting for cuts from the cut generator and start to solve the
relaxation in its current form or possibly branch if necessary. There
are two factors that contribute to determining this timeout. First
is whether this is the first LP in the search node of whether it is a
later LP. Second is whether any cuts have been added already in this
iteration. The four timeout parameters correspond to the four possible
combinations of these two variables.

\item[\ptt{no\_cut\_timeout} -- ]
\sindex[p]{\LPP!no\_cut\_timeout}
This keyword does not have an associated value. If this keyword
appears on a line by itself or with a value, this tells the framework
not to time out while waiting for cuts. This is useful for debugging
since it enables runs with a single LP module to be duplicated.

\item[\ptt{all\_cut\_timeout} -- double (no default).]
\sindex[p]{\LPP!all\_cut\_timeout}
This keyword tells the framework to set all of the above timeout
parameters to the value indicated.

\item[\ptt{max\_cut\_num\_per\_iter} -- integer (20).]
\sindex[p]{\LPP!max\_cut\_num\_per\_iter}
The maximum number of cuts that can be added to the LP in an
iteration. The remaining cuts stay in the local pool to be added in
subsequent iterations, if they are strong enough.

\item[\ptt{do\_reduced\_cost\_fixing} -- boolean ({\tt FALSE}).]
\sindex[p]{\LPP!do\_reduced\_cost\_fixing}
Whether or not to attempt to fix variables by reduced cost. This
option is highly recommended

\item[\ptt{gap\_as\_ub\_frac, gap\_as\_last\_gap\_frac} -- double (.1, .7).]
\sindex[p]{\LPP!gap\_as\_ub\_frac}
\sindex[p]{\LPP!gap\_as\_last\_gap\_frac}
Determines when reduced cost fixing should be attempted. It is only
done when the gap is within the fraction \ptt{gap\_as\_ub\_frac} of the upper
bound or when the gap has decreased by the fraction 
\ptt{gap\_as\_last\_gap\_frac} since the last time variables were fixed.

\item[\ptt{do\_logical\_fixing} -- boolean ({\tt FALSE}).] 
\sindex[p]{\LPP!do\_logical\_fixing}
Determines whether the user's logical fixing routine should be used.

\item[\ptt{fixed\_to\_ub\_before\_logical\_fixing},]
\item[\ptt{fixed\_to\_ub\_frac\_before\_logical\_fixing} -- 
{\bf integer, double (1, .01)}.]
\sindex[p]{\LPP!fixed\_to\_ub\_before\_logical\_fixing}
\sindex[p]{\LPP!fixed\_to\_ub\_frac\_before\_logical\_fixing}
Determines when logical fixing should be attempted. It will be called
only when a certain absolute number {\em and} a certain number of variables
have been fixed to their upper bounds by reduced cost. This is because
it is typically only after fixing variables to their upper bound that
other variables can be logically fixed.

\label{strong_branching}
\item[\ptt{max\_presolve\_iter} -- integer (10).] 
\sindex[p]{\LPP!max\_presolve\_iter}
Number of simplex iterations to be performed in the pre-solve for
strong branching.

\item[\ptt{strong\_branching\_cand\_num\_max},]
\item[\ptt{strong\_branching\_cand\_num\_min},]
\item[\ptt{strong\_branching\_red\_ratio} --
{\bf integer (10, 5, 1)}.]
\sindex[p]{\LPP!strong\_branching\_cand\_num\_max}
\sindex[p]{\LPP!strong\_branching\_cand\_num\_min}
\sindex[p]{\LPP!strong\_branching\_red\_ratio}
These three parameters together determine the number of strong
branching candidates to be used by default. In the root node,
\ptt{strong\_branching\_cand\_num\_max} candidates are used. On each
succeeding level, this number is reduced by the number 
\ptt{strong\_branching\_red\_ratio} multiplied by the square of the level.
This continues until the number of candidates is reduced to 
\ptt{strong\_branching\_cand\_num\_min} and then that number of candidates
is used in all lower levels of the tree.

\item [\ptt{strong\_branching\_high\_low\_weight} -- double (0.8).]
\sindex[p]{strong\_branching\_high\_low\_weight}
This parameter is used to calculate the score of each branching candidate. The
candidate with the highest score is then selected for branching. Let $z_i^+,
z_i^-$ be the estimated change in objective function value when we branch on
the candidate $i$. Then the score of candidate $i$ is $s_i =
\alpha\times\min\{z_i^+, z_i^-\} + (1-\alpha)\times\max\{z_i^+,z_i^-\}$, where
$\alpha$ is the value of \ptt{strong\_branching\_high\_low\_weight}. This
value should always lie in the interval $[0,1]$.

\item [\ptt{use\_hot\_starts} -- boolean ({\tt TRUE}).]
Determines if the LP solver is asked to make special arrangements for doing
dual-simplex iterations when bounds on a variable are changed for strong
branching. Some LP solvers provide such options so that strong branching can
be performed much faster than the regular dual-simplex procedure.

\item[\ptt{should\_use\_rel\_br} -- boolean ({\tt TRUE}).] 
\sindex[p]{should\_use\_rel\_br}
Determines if reliability braching is used to determine branching candidates
or not. This parameter is set to {\tt FALSE} if OPENMP is used. When this
branching rule is disabled, strong branching is used to select a candidate.

%   lp_par->rel_br_override_max_solves = 200;
%   lp_par->rel_br_chain_backtrack = 5;
%   lp_par->rel_br_min_imp = 0.0133;
%   lp_par->rel_br_max_imp = 0.30;

\item[\ptt{rel\_br\_override\_default} -- boolean ({\tt TRUE}).]
\sindex[p]{\LPP!rel\_br\_override\_default}
If reliability branching is enabled and this paramter is set to {\tt TRUE} then the
policy of selecting branching candidates is automatically adjusted on the
basis of bounds on solution value and the time elapsed. If this parameter is
set to {\tt FALSE}, the policy is based on the values of the following three
parameters.

\item[\ptt{rel\_br\_threshold} -- integer (8).] 
\sindex[p]{\LPP!rel\_br\_threshold}
It is assumed that the score obtained by branching on a given variable these many
times is reliable for estimating the pseudocosts of this variable in the rest
of the branch-and-bound algorithm. In other words, if reliability branching is
enabled, strong branching is used on a variable at most
\ptt{rel\_br\_threshold} many times.

\item[\ptt{rel\_br\_max\_solves} -- integer (20).] 
\sindex[p]{\LPP!rel\_br\_max\_solves}
If reliability branching is enabled, this parameter determines the maximum
number of strong branching LPs that are solved in each node. If some branching
candidates have reliable estimates, the number of LPs can be less than
the value of this parameter.

\item[\ptt{rel\_br\_cand\_threshold} -- integer (10).] 
\sindex[p]{\LPP!rel\_br\_cand\_threshold}
If reliability branching is enabled, then strong branching is stopped if the
last \ptt{rel\_br\_cand\_threshold} LPs did not give a better improvement in
the lower bound.


\item[\ptt{is\_feasible\_default} -- integer ({\tt TEST\_INTEGRALITY}\{1\}).]
\sindex[p]{\LPP!is\_feasible\_default}
Determines the default test to be used to determine feasibility. This
parameter is provided so that the user can change the default behavior
without recompiling. The only other option is {\tt TEST\_ZERO\_ONE}\{0\}.

\item[\ptt{send\_feasible\_solution\_default} -- integer 
({\tt SEND\_NONZEROS}\{0\}).] 
\sindex[p]{\LPP!send\_feasible\_solution\_default}
Determines the form in which to send the feasible solution. This
parameter is provided so that the user can change the default behavior
without recompiling. This is currently the only option.

\item[\ptt{send\_lp\_solution\_default} -- integer ({\tt SEND\_NONZEROS}\{0\}).] \sindex[p]{\LPP!send\_lp\_solution\_default}
Determines the default form in which to send the LP solution to the
cut generator and cut pool. This
parameter is provided so that the user can change the default behavior
without recompiling. The other option is {\tt SEND\_FRACTIONS}\{1\}.

\item[\ptt{display\_solution\_default} -- integer ({\tt DISP\_NOTHING}\{0\}).] \sindex[p]{\LPP!display\_solution\_default}
Determines how to display the current LP solution if desired.
See the description of \htmlref{\texttt{user\_display\_solution()}}
{user_display_solution} for other
possible values. This parameter is provided so that
the user can change the default behavior without recompiling.

\item[\ptt{shall\_we\_branch\_default} -- integer 
({\tt USER\_\_BRANCH\_IF\_MUST}\{2\}).] 
\sindex[p]{\LPP!shall\_we\_branch\_default}
Determines the default branching behavior. Other values are {\tt
USER\_\_DO\_NOT\_BRANCH}\{0\} (not recommended as a default), {\tt
USER\_\_DO\_BRANCH}\{1\} (also not recommended as a default), and {\tt
USER\_\_BRANCH\_IF\_TAILOFF}\{3\}. This
parameter is provided so that the user can change the default behavior
without recompiling.

\item[\ptt{select\_candidates\_default} -- integer ({\tt
USER\_\_CLOSE\_TO\_HALF\_AND\_EXPENSIVE}\{10\}).] 
\sindex[p]{\LPP!select\_candidates\_default}
Determines the default rule for selecting strong branching candidates.
Other values are {\tt USER\_\_CLOSE\_TO\_HALF}\{10\} and 
{\tt USER\_\_CLOSE\_TO\_ONE\_AND\_CHEAP}\{12\}. This
parameter is provided so that the user can change the default behavior
without recompiling.

\item[\ptt{compare\_candidates\_default} -- integer 
({\tt HIGHEST\_LOW\_OBJ}\{2\}).] 
\sindex[p]{\LPP!compare\_candidates\_default}
Determines the default rule for comparing candidates. See the
description of \htmlref{\texttt{user\_compare\_candidates()}}
{user_compare_candidates} for other values. This
parameter is provided so that the user can change the default behavior
without recompiling.

\item[\ptt{select\_child\_default} -- integer 
({\tt PREFER\_LOWER\_OBJ\_VALUE}\{0\}).] 
\sindex[p]{\LPP!select\_child\_default}
Determines the default rule for selecting the child to be processed
next. For other possible values, see the description \htmlref{
\texttt{user\_select\_child()}}{user_select_child}. This
parameter is provided so that the user can change the default behavior
without recompiling.

\item[\ptt{mc\_find\_supported\_solutions} -- boolean ({\tt FALSE}).] 
\sindex[p]{\LPP!mc\_find\_supported\_solutions}
By default, {\tt sym\_mc\_solve} routine will find all the non-dominated 
solutions if the problem to be solved is 
a bicriteria problem. However, if the user plans to find only the supported 
solutions, then, this parameter has to be set before 
calling {\tt sym\_mc\_solve} routine. 

\item[\ptt{mc\_rho} -- double ({\tt 0.00001}).] 
\sindex[p]{\LPP!mc\_rho}
The value used in augmented Chebyshev norm during the bicriteria 
solution procedure.

\item[\ptt{generate\_cgl\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_cuts}
Whether or not to generate cuts using COIN's cut generation library. 
Note that, to use CGL cuts, OSI interface has to be used and moreover the 
corresponding flags have to be set during installation. See the makefile for 
more details.

\item[\ptt{generate\_cgl\_gomory\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_gomory\_cuts}
Whether or not to generate Gomory cuts using COIN's cut generation library. 

\item[\ptt{generate\_cgl\_knapsack\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_knapsack\_cuts}
Whether or not to generate knapsack cover cuts using COIN's cut generation 
library. 

\item[\ptt{generate\_cgl\_oddhole\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_oddhole\_cuts}
Whether or not to generate generalized odd hole cuts using COIN's cut 
generation library. 

\item[\ptt{generate\_cgl\_probing\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_probing\_cuts}
Whether or not to generate probing cuts using COIN's cut generation library. 

\item[\ptt{generate\_cgl\_clique\_cuts} -- boolean ({\tt TRUE}).] 
\sindex[p]{\LPP!generate\_cgl\_clique\_cuts}
Whether or not to generate clique cuts using COIN's cut generation library. 

\item[\ptt{generate\_cgl\_flow\_and\_cover\_cuts} -- boolean ({\tt FALSE}).] 
\sindex[p]{\LPP!generate\_cgl\_flow\_and\_cover\_cuts}
Whether or not to generate flow and cover cuts using COIN's cut generation 
library. 

\item[\ptt{generate\_cgl\_rounding\_cuts} -- boolean ({\tt FALSE}).] 
\sindex[p]{\LPP!generate\_cgl\_rounding\_cuts}
Whether or not to generate simple rounding cuts using COIN's cut generation 
library. 

\item[\ptt{generate\_cgl\_lift\_and\_project\_cuts} -- boolean ({\tt FALSE}).] \sindex[p]{\LPP!generate\_cgl\_lift\_and\_project\_cuts}
Whether or not to generate lift-and-project cuts using COIN's cut generation 
library. 

\label{fp_enabled}
\item[\ptt{fp\_enabled} -- integer ({\tt SYM\_FEAS\_PUMP\_DEFAULT}\{1\}).] 
\sindex[p]{\LP!fp\_enabled}
Determines the overall policy of using the feasibility pump heuristic to find
feasible solutions. {\tt SYM\_FEAS\_PUMP\_DEFAULT}\{1\} indicates that the
decision to use the heuristic is determined on the basis of current values of
lower bound, upper bound, the time used etc., based on some preset rules. {\tt
SYM\_FEAS\_PUMP\_REPEATED}\{2\} indicates that the heuristic will be used
every few iterations until the problem is solved. The frequency can be
adjusted through the \ptt{fp\_frequency} parameter.  {\tt
SYM\_FEAS\_PUMP\_TILL\_SOL}\{3\} indicates that the heuristic is used only
until the first feasible solution is found. {\tt
SYM\_FEAS\_PUMP\_DISABLE}\{-1\} indicates that the heuristic is not used.

\item[\ptt{fp\_frequency} -- integer (10).] 
\sindex[p]{\LP!fp\_frequency}
Determines the number of LPs that are solved before which the feasibility pump
heuristic is called again. This parameter is used only if the parameter
\ptt{fp\_enabled} is set to {\tt SYM\_FEAS\_PUMP\_REPEATED}\{2\}. Otherwise,
the frequency is determined automatically based on some preset rules. 

\item[\ptt{fp\_max\_cycles} -- integer (100).] 
\sindex[p]{\LP!fp\_max\_cycles}
Determines the maximum number of LPs that can be solved in a call to the
feasibility pump heuristic. A higher number might be helpful in finding a
better feasible solution but may result in more time spent in the heuristic.

\item[\ptt{fp\_time\_limit} -- double (50).] 
\sindex[p]{\LP!fp\_time\_limit}
If a feasible solution has been found, this parameter determines the time in
seconds that can be spent on the feasibility pump heuristic. If a solution has
not been found yet, the parameter \ptt{fp\_max\_initial\_time} is used.

\item[\ptt{fp\_max\_initial\_time} -- double (100).] 
\sindex[p]{\LP!fp\_max\_initial\_time}
If a feasible solution has not been found, this parameter determines the time in
seconds that can be spent on the feasibility pump heuristic. If a solution has
been found, the parameter \ptt{fp\_time\_limit} is used.

\item[\ptt{fp\_min\_gap} -- double (0.5).] 
\sindex[p]{\LP!fp\_min\_gap}
If the relative (\%) gap between the lower and the upper bounds falls below the
value of this parameter, feasibility pump is not called.

\item[\ptt{fp\_flip\_fraction} -- double (0.1).] 
\sindex[p]{\LP!fp\_flip\_fraction}
When the feasibility pump gets stuck in a cycle, this fraction of binary
variables are flipped. The variables are selected randomly. Increasing the
value of this parameter may result in the pump getting stuck fewer number of
times, but the time to solve LPs after flipping may increase substantially.

\item[\ptt{fp\_poor\_sol\_lim\_fac} -- integer (10).] 
\sindex[p]{\LP!fp\_poor\_sol\_lim\_fac}
Sometimes the feasibility pump keeps generating solutions that have high
objective function values. When the number of such solutions becomes more than
\ptt{fp\_poor\_sol\_lim\_fac} times the number of ``good'' solutions, the pump
is disabled.

\end{description}
\subsection{Cut Generator Parameters}

\begin{description}

\item[\ptt{CG\_verbosity} -- integer (0).] 
\sindex[p]{\CGP!CG\_verbosity}
Verbosity level for the cut generator module.

\end{description}

\subsection{Cut Pool Parameters}
\label{cut_pool_params}
\begin{description}

\item[\ptt{CP\_verbosity} -- integer (0).] 
\sindex[p]{\CP!CP\_verbosity}
Verbosity of the cut pool module.

\item[\ptt{cp\_logging} -- boolean (0).] 
\sindex[p]{\CP!cp\_logging}
Determines whether the logging option is enabled. In this case, the
entire contents of the cut pool are written out periodically to disk
(at the same interval as the tree manager log files are written). If
this option is set, then the line following must start with the
keyword \ptt{cp\_log\_file\_name} and include the appropriate
file name as the value.

\item[\ptt{cp\_warm\_start} -- boolean (0).] 
\sindex[p]{\CP!cp\_warm\_start}
Used to allow the cut pool to make a warm start by reading in a
previously written log file. If
this option is set, then the line following must start with the
keyword \ptt{cp\_warm\_start\_file\_name} and include the appropriate
file name as the value.

\item[\ptt{block\_size} -- integer (5000).] 
\sindex[p]{\CP!block\_size}
Indicates the size of the blocks to allocate when more space is needed
in the cut list.

\item[\ptt{max\_size} -- integer (2000000).] 
\sindex[p]{\CP!max\_size}
Indicates the maximum size of the cut pool in bytes. This is the total
memory taken up by the cut list, including all data structures and the
array of pointers itself.

\item[\ptt{max\_number\_of\_cuts} -- integer (10000).] 
\sindex[p]{\CP!max\_number\_of\_cuts}
Indicates the maximum number of cuts allowed to be stored. When this
max is reached, cuts are forcibly purged, starting with duplicates
and then those indicated by the parameter \htmlref{\texttt{delete\_which}}
{delete_which} (see below), until the list is below the allowable size.

\item[\ptt{min\_to\_delete} -- integer (1000).]
\sindex[p]{\CP!min\_to\_delete}
Indicates the number of cuts required to be deleted when the pool reaches
it's maximum size.

\item[\ptt{touches\_until\_deletion} -- integer (10).] 
\sindex[p]{\CP!touches\_until\_deletion}
When using the number of touches a cut has as a measure of its
quality, this parameter indicates the number of touches a cut can have
before being deleted from the pool. The number of touches is the
number of times in a row that a cut has been checked without being
found to be violated. It is a measure of a cut's relevance or
effectiveness.

\label{delete_which}
\item[\ptt{delete\_which} -- integer 
({\tt DELETE\_BY\_TOUCHES}\{2\}).]
\sindex[p]{\CP!delete\_which}
Indicates which cuts to delete when
purging the pool. {\tt DELETE\_BY\_TOUCHES} indicates that cuts whose
number of touches is above the threshold (see {\tt
touches\_until\_deletion} above) should be purged if the pool gets too
large. {\tt DELETE\_BY\_QUALITY}\{1\} indicates that a user-defined
measure of quality should be used (see the function \hyperref{\tt
user\_check\_cuts()} {{\tt user\_check\_cuts} in Section}{} 
{user_check_cuts}).

\item[\ptt{check\_which} -- integer ({\tt CHECK\_ALL\_CUTS}\{0\}).] 
\sindex[p]{\CP!check\_which}
Indicates which cuts should be checked for violation. The choices are
to check all cuts ({\tt CHECK\_ALL\_CUTS}\{0\}); only those that have
number of touches below the threshold ({\tt CHECK\_TOUCHES}\{2\}); only
those that were generated at a level higher in the tree than the
current one ({\tt CHECK\_LEVEL}\{1\}); or both ({\tt
CHECK\_LEVEL\_AND\_TOUCHES}\{3\}). Note that with {\tt
CHECK\_ALL\_CUTS} set, SYMPHONY will still only check the first
\htmlref{\texttt{cuts\_to\_check}}{cuts_to_check} cuts in the list ordered
by quality (see the function \htmlref{\texttt{user\_check\_cut}}
{user_check_cuts}).

\label{cuts_to_check}
\item[\ptt{cuts\_to\_check} -- integer (1000).]
\sindex[p]{\CP!cuts\_to\_check}
Indicates how many cuts in the pool to actually check. The list is
ordered by quality and the first \ptt{cuts\_to\_check} cuts are
checked for violation.

\end{description}

\subsection{C++ Interface/OSI Parameters}
\label{OSI Parameters}

As the implementation of the whole interface, there exists a matching 
C interface parameter to each of the C++ Interface/OSI parameter and 
the parameter setting functions are designed to set the 
corresponding C interface parameter. Thus, we will just give a table of the 
parameter names, their C interface complements and the values they can be set 
to, rather than their detailed descriptions. For each parameter, the user 
can see the C interface complement for further explanation. \\

\resizebox{16cm}{7cm}{
\begin{tabular}{|l||l||l|} \hline
{\bf C++ Interface} & {\bf C Interface} & {\bf Value}\\ \hline \hline
OsiSymVerbosity & verbosity & -user defined- \\
\hline \hline
OsiSymWarmStart & warm\_start & -boolean- \\
\hline \hline
OsiSymNodeLimit &  & \\
OsiMaxNumIteration & node\_limit & -user defined-\\
OsiMaxNumIterationHotStart & & \\
\hline \hline
OsiSymFindFirstFeasible & find\_first\_feasible & -boolean- \\
\hline \hline
OsiSymSearchStrategy & node\_selection\_rule & LOWEST\_LP\_FIRST \\
& & HIGHEST\_LP\_FIRST \\
& & BREADTH\_FIRST\_SEARCH \\
& & DEPTH\_FIRST\_SEARCH \\
\hline \hline
OsiSymUsePermanentCutPools & use\_permanent\_cut\_pools & -boolean- \\
\hline \hline
OsiSymGenerateCglGomoryCuts & generate\_cgl\_gomory\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglKnapsackCuts & generate\_cgl\_knapsack\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglOddHoleCuts & generate\_cgl\_oddhole\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglProbingCuts & generate\_cgl\_probing\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglCliqueCuts & generate\_cgl\_clique\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglFlowAndCoverCuts & generate\_cgl\_flow\_and\_cover\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglRoundingCuts & generate\_cgl\_rounding\_cuts & -boolean- \\
\hline \hline
OsiSymGenerateCglLiftAndProjectCuts & generate\_cgl\_lift\_and\_project\_cuts & -boolean- \\
\hline \hline
OsiSymKeepWarmStart & keep\_warm\_start & -boolean- \\
\hline \hline
OsiSymTrimWarmTree & trim\_warm\_tree * -boolean- \\
\hline \hline
OsiSymDoReducedCostFixing & do\_reduced\_cost\_fixing & -boolean- \\
\hline \hline
OsiSymMCFindSupportedSolutions & 
mc\_find\_supported\_solutions & -boolean- \\
\hline \hline
OsiSymSensitivityAnalysis & sensitivity\_analysis & -boolean- \\
\hline \hline
OsiSymRandomSeed & random\_seed & -user defined-\\
\hline \hline
OsiSymDivingStrategy & diving\_strategy & BEST\_ESTIMATE \\
& & COMP\_BEST\_K \\
& & COMP\_BEST\_K\_GAP \\
\hline \hline
OsiSymDivingK & diving\_k & -user defined- \\
\hline \hline
OsiSymDivingThreshold & diving\_threshold & -user defined- \\
\hline \hline
OsiSymGranularity & granularity & -user defined- \\
\hline \hline
OsiSymTimeLimit & time\_limit & -user defined- \\
\hline \hline   
OsiSymGapLimit & gap\_limit & -user defined- \\
\hline \hline
OsiObjOffset & - & -user defined- \\
\hline \hline
OsiProbName & problem\_name & -user defined- \\
\hline 
\end{tabular}
} \\

However, as it is seen, only some of the C interface parameters have their 
matches. If the other parameters are required to be modified, the user 
can always set them directly by their C interface names, 
using the overlapping functions: {\tt setSymParam(string, int), 
setSymParam(string, double) and setSymParam(string,string)}. For instance, 
the \ptt{verbosity} parameter can be set, let's say, to 2 either by 
setSymParam(OsiSymVerbosity, 2) or by setSymParam(``verbosity'', 2). 
Note that, this flexibility is also supported for parameter querying 
functions. 

