### Table of Contents

- 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 [214, 72, 215, 221, 124, 163, 108, 245, 226, 246, 218, 107, 216, 236, 237, 238, 241, 242, 220, 217, 222, 10, 239, 219, 240, 55, 25, 205, 26, 141, 142, 268, 269, 143, 270, 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 with GAMS 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 user-specified LP and NLP solver, BARON will automatically select a licensed LP and NLP solver and may default to CLP and IPOPT if no other LP and NLP solver is available, respectively. BARON can be used without a local NLP solver by setting DoLocal 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 β, `x`

^{y}, 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 Bound` | Current lower bound on the model. |

`Upper Bound` | Current 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). h@mi nlp.c 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%'; execute_load 'merged.gdx', xsol=x, zsol=z; 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 in the listing file:

Number of equations in the IIS: 1. Upper: e_2 <= 110 Number of variables in the IIS: 3. Lower: x_1 >= 78 Lower: x_2 >= 33 Lower: x_5 >= 27

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

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

as well as the more general mixed complementarity problem

\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`DeltaA` (δ_{a}) must be ≥ 1e-12.Range: [ `1e-12` , ∞] | `∞` |

DeltaR | Relative improvement for insufficient progress termination`DeltaR` (δ_{r}) 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 `DeltaT` (δ_{t}) 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 DeltaT (δ _{t}) consecutive seconds. Progress is measured using the absolute and relative improvement thresholds DeltaA (δ_{a}) and DeltaR (δ_{r}). 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 `t` -δ_{t}. 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

## Tree management options

## 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

## 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 -1 or 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 By default, BARON will select the LP solver and may switch between different LP solvers during the search according to problem characteristics and solver performance. The solvers CPLEX, if available, and CBC will be used for this purpose. A single specific LP 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 LP solver selection and switching strategy`3` : CPLEX`7` : XPRESS`8` : CLP/CBC`15` : HSL LA04 | `-1` |

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 to provide dual solution values`0` : BARON may or may not return a dual solution.`1` : BARON will return a dual solution using an inexpensive technique to solve a KKT system corresponding to the best primal solution identified | `1` |

## Interface and Conversion

Option | Description | Default |
---|---|---|

BarName | Name of BARON problem file to be written | `225a/mybaron.dat` |

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. |