BARON

Date
5 June 2015

Introduction

The Branch-And-Reduce Optimization Navigator (BARON) is a GAMS solver for the global solution of nonlinear (NLP) and mixed-integer nonlinear programs (MINLP).

While traditional NLP and MINLP algorithms are guaranteed to converge only under certain convexity assumptions, BARON implements deterministic global optimization algorithms of the branch-and-bound type that are guaranteed to provide global optima under fairly general assumptions. These include the existence of finite lower and upper bounds on nonlinear expressions in the NLP or MINLP to be solved.

BARON implements algorithms of the branch-and-bound type enhanced with a variety of constraint propagation, interval analysis, and duality techniques for reducing ranges of variables in the course of the algorithm. Rigorous relaxations are constructed by enlarging the feasible region and/or underestimating the objective function.

Parts of the BARON software were created at the University of Illinois at Urbana-Champaign. The algorithms implemented in the software, the theory behind them, and some related applications are (partly) described in [208, 73, 209, 215, 123, 160, 108, 239, 220, 240, 212, 107, 210, 230, 231, 232, 235, 236, 214, 211, 216, 10, 233, 213, 234, 56, 25, 199, 26, 140, 141, 262, 263, 142, 264, 27] .

Licensing and software requirements

In order to use GAMS/BARON, users will need to have a GAMS/BARON license. BARON comes with several embedded LP/MIP and NLP solvers (CBC; IPOPT, FilterSD, FilterSQP). Additionally, GAMS/BARON users can expedite convergence by accessing CPLEX and XPRESS to solve BARON's LP/MIP subproblems and MINOS, SNOPT, and any GAMS NLP solver, such as CONOPT, to solve BARON's NLP subproblems. These solvers need to be licensed separately.

By default, GAMS/BARON will attempt to use CPLEX as the LP solver and select an NLP solver automatically. The user can use the options LPSol and NLPSol to specify the LP or NLP solver. If the user does not have a license for the default or user-specified LP solver, BARON will switch to CLP. If the user does not have a license for the user-specified NLP solver, BARON will automatically select a licensed NLP solver and may default to IPOPT if no other NLP solver is available. BARON can be used without a local NLP solver by setting DoLocal and and NumLoc to 0.

Running GAMS/BARON

BARON is capable of solving models of the following types: LP, MIP, RMIP, NLP, DNLP, RMINLP, and MINLP. If BARON is not specified as the default solver for these models, it can be invoked by issuing the following command before the solve statement:

option <modeltype>=baron;


where <modeltype> stands for LP, MIP, RMIP, QCP, MIQCP, RMIQCP, CNS, NLP, DNLP, MINLP, or RMINLP.

Model requirements

In order to achieve convergence to global optimality, additional model constraints may be required. The additional constraints may speed up solver time and increase the probability of success.

Variable and expression bounds

All nonlinear expressions in the mathematical program to be solved must be bounded below and/or above. It is important that finite lower and upper bounds be provided by the user on all problem variables. Note that providing finite bounds on variables alone may not suffice to guarantee finite bounds on nonlinear expressions arising in the model.

For example, consider the term 1/x for x[0,1], which has finite variable bounds, but is unbounded. It is important to provide bounds for problem variables that guarantee that the problem functions are finitely-valued. If the user model does not include variable bounds that guarantee that all nonlinear expressions are finitely-valued, BARON will attempt to infer appropriate bounds from problem constraints. If this step fails, global optimality of the solutions provided is not guaranteed. Occasionally, because of the lack of bounds no numerically stable lower bounding problems can be constructed, in which case BARON may terminate.

See section Some BARON features on how to specify variable bounds.

Allowable nonlinear functions

In addition to multiplication and division, GAMS/BARON can handle nonlinear functions that involve exp(x), ln(x), xα for real α, βx for real β, xy, and |x|. Currently, there is no support for other functions, including the trigonometric functions sin(x), cos(x), etc.

BARON output

BARON log output

The log output below is obtained for the MINLP model gear.gms from the GAMS model library using absolute and relative optimality tolerances of 1e-6.

===========================================================================
BARON version 15.6.5. Built: LNX-64 Fri Jun 5 08:34:09 EDT 2015

If you use this software, please cite:
Tawarmalani, M. and N. V. Sahinidis, A polyhedral
branch-and-cut approach to global optimization,
Mathematical Programming, 103(2), 225-249, 2005.

BARON is a product of The Optimization Firm, LLC. http://www.minlp.com/
Parts of the BARON software were created at the
University of Illinois at Urbana-Champaign.
===========================================================================
This BARON run may utilize the following subsolver(s)
For LP/MIP: ILOG CPLEX
For NLP: MINOS, SNOPT, GAMS external NLP, COIN IPOPT with MUMPS and METIS, FILTERSD
===========================================================================
Starting solution is feasible with a value of     36.1767610000
Doing local search
Solving bounding LP
Starting multi-start local search
Preprocessing found feasible solution with value  4.23791612465
Done with local search
===========================================================================
Iteration    Open nodes         Time (s)    Lower bound      Upper bound
1             1             0.02     1.00000          4.23792
*         1+            1             0.02     1.00000          3.29321
*         1+            1             0.02     1.00000          2.20487
1             1             0.02     1.00000          2.20487
*         2             2             0.02     1.00000          1.06987
*         3+            1             0.03     1.00000          1.01273
*         4+            2             0.03     1.00000          1.00117
*         4+            2             0.03     1.00000          1.00018
*         4             2             0.03     1.00000          1.00004
*        14             8             0.04     1.00000          1.00001
*        30             0             0.05     1.00000          1.00000
30             0             0.05     1.00000          1.00000

Cleaning up

*** Normal completion ***

Wall clock time:                     0.05
Total CPU time used:                 0.05

Total no. of BaR iterations:      30
Best solution found at node:      30
Max. no. of nodes in memory:      11

All done
===========================================================================


The solver first tests feasibility of the user-supplied starting point. This point is found to be feasible with an objective function value of 36.1767610000. BARON subsequently performs a randomized local search procedure and, eventually, finds a feasible solution with an objective of 4.23791612465. Then, the iteration log provides information every 1,000,000 branch-and-bound iterations and every 30 seconds. Additionally, information is printed at the end of the root node, whenever the value of the incumbent is improved by at least 10-5, and at the end of the search. A star (*) in the first position of a line indicates that a better feasible solution was found that improves the value of previous best known solution by at least 10-5. The log fields include the iteration number, number of open branch-and-bound nodes, the CPU time taken thus far, the lower bound, and the upper bound for the problem. The log output fields are summarized below:

Field Description
Itn. no. The number of the current iteration. A plus (+) following the iteration number denotes reporting while solving a probing (as opposed to a relaxation) subproblem of the corresponding node.
Open Nodes Number of open nodes in branch-and-reduce tree.
Time Current computational time in seconds. CPU time is reported for single-threaded jobs and wall clock time is reported for multi-threaded jobs.
Lower BoundCurrent lower bound on the model.
Upper BoundCurrent upper bound on the model.

Once the branch-and-reduce tree is searched, the best solution is isolated and a corresponding dual solution is calculated. Finally, the total number of branch-and-reduce iterations (number of search tree nodes) is reported, followed by the node where the best solution was identified (a -1 indicates preprocessing as explained in the next section on termination messages).

Termination messages, model and solver statuses

Upon normal termination, BARON will report the node where the optimal solution was found. We refer to this node as nodeopt. Associated with this node is a return code indicating the status of the solution found at nodeopt. The return code is given in the log line:

Best solution found at node:  (return code)


The return codes have the following interpretation:

-3 : no feasible solution found

-2 : the best solution found was the user-supplied

-1 : the best solution was found during preprocessing

i : the best solution was found in the i-th node of the tree

In addition to reporting nodeopt, upon termination, BARON will issue one of the following statements:

*** Normal completion ***

This is the most desirable termination status. The problem has been solved within tolerances in this case. If BARON returns a code of -3, then no feasible solution exists.

*** Heuristic termination ***

While global optimality is not guaranteed in this case, BARON will terminate with this message when (a) a feasible solution has been found and (b) the progress of lower/upper bounds satisfies the heuristic termination criterion set by the user through BARON's DeltaTerm option.

*** User did not provide appropriate variable bounds ***

The user will need to read the BARON output (in file sum.dat in the scratch directory, use GAMS parameter keep=1 to prevent the automatic removal of this directory) for pointers to variables and expressions with missing bounds. The model should be modified in order to provide bounds for variables and intermediate expressions that make it possible for BARON to construct reliable relaxations. Even though relaxation bounds are printed on the screen to give the user a feeling for convergence, these bounds may not be valid for the problem at hand. This message is followed by one of the following two messages:

***Infeasibility is therefore not guaranteed ***

This indicates that, because of missing bounds, no feasible solution was found, but model infeasibility was not proven.

 *** Globality is therefore not guaranteed ***

This indicates that, because of missing bounds, a feasible solution was found, but global optimality was not proven.

*** Max. allowable nodes in memory reached ***

The user will need to increase the physical memory of the computer or change algorithmic options, such as branching and node selection rules, to reduce the size of the search tree and memory required for storage.

*** Max. allowable BaR iterations reached ***

The user will need to increase the maximum number of allowable iterations. The BARON option is MaxIter. To specify this in GAMS, one can use the NodLim option. We remark that the BARON option MaxIter overrides NodLim.

*** Max. allowable CPU time exceeded ***

The user will need to increase the maximum of allowable CPU time. The BARON option is MaxTime. To specify this in GAMS, one can use the ResLim option. We remark that the BARON option MaxTime overrides ResLim.

*** Problem is numerically sensitive ***

BARON is designed to automatically handle problems with numerical difficulties. However, for certain problems, the global optimum is numerically sensitive. This occurs, for instance, when the objective function value varies significantly over small neighborhoods of points that are strictly outside the feasible region but nonetheless feasible within numerical tolerances. When BARON returns this message, the "Best possible" reported on the objective is likely correct.

*** Search interrupted by user ***

The run was interrupted by the user (Ctrl-C).

*** Insufficient memory for data structures ***

More memory is needed to set up the problem data structures. The user will need to increase the physical memory available on the computer in order to accommodate problems of this size.

*** A potentially catastrophic access violation just took place ***

In the unlikely event of a memory access violation, BARON will terminate the search and return the best known solution. Please report problems that lead to this condition to Nick Sahinidis (niksa.nosp@m.h@mi.nosp@m.nlp.c.nosp@m.om).

Some BARON features

The features described in this section rely on options that are further detailed in the next section. For details of the algorithmic implementations, the user may wish to consult publications cited at the end of this document.

No starting point is required

In contrast to many NLP algorithms that require a feasible starting point, a starting point is not required for BARON. A user may optionally provide a starting point for all or even some of the problem variables. BARON will judiciously initialize any variables that are not initialized by the user. Even when the problem functions cannot be evaluated at a user-provided starting point, BARON is still capable of carrying out its global search.

For problems for which GAMS compilation is aborted because the nonlinear functions cannot be evaluated at the starting point, the user can use the following commands before the SOLVE statement:

MaxExecError = 100000;
option sys12 = 1;


The first command asks GAMS to continue compilation for as many as MaxExecError execution errors. The sys12 option will pass the model to the BARON despite the execution errors. Even though the starting point is bad in this case, BARON is capable of carrying out its global search.

Finding a few of the best or all feasible solutions

BARON offers a facility, through its NumSol option, to find the best few, or even all feasible, solutions to a model. The development of this facility was motivated by combinatorial optimization problems but the facility is applicable to continuous problems as well. Even for combinatorial problems, BARON does not rely on integer cuts to find multiple solutions. Instead, it utilizes a single search tree, thus providing a computationally efficient method for finding multiple solutions. Furthermore, because BARON's approach applies to integer as well as continuous programs, it can be used to find all feasible solutions to a system of nonlinear equality and inequality constraints.

Once a model is solved by BARON with the NumSol option, the solutions found can be recovered using the GAMS GDX facility. An example is provided below.

$eolcom !$Ontext
Purpose: demonstrate use of BARON option 'numsol' to obtain the best
numsol solutions of an optimization problem in a single branch-and-bound
search tree.

The model solved here is a linear general integer problem with 18 feasible
solutions.  BARON is run with a request to find up to 20 solutions.  The
model solved is the same as the one solved in gamslib/icut.gms.
$Offtext set i index of integer variables / 1 * 4 / variables x(i) variables z objective variable integer variable x; x.lo(i) = 2; x.up(i) = 4; x.fx('2') = 3; ! fix one variable x.up('4') = 3; ! only two values equation obj obj definition; * pick an objective function which will order the solutions obj .. z =e= sum(i, power(10,card(i)-ord(i))*x(i)); model enum / all /; * instruct BARON to return numsol solutions$onecho > baron.opt
numsol 20
gdxout multsol
\$offecho

enum.optfile=1; option mip=baron, limrow=0, limcol=0, optca=1e-5,
optcr=1e-5; solve enum minimizing z using mip;

* recover BARON solutions through GDX
set sol /multsol1*multsol100/; variables xsol(sol,i), zsol(sol);

execute 'gdxmerge multsol*.gdx >  %gams.scrdir%merge.%gams.scrext%';

option decimals=8;

display xsol.l, zsol.l;


Using BARON as a multi-start heuristic solver

To gain insight into the difficulty of a nonlinear program, especially with regard to existence of multiple local solutions, modelers often make use of multiple local searches from randomly generated starting points. This can be easily done with BARON's NumLoc option, which determines the number of local searches to be done by BARON's preprocessor. BARON can be forced to terminate after preprocessing by setting the number of iterations to 0 through the MaxIter option. In addition to local search, BARON's preprocessor performs extensive reduction of variable ranges. To sample the search space for local minima without range reduction, one would have to set to 0 the range reduction options TDo, MDo, LBTTDo, and OBTTDo. On the other hand, leaving these options to their default values increases the likelihood of finding high quality local optima during preprocessing. If NumLoc is set to -1, local searches in preprocessing will be done from randomly generated starting points until global optimality is proved or MaxTime seconds have elapsed.

Systematic treatment of unbounded problems

If BARON declares a problem as unbounded, it will search for and may report a vertex and direction of an unbounded ray. In addition, BARON will report the best solution found. This will be a feasible point that is as far as possible along an unbounded ray while avoiding numerical errors due to floating point arithmetic.

Systematic treatment of infeasible problems

If BARON declares a problem as infeasible, it has the capability to identify a subset of the constraints that are infeasible and become feasible once any one of them is eliminated. This, so-called, irreducibly inconsistent system (IIS) can be obtained by BARON for all types of problems handled by BARON, including linear and nonlinear, continuous and integer, convex and nonconvex, and problems with complementarity constraints. BARON's CompIIS option can be used to identify an IIS.

As an example, consider the problem of minimizing the nonconvex function $$x_1 x_3$$ over the following nonconvex constrained set:

\begin{eqnarray*} & e_1: & 85 + 0.006 x_2 x_5 + 0.0006 x_1 x_4 - 0.002 x_3 x_5 <= 92 \\ & e_2: & 0.8 x_2 x_5 + 0.003 x_1 x_2 + 0.002 x_3^2 = 110 \\ & e_3: & 9 + 0.005 x_3 x_5 + 0.001 x_1 x_3 + 0.002 x_3 x_4 <= 25 \\ & & 78 \leq x_1 \leq 102 \\ & & 33 \leq x_2 \leq 45 \\ & & 27 \leq x_i \leq 45, \quad i=3,\ldots,5 \end{eqnarray*}

When this problem is solved with CompIIS equal to 1, BARON provides the following result:

IIS contains 1 row and 3 columns as follows:
e2   Upper
x1   Lower
x2   Lower
x5   Lower


The IIS consists of the lower bounds of variables $$x_1$$, $$x_2$$, and $$x_5$$, along with the $$\le$$ part of the equality constraint $$e_2$$. This suggests that constraint $$e_2$$ and the entire model can be made feasible by lowering the lower bound of any of the three variables that are part of the IIS, whereas modifying the bounds of $$x_3$$ would not make the model feasible.

If a problem is known to be infeasible and the user desires to identify an IIS, it may be beneficial to set BARON's NumLoc option to zero. Doing so will deactivate BARON's initial upper bounding search, which involves multiple local searches. On the other hand, DoLocal should be nonzero in order to permit local search during the solution of certain subproblems that BARON solves while searching for an IIS.

Handling of complementarity constraints

Complementarity relationships of the type f(x)g(x) = 0 are automatically recognized and exploited algorithmically by BARON. The functions f and g may be univariate or multivariate, linear or nonlinear, convex or nonconvex, in terms of continuous and/or integer variables, and may be subject to additional constraints in the model. These complementarity relationships can be inferred by BARON even when implied by problem constraints and variable bounds. As a result, BARON can solve general mathematical programs with equilibrium constraints (MPECs). This class of problems includes the classical linear complementarity problem

(LCP): Find $$z\geq 0$$ and $$q$$ such that

\begin{align*} Mz + q & \geq 0, \\ z^t(Mz + q) & = 0 \end{align*}

as well as the more general mixed complementarity problem

(MCP): Given a function $$f: \mathbb{R}^n \rightarrow \mathbb{R}^n$$ and bounds $$l, u \in \mathbb{R}^n$$ with $$\overline{\mathbb{R}} = \mathbb{R}\cup \{-\infty,+\infty\}$$, find $$z \in \mathbb{R}^n$$ and $$w, v\in \mathbb{R}^n_+$$ such that

\begin{align*} f(z)&=w-v,\\ l \le z &\le u, \\ (z-l)^t w &= 0,\\ (u-z)^t v &= 0. \end{align*}

Both problems are automatically recognized and exploited by BARON without the user having to mark complementarities in any special way. In GAMS, all these problems can be solved by BARON when declared as NLP or MINLP models.

Parallel capabilities

For difficult problems with integer variables, most of BARON's time is spent on solving MIP relaxations. Hence, considerable speedups may be obtained via parallel solution of the MIP subproblems. For this purpose, the option threads may be used to specify the number of cores that BARON's MIP subsolver is allowed to use. By default, this option has the value of 1, meaning that a single core will be utilized.

The BARON options

The BARON options allow the user to control termination tolerances, branching and relaxation strategies, heuristic local search options, and output options as detailed in this section.

Many options can also be set in the GAMS model. The most relevant GAMS options are ResLim, NodLim, OptCA, OptCR, OptFile, and CutOff. The IterLim option is not implemented. specify BARON iterations, the user can set the MaxIter option, which is equivalent to the GAMS option NodLim.

Additionally, a BARON Options file can be provided. See section The Solver Options File for general use of solver option files.

For branching, users can specify separate branching priorities for any discrete and continuous variables using Dot Options. To specify variable branching priorities, one specifies

(variable).prior(value)

in the BARON options file, where (value) can be any non-negative real value. The lower the value, the higher the priority for branching, see also Setting Priorities for Branching. Specifying maxdouble for (value) translates to passing 0 as branching priority for (variable).

Termination options

Option Description Default
AbsConFeasTol Absolute constraint feasibility tolerance
This tolerance is used for general constraints and variable bounds. AbsConFeasTol must be ≥ 1e-12. A point is considered feasible for a constraint/bound if the absolute or relative constraint feasibility tolerance is satisfied.
Range: [1e-12, ∞]
1e-5
AbsIntFeasTol Absolute integer feasibility tolerance
All integer variable values must satisfy this tolerance. AbsIntFeasTol must be ≥ 1e-12. A point is considered integer feasible for a variable if integrality is satisfied using the absolute or relative integer feasibility tolerance.
Range: [1e-12, ∞]
1e-5
BoxTol Box elimination tolerance.
Boxes will be eliminated if smaller than this tolerance. BoxTol must be ≥ 1e-12.
1e-8
CutOff Eliminate solutions that are no better than this value
Can also be used with the GAMS model attribute option CutOff.
GAMS CutOff
DeltaA Absolute improvement for insufficient progress termination
DeltaAa) must be ≥ 1e-12.
Range: [1e-12, ∞]
∞
DeltaR Relative improvement for insufficient progress termination
DeltaRr) must be ≥ 1e-12.
Range: [1e-12, ∞]
1
DeltaT Time interval for insufficient progress termination
If DeltaTerm is set to 1, BARON will terminate if insufficient progress is made over DeltaTt) consecutive seconds. If δt is set to a non-positive quantity, BARON will automatically set δt equal to -δt times the CPU time taken till the end of root node processing. DeltaT can take any real value.
Range: [-∞, ∞]
-100
DeltaTerm Indicates whether insufficient progress termination is on or off
Users have the option to request BARON to terminate if insufficient progress is made over DeltaTt) consecutive seconds. Progress is measured using the absolute and relative improvement thresholds DeltaAa) and DeltaRr). Termination will occur if, over a period of δt consecutive seconds, the value of the best solution found by BARON is not improved by at least an absolute amount δa or an amount equal to δr times the value of the incumbent at time tt. This termination condition is enforced after processing the root node and only after a feasible solution has been obtained. Because it relies on CPU time measurements, which may depend on machine load, this option may result in nondeterministic behavior.
0: do not enforce this termination condition
1: terminate if progress is insufficient
0
EpsA Absolute termination tolerance.
BARON terminates if |U-L|EpsA, where U and L are the upper and lower bound, respectively, on the optimal value of the optimization problem at the current iteration. EpsA must be ≥ 1e-12.
GAMS OptCA
EpsR Relative termination tolerance.
BARON terminates if |U-L|EpsR|L|, where U and L are the upper and lower bound, respectively, on the optimal value of the optimization problem at the current iteration. EpsR must be ≥ 0.
GAMS OptCR
FirstFeas Changes the search for first numsol solutions
If set to 1, BARON will terminate once it finds NumSol feasible solutions, irrespective of solution quality.
0: search for the best NumSol feasible solutions
1: find NumSol solutions irrespective of solution quality
0
FirstLoc Terminate the search as soon as a local optimum is found 0
ISolTol Solution Distance
Separation distance between solutions. This option is used in conjunction with NumSol. For combinatorial optimization problems, feasible solutions are isolated. For continuous problems, feasible solution points within an l distance that does not exceed IsolTol will be treated as identical by BARON. IsolTol must be ≥ 1e-12.
1e-4
MaxIter Maximum number of branch-and-reduce iterations allowed
Setting MaxIter to 0 will force BARON to terminate after root node preprocessing. Setting MaxIter to 1 will result in termination after the solution of the root node. MaxIter must be ≥ -1, where -1 implies unlimited.
Range: [-1, ∞]
GAMS NodeLim
MaxTime Maximum time allowed (sec)
MaxTime must be -1 or > 0, where -1 implies unlimited. For single-threaded jobs, i.e., when threads equals 1, this limit is enforced on CPU time consumed by the job. For multi-threaded jobs, the limit is enforced on wall clock time.
GAMS ResLim
NumSol Number of feasible solutions to be found
Solutions found will be listed in the results file. As long as NumSol ≠ -1, these solutions will be sorted from best to worse. If NumSol is set to -1, BARON will search for all feasible solutions to the given model and print them, in the order in which they are found, in the results file. NumSol must be ≥ -1.
Range: [-1, ∞]
1
RelConFeasTol Relative constraint feasibility tolerance
This tolerance is used for general constraints and variable bounds. RelConFeasTol must be ≥ 0. A point is considered feasible for a constraint/bound if the absolute or relative constraint feasibility tolerance is satisfied.
Range: [0, 0.1]
0
RelIntFeasTol Relative integer feasibility tolerance
All integer variable values must satisfy this tolerance. RelIntFeasTol must be ≥ 0. A point is considered integer feasible for a variable if integrality is satisfied using the absolute or relative integer feasibility tolerance.
Range: [0, 0.1]
0

Relaxation options

Option Description Default
Nouter1 Number of outer approximators of convex univariant functions
NOuter1 must be ≥ 0.
4
NoutIter Number of rounds of cutting plane generation at node relaxation
NOutIter must be a ≥ 0.
4
NoutPerVar Number of outer approximations per variable for convex multivariate functions
NOutPerVar must be ≥ 0.
4
OutGrid Number of grid points per variable for convex multivariate approximators of BARON's CONVEX_EQUATIONS.
OutGrid must be a ≥ 0.
20
Threads Number of cores used for solution of MIP subproblems
The value of this option is passed to CBC, CPLEX, and XPRESS.
Range: [1, ∞]
max(1,GAMS Threads)

Range reduction options

Option Description Default
LBTTDo Linear-feasibility-based range reduction option (poor man's LPs)
0: no range reduction based on feasibility.
1: range reduction done based on feasibility.
1
MDo Marginals-based reduction option
0: no range reduction based on marginals.
1: range reduction done based on marginals.
1
OBTTDo Optimality based tightening option
0: no range reduction based on optimality.
1: range reduction done based on optimality.
1
PDo Number of probing problems allowed
-2: automatically decided by BARON.
-1: probing on all variables.
0: no range reduction by probing.
n: probing on n variables.
-2
TDo Nonlinear-feasibility-based range reduction option (poor man's NLPs)
0: no bounds tightening is performed.
1: bounds tightening is performed.
1

Tree management options

Option Description Default
BrPtStra Branching point selection strategy
0: BARONs dynamic strategy
1: w-branching
2: bisection-branching
3: convex combination of 1 and 2
0
BrVarStra Branching variable selection strategy
0: BARONs dynamic strategy
1: largest violation
2: longest edge
0
NodeSel Specifies the node selection rule to be used for exploring the search tree
Specifies the node selection rule to be used for exploring the search tree.
0: BARONs mixed selection scheme
1: best bound
2: last in first out [LIFO]
3: minimum infeasibility
0

Local search options

Option Description Default
DoLocal Local search option for upper bounding
0: no local search is done during upper bounding
1: BARON's dynamic local search decision rule
1
NumLoc Number of local searches done in preprocessing
The first local search begins with the user-specified starting point. Subsequent local searches are done from judiciously chosen starting points. If NumLoc is set to -1, local searches in preprocessing will be done until proof of globality or MaxTime is reached. If NumLoc is set to -2, BARON decides the number of local searches in preprocessing based on problem and NLP solver characteristics. NumLoc must be ≥ -2.
Range: [-2, ∞]
-2

Output Options

Option Description Default
LocRes Option to control output from local search
0: no local search output
1: detailed results from local search will be printed to res.dat file
0
prfreq Log output frequency in number of nodes 1000000
prlevel Defines the level of log output printed.
0: all log output is suppressed
1: print log output
1
prtimefreq Log output frequency in number of seconds 30

Subsolver Options

Option Description Default
AllowExternal Indicator for use of External NLP solver with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of external GAMS NLP solver as an NLP subsolver.
0: do not use the GAMS external NLP solver for local search
1: consider the GAMS external NLP solver for local search
1
AllowFilterSD Indicator for use of FILTERSD with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of FILTERSD as an NLP subsolver.
0: do not use FILTERSD for local search
1: consider FILTERSD for local search
1
AllowFilterSQP Indicator for use of FILTERSQP with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of FILTERSQP as an NLP subsolver.
0: do not use FILTERSQP for local search
1: consider FILTERSQP for local search
1
AllowIpopt Indicator for use of IPOPT with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of IPOPT as an NLP subsolver. Currently, this option defaults to 0 on Mac OS X.
0: do not use IPOPT for local search
1: consider IPOPT for local search
1
AllowMinos Indicator for use of MINOS with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of MINOS as an NLP subsolver.
0: do not use MINOS for local search
1: consider MINOS for local search
1
AllowSnopt Indicator for use of SNOPT with automatic NLP solver selection
In case of automatic NLP solver selection, this option can be used to selectively permit or disallow the use of SNOPT as an NLP subsolver.
0: do not use SNOPT for local search
1: consider SNOPT for local search
1
ExtNLPsolver External GAMS NLP solver and option file (e.g. conopt.1)
Specifies the GAMS NLP solver to be used when NLPSol is set to 6. All GAMS NLP solvers are available through this option. If a non-existing solver is specified or the solver chosen cannot solve NLPs, NLPSol will be reset to its default. A GAMS solver options file can be specified for the GAMS NLP solver by adding a dot followed by the options file number to the solver name, e.g., setting ExtNLPSolver to CONOPT.42 would instruct GAMS/CONOPT to use options file conopt.o42.
conopt
LPAlg Specifies the LP algorithm to be used (available only with CPLEX as the LP solver)
0: automatic selection of LP algorithm
1: primal simplex
2: dual simplex
3: barrier
0
LPSol Specifies the LP/MIP Solver to be used
3: CPLEX
7: XPRESS
8: CLP
3
NLPSol Specifies the NLP solver to be used
By default, BARON will select the NLP solver and may switch between different NLP solvers during the search, based on problem characteristics and solver performance. Any combination of licensed NLP solvers may be used in that case. A single specific NLP solver can be specified by setting this option to a value other than the default. If the specified solver is not licensed, BARON will default to automatic solver selection.
-1: Automatic NLP solver selection and switching strategy
0: Local search based on function evaluations alone with no calls to local solvers
2: MINOS
4: SNOPT
6: GAMS NLP solver (see ExtNLPsolver)
9: IPOPT
10: FILTERSD
14: FILTERSQP
-1

Other Options

Option Description Default
CompIIS Request the computation of an Irreducible Inconsistent Set (IIS)
In case of an infeasible problem, this option can be used to search for an IIS. Setting this option 1, works very well for most problems.
0: do not search for an IIS
1: the search for an IIS is based on a fast heuristic
2: an IIS is obtained using a deletion filtering algorithm
3: an IIS is obtained using an addition filtering algorithm
4: an IIS is obtained using an addition-deletion filtering algorithm
5: an IIS is obtained using a depth-first search algorithm
0
IISInt Indicates whether general integers should be considered as potential members of the IIS
When search for an IIS is requested through CompIIS, BARON assumes that the model is unlikely to include an error in terms of binaries, i.e., the binary definitions are assumed correct and the IIS output should be interpreted with respect to binary definitions. General integer bounds may be assumed as correct or can be questioned using the option IISint. Integrality is enforced in both cases.
0: do not consider general integers as part of an IIS, assume them to be correct
1: consider general integers (but not binaries) as part of an IIS
0
IISOrder Order in which constraints are considered in the search for an IIS
-1: auto set to aim for a small IIS depending on the value of CompIIS
1: arrange constraints in problem order
2: arrange constraints in ascending order of degree
3: arrange constraints in descending order of degree
>3: random order using IISorder as seed
-1
InfBnd infinity value to be used on bounds
If set to 0, then no bounds are used.
0
WantDual whether to try hard to provide dual solution values
0: use an inexpensive way to solve the KKT system to provide dual values
1: make a final call to the NLP solver to compute dual values if the inexpensive way of solving the KKT system failed
1 for LP/RMIP, 0 otherwise

Interface and Conversion

Option Description Default
ClockType Type of clock to use when reporting solving time back to GAMS
wall: report time according to "clock on the wall" (as used by most GAMS solver links)
cpu: report time used by CPU (summed up over all cores)
baron: report same time as used by BARON ("cpu" if one thread, "wall" if multiple threads)
wall
.EquClass Equation Classification
Specifies nature of named constraint in the users model. This is a Dot Option. Slices like supply.EquClass("new-york") 1 are allowed.
0: Regular constraint.
1: Relaxation-only constraint. These constraints are provided to BARON as RELAXATION_ONLY_EQUATIONS and used to help strengthen the relaxation bound but are not considered as part of the user model and thus not used for feasibility testing of solutions or local search. Adding, for instance, the first-order optimality conditions as relaxation-only constraints often expedites convergence.
2: Convex constraint. These constraints are provided to BARON as CONVEX_EQUATIONS and used to generate cutting planes from the set of outer approximating supporting hyperplanes of the convex constraint set.
3: Convex constraint that is relaxation-only.
0
GDXOut Prefix for GDX file names for multiple solutions if NumSol > 1.