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 [156, 50, 157, 163, 92, 119, 78, 186, 167, 187, 160, 77, 158, 177, 178, 179, 182, 183, 162, 159, 164, 6, 180, 161, 181, 35, 11, 148, 12, 105, 106, 205, 206, 107, 207, 13] .
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/QP 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/QP 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/MIP/QP and NLP solver, respectively. If the user does not have a license for the user-specified solver, BARON will automatically select a licensed one and may default to CLP/CBC and IPOPT if no other LP/MIP 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 β, 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 24.5.8. Built: LNX-64 Wed May 8 10:06:40 EDT 2024
Running on machine blackpepper
BARON is a product of The Optimization Firm.
For information on BARON, see https://minlp.com/about-baron
If you publish work using this software, please cite publications from
https://minlp.com/baron-publications, such as:
Khajavirad, A. and N. V. Sahinidis,
A hybrid LP/NLP paradigm for global optimization relaxations,
Mathematical Programming Computation, 10, 383-421, 2018.
===========================================================================
This BARON run may utilize the following subsolver(s)
For LP/MIP/QP: CLP/CBC, ILOG CPLEX
For NLP: MINOS, SNOPT, External NLP, IPOPT, FILTERSQP
===========================================================================
Starting solution is feasible with a value of 36.1768
Doing local search
Solving bounding LP
Starting multi-start local search
Preprocessing found feasible solution with value 1.02321
Preprocessing found feasible solution with value 1.00014
Done with local search
===========================================================================
Iteration Open nodes Time (s) Lower bound Upper bound
1 1 0.04 1.00000 1.00014
* 5 3 0.05 1.00000 1.00006
* 6 4 0.06 1.00000 1.00002
* 7 0 0.06 1.00000 1.00001
7 0 0.06 1.00001 1.00001
*** Normal completion ***
Wall clock time: 0.07
Total CPU time used: 0.06
Total no. of BaR iterations: 7
Best solution found at node: 7
Max. no. of nodes in memory: 4
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 1.00014. 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 thei-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.datin the scratch directory, use GAMS parameterkeep=1to 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 (niksah@minlp.com).
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
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 terminationDeltaA (δa) must be ≥ 1e-12.Range: [ 1e-12, ∞] | ∞ |
| DeltaR | Relative improvement for insufficient progress terminationDeltaR (δ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 condition1: 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|U|, where U and L are the objective function value of the incumbent and the lower bound (if minimizing, otherwise upper bound) on the optimal value, respectively, for the optimization problem at the current iteration. | 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 solutions1: 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 functionsNOuter1 must be ≥ 0. | 4 |
| NoutIter | Number of rounds of cutting plane generation at node relaxationNOutIter must be a ≥ 0. | 4 |
| NoutPerVar | Number of outer approximations per variable for convex multivariate functionsNOutPerVar 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. GAMS option threads set to 0 corresponds to Threads=1.Range: { 1, ..., ∞} | GAMS Threads |
Range reduction options
Tree management options
Local search options
| Option | Description | Default |
|---|---|---|
| DoLocal | Local search option for upper bounding0: no local search is done during upper bounding1: 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 |
|---|---|---|
| AllowCbc | Indicator for use of CLP/CBC with automatic LP/MIP/QP solver selection | 1 |
| AllowCplex | Indicator for use of CPLEX with automatic LP/MIP/QP solver selection | 1 |
| 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 search1: 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 search1: 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 search1: consider FILTERSQP for local search | 1 |
| AllowHsl | Indicator for use of HSL LA04 with automatic LP solver selection | 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. 0: do not use IPOPT for local search1: consider IPOPT for local search | 0 on macOS/ARM64, 1 otherwise |
| 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 search1: 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 search1: consider SNOPT for local search | 1 |
| AllowXpress | Indicator for use of FICO XPRESS with automatic LP/MIP/QP solver selection | 0 on macOS/ARM64, 1 otherwise |
| 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 algorithm1: primal simplex2: dual simplex3: barrier | 0 |
| LPSol | Specifies the LP/MIP/QP 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/MIP/QP solver selection and switching strategy3: CPLEX7: XPRESS8: CLP/CBC15: 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 strategy0: Local search based on function evaluations alone with no calls to local solvers2: MINOS4: SNOPT6: GAMS NLP solver (see ExtNLPsolver)9: IPOPT10: FILTERSD14: 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 IIS1: the search for an IIS is based on a fast heuristic2: an IIS is obtained using a deletion filtering algorithm3: an IIS is obtained using an addition filtering algorithm4: an IIS is obtained using an addition-deletion filtering algorithm5: 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 correct1: 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 CompIIS1: arrange constraints in problem order2: arrange constraints in ascending order of degree3: arrange constraints in descending order of degree>3: random order using IISorder as seed | -1 |
| seed | Initial seed for random number generator Changing the value of this option is likely to change the outcome of BARON's randomized search steps, including starting points and solutions obtained from local search heuristics. Range: { 1, ..., ∞} | 19631963 |
| WantDual | whether to try to provide dual solution values0: 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 for LP, 0 otherwise |
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 GAMSwall: 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. | |
| InfBnd | infinity value to be used on bounds If set to 0, then no bounds are used. | 0 |