Readers who want to solve a model immediately should begin with Section 2, which covers installation, and then Section 3 (quickstart), which provides a quickstart example using the command line and from several modeling systems. Section 4 explains the problem classes for which BARON is appropriate and the model characteristics that affect difficulty. Section 5 describes the algorithm and provides the background needed to interpret the option tables. Sections 6–8 cover model requirements, reformulations, and the BARON input language.

Sections 9–10 describe output files and BARON’s principal features. Section 11 is the option reference, Section 12 lists termination codes, and Section 13 provides troubleshooting guidance organized by symptom. Appendix A contains an alphabetical index of all options.

A free version of BARON is available from http://www.minlp.com/download. Without a license, BARON can solve problems with up to 10 variables, 10 constraints, and 50 nonlinear operations. Larger problems require a valid BARON license.

The Optimization Firm provides licenses for running BARON directly on any Windows, Linux, and macOS, as well as through JuMP, MATLAB, Oximo (Rust), Pyomo, and YALMIP. BARON distributors AIMMS, AMPL, and GAMS also provide licenses for use within their modeling systems.

BARON includes CLP/CBC [7], HiGHS [19], FilterSD [8], FilterSQP [40], and IPOPT [55] for solving linear, mixed integer, quadratic, and nonlinear (NLP) subproblems. It also includes numerical software from HSL, a collection of Fortran codes for large-scale scientific computation; see http://www.hsl.rl.ac.uk.

If IBM ILOG CPLEX [20] is installed as a dynamic library, BARON can use it to solve LP, MIP, and QP subproblems. The AIMMS, AMPL, and GAMS versions of BARON can also use additional licensed solvers. XPRESS [13] may be used for LP and MIP subproblems, while available NLP solvers include CONOPT [9], MINOS [33], SNOPT [16] and KNITRO [6], among others. These solvers may improve performance on some problems.

1. 1.

   Go to http://minlp.com/baron-downloads and download BARON for your platform.

   On Windows, baron-win64.exe is an installer. Run it to install the BARON executable. On other platforms, unzip the downloaded archive to obtain the executable.

2. 2.

   Place the BARON license file, executable, and any distributed dynamic libraries in a directory included in your system PATH.

3. 3.

   See Section 3 for instructions on running BARON from the command line.

For a silent installation on Windows, run:

baron-win64.exe /SILENT

To create an installation log, run:

baron-win64.exe /SILENT /LOG=filename

where $\mathrm{𝚏𝚒𝚕𝚎𝚗𝚊𝚖𝚎}$ is the desired log-file name. Windows will still request permission to run the executable before launching the silent installer.

1. 1.

   Go to http://minlp.com/baron-downloads and download BARON for your platform.

   On Windows, run the baron-win64.exe installer. On other platforms, unzip the downloaded archive.

2. 2.

   Place the BARON license file, executable and any distributed dynamic libraries in a directory included in your system PATH.

3. 3.

   Consult the documentation for your modeling system for instructions on calling BARON. For Pyomo, see http://www.pyomo.org/workshop-examples/. For JuMP, see
   https://jump.readthedocs.io/en/latest/quickstart.html. In YALMIP, select BARON by passing sdpsettings(’solver’,’baron’) to optimize.

   Section 3.3 provides a minimal example for each interface.

1. 1.

   Download the MATLAB/BARON interface from
   http://minlp.com/downloads/matbar/matbar.zip

2. 2.

   Unzip and place the contents of matbar.zip in a location of your choice. This creates a directory named matbar.

3. 3.

   Go to http://minlp.com/baron-downloads and download BARON for your platform.

4. 4.

   Place the BARON executable in the matbar directory. Name it barin.exe on Windows and barin on all other platforms. Place any distributed dynamic libraries in the same directory.

5. 5.

   Add the matbar directory to your system PATH. Adding it only to the MATLAB path may not be sufficient.

6. 6.

   Place the BARON license file in a directory included in your system PATH, such as the matbar directory.

7. 7.

   From MATLAB, run BARON_install

8. 8.

   Consult the Help directory included with the MATLAB/BARON interface for the interface and solver manuals.

Oximo is an algebraic modeling library for Rust; see https://oximo.dev.

1. 1.

   Go to http://minlp.com/baron-downloads and download and install BARON for your platform.

2. 2.

   Place the BARON license file, executable, and any distributed dynamic libraries distributed with it somewhere in a directory included in your system PATH.

   Alternatively, specify the BARON executable directly in Oximo using the baron_path option or: Baron::with_exec("/path/to/baron").

3. 3.

   Add the oximo crate to Cargo.toml with the baron feature enabled:

   [dependencies]
   oximo = { version = "0.5.1", features = ["baron"] }
   

   Section 3.3 provides a minimal example.

To use CPLEX with BARON, install CPLEX for your platform and use BARON’s CplexLibName option to specify the location of the CPLEX dynamic library.

CPLEX libraries may be installed by downloading GAMS, AIMMS or AMPL, or obtained directly from IBM; see https://www.ibm.com/products/ilog-cplex-optimization-studio.

Academic users may be eligible for free CPLEX licenses through the IBM Academic Initiative. Visit http://ibm.biz/CPLEXonAI and register with an academic email address to verify eligibility. Once approved, download the appropriate version for Windows, Linux, or MacOS) through IBM’s academic software portal.

The CPLEX version used by BARON is independent of any CPLEX version used by MATLAB or another modeling system. We recommend using the most recent version available for your platform.

This section solves a small nonconvex nonlinear program (NLP) from the command line and from several modeling systems. The model is

Both constraints are nonconvex, the feasible region has several disconnected components, and the model has multiple local minima. A local NLP solver may return different solutions depending on its starting point. BARON instead identifies the global minimum, near $x_1\approx 2.33$, $x_2\approx 3.18$, with an objective value near $-5.51$.

The model is small enough to solve with the free version of BARON described in (Section 1.2), so no license is required to reproduce the example.

Save the following model in a file named quick.bar:

// A small nonconvex NLP with several local minima.

POSITIVE_VARIABLES x1, x2;

UPPER_BOUNDS{
x1: 3;
x2: 4;
}

EQUATIONS e1, e2;

e1: x2 - 2*x1^4 + 8*x1^3 - 8*x1^2 <= 2;
e2: x2 - 4*x1^4 + 32*x1^3 - 88*x1^2 + 96*x1 <= 36;

OBJ: minimize -x1 - x2;

Then run

baron quick

BARON parses the model, solves it, reports progress to screen, and writes the res.lst, sum.lst, and tim.lst files described in Section 9. The final screen output reports the best solution found, the bound establishing global optimality, and the termination status. Variable values are reported in res.lst.

Two BARON input conventions are particularly important. First, variables may appear only on the left-hand side of a relational operator, which is why the constants 2 and 36 have been appear on the right. Second, variables should have finite bounds whenever possible; finite bounds are often necessary for convergence. Sections Section 6.2 discusses those requirements in more detail

The same model is shown below in GAMS [4], AMPL [14], AIMMS [1], Pyomo [17], JuMP [10], MATLAB [52], YALMIP [21], and Oximo. GAMS, AMPL, and AIMMS distribute BARON directly and therefore do not require a separate BARON installation. The remaining interfaces call a separately installed BARON executable.

Section 9 explains BARON’s screen log and output files. If a run reports missing bounds, terminates because of a limit, or returns a solution that appears incorrect, consult the troubleshooting guide in Section 13.

Additional examples are available at http://www.minlp.com/download. Larger collections of NLP and MINLP test problems are available from The Optimization Firm [53] and from MINLPLib [5].

Model size alone, measured by the number of variables and constraints, is a poor predictor of difficulty. The following characteristics matter far more.

• •

  Tightness of variable bounds. Relaxation quality depends directly on the ranges of variables that appear in nonlinear terms. Tight bounds based on physical or problem-specific knowledge are often more valuable than any algorithmic option in this manual. Bounds set to extremely large values, such as $\pm {10}^{10}$, merely “to be safe,” are a common cause of slow convergence.

• •

  Number and type of nonconvex terms. A model with thousands of variables but only a few bilinear terms may be easier than one with 50 variables that interact nonlinearly throughout. Bilinear, trilinear, and fractional terms are particularly expensive when the participating variables have wide ranges.

• •

  Scaling. Coefficients that span many orders of magnitude can degrade both LP subproblems and feasibility calculations. Rescaling variables so that their ranges are comparable is usually beneficial [11].

• •

  Degeneracy of the optimal value. Models with many solutions of nearly identical objective value may require BARON to explore many nodes before closing the optimality gap. A modest relative tolerance (EpsR) or a Target value can sometimes turn a difficult run into a much faster one.

• •

  Redundant but valid constraints. Constraints implied by the original model can still strengthen its relaxation. Examples include problem-specific optimality conditions or products of important existing constraints. Such additions can produce order-of-magnitude improvements [46, 44] and should be declared using BARON’s RELAXATION _ONLY _EQUATIONS facility (Section 10.2).

• •

  Known convex constraints. Declaring convex constraints with CONVEX_EQUATIONS allows BARON to outer-approximate them rather than relax them term by term. This can produce tighter relaxations at lower computational cost (Section 10.2).

BARON searches a tree of subproblems. At each node, it operates over a box of variable bounds and performs three main tasks. First, it relaxes the model to obtain a valid lower bound on the best objective value attainable within the box. Second, it reduces the box by eliminating parts that provably contain no improving feasible solution. Third, if the box cannot be eliminated, BARON branches, by splitting it into smaller boxes and repeating the process.

A separate upper-bounding process generates feasible solutions. These are what the reduction step uses to prune. The search terminates when the best lower bound over all open nodes and the value of the best feasible solution agree within the absolute or relative optimality tolerances EpsA and EpsR.

What distinguishes branch-and-reduce [41, 42] from plain spatial branch-and-bound is the aggressive use of range reduction. BARON applies several independent reduction mechanisms at every node. These reductions help keep the search tree small. BARON further distinguishes itself through the quality and sophistication of its relaxations, upper-bounding heuristics, and tree-management techniques.

BARON first decomposes each nonlinear model expression into a sequence of elementary operations and introduces an auxiliary variable for each intermediate result [31, 32]. Elementary operations such as products, quotients, powers, exponentials, and logarithms have known convex envelopes. BARON composes these estimators to construct a convex relaxation of the full model, then further outer-approximates that relaxation with linear inequalities so that the node subproblem is an LP, or a MIP when integer variables are present [51, 25].

BARON also exploits structure beyond individual elementary operations. It recognizes multilinear, bilinear, and polynomial substructures, convex-transformable intermediate expressions, and quadratic forms, for which stronger relaxations are available [43, 48, 3, 23, 24, 59, 22, 60, 2, 36, 34, 35].

Two consequences of this construction are especially important for users.

First, the quality of each estimator depends on the bounds of the variables entering the corresponding elementary operation, including auxiliary variables introduced for intermediate expressions. Bounds on the original user model variables alone may therefore be insufficient. Section 6.2 discusses this issue in detail.

Second, a relaxation is typically tight at the ends of a box, especially in one dimension, while a gap remains in the interior. That gap narrows as the box shrinks. Figure 1 illustrates why branching is effective: splitting the domain adds a point of agreement at the branching point and gives each sub-box a relaxation that hugs the function more closely, thereby improving the lower bound.

The options NOuter1, NOutPerVar, NOutIter, and OutGrid control how finely BARON outer-approximates the convex relaxation with linear cuts. The options LPSol, LPAlg, and the Allow* options control which solver processes the resulting LP or MIP.

Once a feasible solution with objective value $U$ is known, any part of the search space that cannot contain a better solution than $U$ may be discarded. BARON uses this principle not only to fathom entire nodes, but also to shrink the box at nodes that survive. This is the “reduce” step in branch-and-reduce [42, 39]. Figure 2 illustrates the effect.

BARON applies several range-reduction mechanisms, each controlled by its own option:

• •

  Linear feasibility-based tightening (LBTTDo), sometimes called poor man’s LPs. For each variable, BARON uses the linear constraints of the relaxation to derive the tightest bounds consistent with feasibility, at substantially lower cost than solving a separate LP for every variable bound.

• •

  Nonlinear feasibility-based tightening (TDo). BARON applies the same principle to nonlinear constraints by propagating bounds through the factorable decomposition described in Section 5.2 [45, 39].

• •

  Marginals-based reduction (MDo). The dual solution of the node relaxation assigns reduced costs to active variable bounds. When a bound has a sufficiently large reduced cost, duality can show that moving the variable beyond a certain point would raise the relaxation value above the incumbent $U$. BARON can then discard that portion of the variable range. This reduction adds little computational cost.

• •

  Optimality-based tightening (OBTTDo) and probing (PDo). BARON solves auxiliary optimization problems to derive the strongest possible bounds [37, 57, 50]. These procedures, especially probing, can be expensive. BARON therefore determines automatically how much probing is worthwhile; setting PDo$=-2$ leaves this decision to BARON.

Because several of these mechanisms rely on the incumbent value $U$, they become much more effective once a good feasible solution is available. This is one reason BARON invests in local search before and during the tree search (Section 5.5). It also explains why a good starting point or a useful CutOff value can substantially reduce solution time.

When a node survives reduction, BARON selects a variable on which to branch and a point at which to split its range [50]. The BrVarStra option selects among a dynamic strategy that adapts to observed performance, the largest-violation rule, and the longest-edge rule. The BrPtStra chooses the split point. Users can override variable selection through the BRANCHING_PRIORITIES section of the input file (Section 8.4); assigning a priority of zero prevents branching from branching on that variable. The NodeSel option determines which open node BARON processes next, allowing a tradeoff between bound improvement (best bound) and limiting memory use or finding incumbents through LIFO selection.

BARON obtains feasible solutions from four sources: a user-supplied starting point, if provided; solutions obtained by BARON’s relaxations that are feasible to the original problem; a randomized multistart local search performed during preprocessing, controlled by NumLoc; and local searches launched at nodes during the tree search, controlled by DoLocal. The NLP subsolver used for these searches is selected by NLPSol or, by default, chosen automatically and adaptively by BARON.

BARON does not require a feasible starting point. The problem functions need not be evaluable at the supplied point. See Section 10.1.

Several BARON options are expressed in work units rather than seconds. A work unit is an internal, deterministic measure of computational effort that accumulates as BARON constructs relaxations, solves subproblems, performs range reduction, and processes nodes. Unlike elapsed time, work units do not depend on machine speed or system load. Two runs of the same model with the same options and BARON executable therefore consume the same number of work units at every corresponding point of the search.

Wall-clock and CPU seconds do not provide the same reproducibility. A run terminated by MaxTime may stop at a different node on a loaded machine than on an idle one, and may therefore return a different result [29]. Similarly, a log printed every PrTimeFreq seconds is not identical across runs. The corresponding work-unit options avoid these problems:

• •

  MaxWork limits total search effort deterministically, and is the reproducible counterpart of MaxTime. A run stopped by MaxWork stops at exactly the same point on every machine.

• •

  PrWorkFreq controls log output according to work units consumed rather than seconds elapsed, so two runs of the same model produce identical logs. When PrWorkFreq is nonzero, BARON ignores PrTimeFreq.

• •

  DeltaTerm, with DeltaT, DeltaA, and DeltaR, terminates the search when progress over a specified window of work units is insufficient. Because the window is measured in work units, the resulting heuristic termination point is reproducible (Section 10.5).

Two caveats apply. First, the seed option initializes BARON’s random number generator, which affects the selection of starting points for local searches; changing the seed changes the search path, although not the validity of the result. Second, when threads is greater than 1, reproducibility additionally also depends on the determinism of the parallel MIP subsolver [58]. For fully reproducible results, set threads to 1, fix seed, and use MaxWork rather than MaxTime.

Under the assumptions of Section 6, particularly finite bounds on all nonlinear expressions, BARON’s algorithm converges to a global optimum [42, 50, 49]. The lower bounds generated during the search converge to the global optimal value, and the search terminates finitely at any positive tolerance. Finite termination is also guaranteed for problems in which all nonconvexities involve discrete variables or products of discrete and bounded continuous variables [27].

When bounds on nonlinear expressions are missing, BARON may be unable to construct valid relaxations. BARON detects this condition and warns explicitly that global optimality is not guaranteed (Section 13.1).

In addition to multiplication and division, BARON supports nonlinear expressions involving $\exp (x)$, $\ln (x)$, $x^{\alpha }$ for real $\alpha$, and ${\beta }^x$ for real $\beta$. AIMMS/BARON, AMPL/BARON, GAMS/BARON, and Oximo/BARON also handle $|x|$ and $x^y$, where $x$ and $y$ are variables automatically. For other BARON interfaces, the transformations in Section 7 can be used. Other functions, including trigonometric functions such as $\sin (x)$, $\cos (x)$, are not currently supported.

Nonlinear expressions in the model must have the finite bounds required to construct valid relaxations. Users should therefore provide finite lower and upper bounds for as many problem variables as possible.

Finite variable bounds alone, however, do not guarantee finite bounds on every nonlinear expression. Consider $1/x$ with $x\in [0,1]$; the variable is bounded, but the expression is not. Because BARON relaxes the model through intermediate quantities introduced by the factorable decomposition described in (Section 5.2), bounds on these intermediate quantities determine whether valid relaxations can be constructed.

Several common expressions can produce unbounded or undefined intermediate quantities even when all declared variable are bounded:

• •

  Division by an expression that can reach or approach zero. Expressions such as $1/x$, $y/x$, and $x^{-2}$ require $|x|$ to be positive. If the model implies, for example, $x\ge {10}^{-3}$, declare that bound explicitly.

• •

  Logarithms of expressions that can reach zero. An expression such as $\log (x)$ requires a strictly positive lower bound on $x$.

• •

  Fractional or negative powers. An expression such as $x^{0.5}$ requires $x\ge 0$, while $x^{-1.5}$ requires $x$ to remain within its valid domain and be bounded away from zero.

Variable bounds should therefore ensure that all problem functions remain finitely valued over the domain of interest. When the model does not provide sufficient bounds, BARON attempts to infer them from problem constraints. If it cannot establish the bounds needed for valid relaxations, BARON cannot guarantee global optimality and states this explicitly in its termination message. Section 13.1 provides a small example of how to diagnose and repair such a model.

• •

  Base-10 logarithm. Use ${\log }_{10}(x)={\log }_{10}(\mathrm{e})\cdot \log (x)=0.4342944819032518\cdot \log (x)$.

• •

  Variable raised to a variable power. BARON does not directly accept $x^y$ when both $x$ and $y$ variables. Use $x^y=\exp (y\cdot \log (x))$, which requires $x$ to be bounded away from zero. This reformulation is performed automatically when BARON is used under AIMMS, AMPL, GAMS, MATLAB, Oximo, or YALMIP.

• •

  Absolute value. BARON does not accept $|x|$. Use $|x|={(x^2)}^{0.5}$. AIMMS, AMPL, GAMS, MATLAB, Oximo, or YALMIP perform this reformulation automatically when used with BARON. If $x$ is known to be nonnegative, the absolute value is not needed; introducing one would add unnecessary nonlinearity.

• •

  Maximum and minimum. To model $t=\max (x,y)$, introduce a binary variable $\delta$ and a finite bound $M$ on the deviation: $t\ge x$, $t\ge y$, $t\le x+M\delta$, $t\le y+M(1-\delta )$. Model $\min$ symmetrically. If the model only requires $t\ge \max (x,y)$, the first two inequalities alone suffice and no binary is needed. Use this simpler formulation whenever it captures the required relationship.

• •

  Piecewise-linear functions. Use standard SOS2 or incremental formulations with binaries. When a modeling system offers a native piecewise-linear construct, prefer it: the formulation it generates is usually tighter than a hand-written one.

• •

  Trigonometric functions. These functions are not supported. Models that are periodic in an angle can sometimes be reformulated in terms of $s=\sin \theta$ and $c=\cos \theta$ with the constraint $s^2+c^2=1$, which BARON handles.

• •

  Tighten bounds before BARON has to. Any bound the modeler can justify is more valuable than the same bound derived at run time because it is available at the root node and in every relaxation thereafter.

• •

  Declare convex constraints. CONVEX_EQUATIONS lets BARON outer-approximate a constraint directly rather than relax it term by term.

• •

  Break symmetry. Models whose variables are interchangeable, for example assignments of identical units to identical tasks, force the search to prove optimality once per permutation. Ordering constraints that select one representative of each symmetric class often shrink the tree by orders of magnitude [47, 28].

• •

  Avoid gratuitous nonlinearity. $x/y\le c$ with $y>0$ should be written $x\le cy$. ${(x^2)}^{0.5}$ should not be introduced when $x\ge 0$. Every nonlinear operation removed is one that need not be transformed, relaxed, or branched on.

• •

  Add valid redundant constraints as relaxation-only. Products of pairs of important problem constraints and problem-specific optimality conditions can substantially tighten the relaxation. Declare them with RELAXATION_ONLY_EQUATIONS so that they strengthen the bound without being used for feasibility testing or local search (Section 10.2).

The power operator is right-associative in BARON, as it is in Fortran, AMPL, and Mathematica, and left-associative in GAMS, MATLAB, and Excel:

• $x\mathrm{^}y\mathrm{^}z=(x\mathrm{^}y)\mathrm{^}z$ in GAMS, MATLAB, and Excel;

• $x\mathrm{^}y\mathrm{^}z=x\mathrm{^}(y\mathrm{^}z)$ in Fortran, AMPL, BARON, and Mathematica.

Models ported between systems should parenthesize such expressions explicitly.

A unary operator following an arithmetic operator is rejected by some compilers and accepted by others. BARON permits such expressions and assumes parentheses following the arithmetic operator through the end of the expression:

Here, too, explicit parentheses are strongly recommended.

BARON provides a high-level modeling language for specifying mixed-integer nonlinear optimization model in a relatively simple format. Users provide the mode in a text file. Although not required, we strongly recommend using the extension .bar for all BARON input files. Suppose the input file is called test.bar and the BARON executable is named baron. Then either command

baron test

or

baron test.bar

causes BARON to parse the file and solve the problem.

Follow these rules when preparing a BARON input file:

• •

  All statements should be terminated by a semicolon (;).

• •

  Reserved words must appear in uppercase letters.

• •

  Variable and equation names may use lower or upper case letters. The parser is case sensitive; i.e., X1 and x1 are two different variables. Option names, however, are not case-sensitive.

• •

  Variable and equation names should be no longer than 128 characters.

• •

  Variable and equation names must start with a letter.

• •

  String options should be no longer than 250 characters.

• •

  Except for underscores (_), do not use non-alphanumeric characters such as hyphens (-) in variable names.

• •

  Any text between // and the end of a line is ignored (i.e., it is treated as a comment).

• •

  The signs “+”, “-”, “*” and “/” have their usual meaning of arithmetic operations.

• •

  “^” is the power/exponentiation operator. If the base is a negative constant, the exponent must be an integer. See Section 7 for its associativity and the treatment of unary operators.

• •

  The exponential function is denoted as $\exp ()$.

• •

  The natural logarithm is available as $\log ()$ as well as $\ln ()$.

• •

  Parentheses (“(” and “)”) may be used in any meaningful combination with operations in mathematical expressions.

• •

  Constraints must contain at least one expression that does not evaluate to a constant.

• •

  Variables must appear on only one side of the relational operator. That is, the “left-hand side” and the “right-hand side” should be pure numbers or expressions involving constants but no variables.

The input file is divided into two sections: options and problem data.

This section is optional. If used, place it before any other programmatic statements. You may specify any of BARON’s algorithmic options here. The section has the following form:

OPTIONS {
<optname1>: <optvalue1>;
<optname2>: <optvalue2>;
<optname3>: <optvalue3>;
}

Section 11 describes the option names and their corresponding values in detail. Options not specified here use their default values. You may use OPTION instead of OPTIONS.

This section contains the data for the problem to be solved. It consists of the following parts, where the description uses the terms equations, rows, and constraints interchangeably.

• •

  Variable declaration: Declare all variables before using them in the input file. Use the keywords BINARY_VARIABLES, INTEGER_VARIABLES, POSITIVE_VARIABLES, and VARIABLES to declare binary, integer, positive, and free variables, respectively. In these keywords, you may use VARIABLE or VAR instead of VARIABLES, and replace the underscore with a space. Declare all discrete (binary and integer) variables before any continuous variables. For example:

  BINARY_VARIABLES y1, y2;        // 0-1 variables
  INTEGER_VARIABLES x3, x7;       // discrete variables
  POSITIVE_VARIABLES x1, x4, x6;  // nonnegative variables
  VARIABLE x5;                    // this is a free variable
  

• •

  Variable bounds (optional but strongly recommended; see Section 6.2): Declare variable lower and upper bounds using the keywords LOWER_BOUNDS and UPPER_BOUNDS, respectively. You may use BOUND instead of BOUNDS. For example:

  LOWER_BOUNDS{
  x7: 10;
  x5: -300;
  }
  
  UPPER_BOUND{
  x4: 100;
  }
  

• •

  Branching priorities (optional): Specify branching priorities using the keyword BRANCHING_PRIORITIES. The default priority for each variable is 1. BARON multiplies variable violations by the user-provided priorities before selecting a branching variable. For example:

  BRANCHING_PRIORITIES{
  x3: 10;
  x5: 0; }
  

  This input gives variable x3 higher priority than all others, while BARON will never branch on variable x5. Setting a branching priority to zero can harm BARON’s performance and is not recommended.

• •

  Equation declaration: Declare an identifier (name) for each equation (constraint) before using it. Use the keywords EQUATION and EQUATIONS. For example:

  EQUATIONS e1, e2, e3;
  

  Equation names follow the same naming rules as variable names; i.e., they are case-sensitive and must begin with a letter.

• •

  RELAXATION_ONLY_EQUATIONS <list equation names>;
  

  This optional declaration identifies constraints used only to construct relaxations. It must follow the EQUATIONS declaration and precede the equation definitions. See Section 10.2.

• •

  CONVEX_EQUATIONS <list equation names>;
  

  This optional declaration specifies constraints that are convex. It imust follow the EQUATIONS declaration and precede the equation definitions. See Section 10.2.

• •

  Equation definition: Define each equation (or inequality) declared above by preceding it with its corresponding identifier. Use == (equal to), <= (less than or equal to), or >= (greater than or equal to). You may use both <= and >= in the same equation. For example:

  e1: 5*x3 + y2 - 3*x5^3 >= 1;
  e2: y1 + 2*x4 - 2*x7 == 25.7;
  e3: -20 <= x4 + 2*y1*x3 + x6 <= 50;
  

• •

  Objective function: BARON optimizes a specified objective function. Users can declare it using the OBJ keyword together with minimize or maximize. For example:

  OBJ: minimize 7*x3 + 2*x6;
  

• •

  Starting point (optional): Specify a starting point using the keyword STARTING_POINT as follows:

  STARTING_POINT{
  x1: 50;
  x4: 100;
  x7: 300;
  }
  

Any errors in the input file are “warnings” or “errors.” BARON attempts to continue execution after warnings. If a warning or error is severe, BARON stops execution and reports the line where the fatal error occurred. Users should review all warnings, even nonfatal ones, because BARON may have parsed the model differently than intended.

A sample input file for BARON is shown below:

//  This gear train design problem is taken from the GAMS test library
//
//  The goal is to design a compound gear train that achieves a specific
//  gear ratio between the driver and driven shafts. The objective
//  is to determine the number of teeth on the four gears to obtain
//  a required gear ratio of 1/6.931.
//
//  The problem originated from:
//  Deb, K, and Goyal, M, Optimizing Engineering Designs Using a
//  Combined Genetic Search. In Back, T, Ed, Proceedings of the
//  Seventh International Conference on Genetic Algorithms. 1997,
//  pp. 521-528.

INTEGER_VARIABLES  i1,i2,i3,i4;   // number of teeth in each of the gears

LOWER_BOUNDS{
i1: 12;
i2: 12;
i3: 12;
i4: 12;
}

UPPER_BOUNDS{
i1: 60;
i2: 60;
i3: 60;
i4: 60;
}

EQUATIONS  e2,e3;                       // symmetry constraints

e2:  - i3 + i4 >= 0;
e3:    i1 - i2 >= 0;

// The objective is to make the reciprocal of the gear ratio
// as close to 6.931 as possible. An ideal design will have an
// objective equal to 1.

OBJ: minimize (6.931 - i1*i2/(i3*i4))^2 + 1;

STARTING_POINT{
i1: 24;
i2: 24;
i3: 24;
i4: 24;
}

Additional examples can be found at http://www.minlp.com/download.

The screen output below is obtained for the MINLP model gear.bar.

===========================================================================
 BARON version 26.9.10. Built: WIN-64 2026-09-10 18:07:59
 Running on machine PONTIOS

 BARON is a product of The Optimization Firm. For more information and
 related optimization and data analytics products visit https://minlp.com.

 License file baronlice.txt is not valid for this version of BARON.
 Continuing in free version mode.
 Model size is allowable within free BARON size.

 If you publish work using this software, please cite publications from
 https://minlp.com/baron-publications, such as:

 Zhang, Y. and N. V. Sahinidis, Solving continuous and discrete
 nonlinear programs with BARON, Comput Optim Appl, 92, 1123-1161, 2025.
 https://doi.org/10.1007/s10589-024-00633-0
===========================================================================
 This BARON run may utilize the following subsolver(s)
 For LP/MIP/QP: CLP/CBC, HiGHS, ILOG CPLEX
 For 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 20.3805
 Preprocessing found feasible solution with value 1.04488
 Done with local search
===========================================================================
    Iter       WUs  Time (s)     Mem  Lower bound  Upper bound Progress
*      1      0.03      0.12    19MB       1.0000       1.0012   79.30%
       1      0.05      0.17    19MB       1.0000       1.0012   79.30%
*      3      0.06      0.22    19MB       1.0000       1.0002   87.41%
*      4      0.07      0.23    19MB       1.0000       1.0001   91.95%
*     11      0.10      0.33    77MB       1.0000       1.0000   99.99%
*     28      0.14      0.47    77MB       1.0000       1.0000   99.99%
      28      0.14      0.47    77MB       1.0000       1.0000  100.00%

                         *** Normal completion ***

 Wall clock time:                     0.46
 Total CPU time used:                 0.47
 Total deterministic work units:      0.14

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

 All done
===========================================================================
 Unable to find/load CPLEX library cplex2212.dll.
 Using CPLEX library cplex2211.dll.

BARON first tests the feasibility of the user-supplied starting point. If this point is feasible, BARON reports this along with the corresponding objective function value; if it is infeasible, BARON prints no related message. BARON then performs a randomized local search. Whenever it finds an improved solution, BARON reports the new objective function value.

BARON then begins branch-and-bound. BARON prints log lines periodically according to three options: every PrFreq branch-and-bound iterations, and in addition, either every PrWorkFreq work units or, if PrWorkFreq is zero, every PrTimeFreq seconds. Because reporting by work units is deterministic and reporting by elapsed time is not (Section 5.6), two runs of the same model produce identical logs under the default settings. BARON also prints information whenever the incumbent improves by at least ${10}^{-5}$ and at the end of the search. During branch-and-bound, a star (*) in the first position of a line indicates that BARON found a feasible solution that improves the previous incumbent by at least ${10}^{-5}$.

The log output fields are summarized below.

After searching the branch-and-reduce tree, BARON isolates the best solution and calculates a corresponding dual solution. It then reports the total number of branch-and-reduce iterations (search tree nodes), followed by the node where it identified the best solution (a -1 indicates preprocessing, as explained in Section 9.2).

Upon normal termination, BARON reports the node where it found the optimal solution. We refer to this node as nodeopt. The log message has the following form:

  Best solution found at node:  (nodeopt)

where nodeopt can take the following values:

When BARON runs with AIMMS, AMPL, GAMS, JuMP, MATLAB, Oximo, Pyomo, or YALMIP, the corresponding interface imports BARON results directly into the modeling environment. Users of these systems can skip this section. When running BARON alone, users can read the solution from three output files:

• •

  The results file contains the solutions found by BARON. BARON writes each solution to this file as soon as it finds them. Variable values and dual values for variables and constraints appear in the order in which they are defined in the BARON file. At the end of this file, BARON prints a termination message, such as “*** Normal Completion ***”, followed by the best solution in two formats. The second format uses the variable names from the BARON input file.

• •

  The summary file contains the information printed to the screen. It also reports expressions with missing bounds, if any.

• •

  The time file contains a single line summarizing the solution, including a breakdown of iterations and solution times. The same information appears at the end of the summary file.

As detailed in Section 11, users control whether BARON writes any of these files and can specify their names and paths. File names must be unique for each BARON run in case of parallel runs in the same execution directory.

Unlike many NLP algorithms, BARON does not require a feasible starting point. Users may optionally provide starting points for all or some problem variables, and BARON initializes any remaining variables automatically. Even if BARON cannot evaluate the problem functions at a user-provided starting point, it can still perform its global search.

Two equation declarations let users provide BARON with information about a constraint that it may not infer on its own.

BARON’s NumSol option lets users find the best few, or even all feasible, solutions to a model. The option applies to both combinatorial and continuous problems. For combinatorial problems, BARON does not rely on integer cuts to find multiple solutions. Instead, it uses a single search tree, which provides a computationally efficient way to identify multiple solutions. Because this approach also applies to continuous problems, BARON can find all feasible solutions systems of nonlinear equality and inequality constraints. Using this feature, however, can make the branch-and-bound search much slower than usual.

After solving a model with the NumSol option, users can read the solutions from the BARON results file. To illustrate this feature, consider a problem in kinematic analysis of robot manipulators [54], known as the indirect-position or inverse kinematics problem. Given the desired position and orientation of a robot hand, the problem is to determine the corresponding joint displacements. The example below uses the following system of equations for the PUMA robot:

where

The first four equations are bilinear, while the last four are generalized cylinders. BARON’s method for finding all feasible solutions works well in continuous spaces when the solutions are isolated from one another. The isoltol option (default ${10}^{-4}$) specifies the isolation tolerance used to distinguish among solutions. BARON considers two feasible solution vectors different if at least one coordinate differs by at least isoltol.

The BARON file for the robot problem is as follows:

//  Filename: robot.bar
//
//  Purpose: Find all solutions of the PUMA robot problem
//  L.-W. Tsai and A. P. Morgan, "Solving the kinematics of the
//  most general six- and five-degree-of-freedom manipulators by
//  continuation methods," ASME J. Mech. Transm. Automa. Des.,
//  107, 189-200, 1985.

OPTIONS{
numsol: 20;
}

VARIABLES  x1,x2,x3,x4,x5,x6,x7,x8;

LOWER_BOUNDS{
x1: -1;
x2: -1;
x3: -1;
x4: -1;
x5: -1;
x6: -1;
x7: -1;
x8: -1;
}

UPPER_BOUNDS{
x1: 1;
x2: 1;
x3: 1;
x4: 1;
x5: 1;
x6: 1;
x7: 1;
x8: 1;
}

EQUATIONS  e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13,e14,e15,e16;


e2: 0.004731*x1*x3 - 0.1238*x1 - 0.3578*x2*x3 - 0.001637*x2 - 0.9338*x4 + x7
        <= 0.3571;

e3: 0.1238*x1 - 0.004731*x1*x3 + 0.3578*x2*x3 + 0.001637*x2 + 0.9338*x4 - x7
        <= -0.3571;

e4: 0.2238*x1*x3 + 0.2638*x1 + 0.7623*x2*x3 - 0.07745*x2 - 0.6734*x4 - x7
        <= 0.6022;

e5: (-0.2238*x1*x3) - 0.2638*x1 - 0.7623*x2*x3 + 0.07745*x2 + 0.6734*x4 + x7
        <= -0.6022;

e6: x6*x8 + 0.3578*x1 + 0.004731*x2  <= 0;

e7:  - x6*x8 - 0.3578*x1 - 0.004731*x2  <= 0;

e8:  - 0.7623*x1 + 0.2238*x2 == -0.3461;

e9: x1^2 + x2^2  <= 1;

e10: (-x1^2) - x2^2  <= -1;

e11: x3^2 + x4^2  <= 1;

e12: (-x3^2) - x4^2  <= -1;

e13: x5^2 + x6^2  <= 1;

e14: (-x5^2) - x6^2  <= -1;

e15: x7^2 + x8^2  <= 1;

e16: (-x7^2) - x8^2  <= -1;

OBJ: minimize    0;

The above problem has 14 different solutions. Looking at the BARON results file, these solutions can be found after the “*** Normal Completion ***” message.

To assess the difficulty of a nonlinear program, especially the possibility of multiple local solutions, modelers often perform local searches from multiple randomly generated starting points. BARON’s NumLoc option controls the number of local searches performed during preprocessing. To stop BARON after preprocessing, set MaxIter to 0.

In addition to local search, BARON’s preprocessor performs extensive range reduction. To sample the search space for local minima without range reduction, set the range reduction options TDo, MDo, LBTTDo, and OBTTDo to zero. Leaving these options at their default values, however, increases the likelihood of finding high-quality local optima during preprocessing.

If NumLoc is set to $-1$, BARON performs local searches from randomly generated starting points until it proves global optimality or exhausts the CPU-time or work-unit limits specified by (MaxTime and MaxWork).

For example, consider the following model:

VARIABLES  x1,x2,x3,x4,x5;

EQUATIONS  e1,e2,e3;

e1: x2^2 + x3^2 + x1 == 6.24264068711929;
e2: -x3^2 + x2 + x4 == 0.82842712474619;
e3: x1*x5 == 2;

OBJ: minimize x1^2 + (x1 - x2)^2 + (x2 - x3)^3
             + (x3 - x4)^4 + (x4 - x5)^4;

The options

OPTIONS{
numloc: 1000;
locres: 1;
maxiter: 0;
}

request a thousand local searches, ask that their outcomes be reported, and stop the run at the end of preprocessing. BARON reports:

Local search found the following     7  distinct solution value(s):
597.003735876           123  times
69.6080893018            19  times
50.9718393653           282  times
41.4464884606           108  times
24.9788095391            88  times
24.6573279371           129  times
1.28838290225           251  times

The model has seven local minima spanning more than two orders of magnitude, and the best, $1.28838290225$, was reached from about a quarter of the starting points. The counts are informative in their own right: a value reached from only a handful of starting points lies in a small basin, while a model whose best value is found rarely is one for which a single local search is unlikely to suffice.

It is important to distinguish what such a run does and does not establish. It shows that a feasible point with value $1.28838290225$ exists and suggests that no better one may exist. It does not prove global optimality. Multistart produces no lower bound, so only the branch-and-bound search can provide that guarantee.

Many practical runs do not need a proof of global optimality. They require a good solution and confidence that further search is unlikely to improve it. DeltaTerm provides this. When it is set to 1, BARON monitors the incumbent over a moving window of ${\delta }_t$ work units and stops when improvement over that window falls below both an absolute threshold ${\delta }_a$ and a relative threshold ${\delta }_r$. Because BARON measures the window in work units rather than seconds (Section 5.6), the termination point is deterministic. The same model produces the same answer on every machine.

The default ${\delta }_t=-100$ is a relative specification. BARON sets the window to 100 times the work consumed through the end of root-node processing, allowing the window to adapt to the difficulty of the model rather than fixing it in advance. BARON applies the condition only after preprocessing the root node and only after finding a feasible solution, so DeltaTerm never causes BARON to terminate without a solution.

If BARON declares a problem unbounded, it searchers for and may report a vertex and direction of an unbounded ray. BARON also reports the best solution found. This solution is a feasible point as far along an unbounded ray as possible without causing numerical errors from floating-point arithmetic.

If BARON declares a problem as infeasible, it can identify a subset of the constraints that becomes feasible when any one of them is removed. BARON can compute such an irreducibly inconsistent system (IIS) [38] for all types of problems it handles, including linear and nonlinear, continuous and integer, convex and nonconvex, and problems with complementarity constraints. Use the CompIIS option to identify an IIS.

For example, consider the problem of minimizing the nonconvex function $x_1{x}_3$ over the following nonconvex constrained set:

When this problem is solved with CompIIS equal to 1, BARON provides the following infeasible set in the results file:

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

The IIS consists of the lower bounds on variables $x_1$, $x_2$, and $x_5$, along with the $\le$ part of equality constraint e2. This suggests that constraint e2 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 the problem is known to be infeasible and the user wants to identify an IIS, setting BARON’s NumLoc option to zero may improve performance. This disables BARON’s initial upper bounding search, which performs multiple local searches. Keep DoLocal nonzero to allow local search when BARON solves certain subproblems during IIS detection. Because identifying an IIS requires BARON to disable some presolve facilities, activating IIS detection for a feasible model may significantly degrade performance.

BARON automatically recognizes and exploits complementarity relationships of the form $f(x)g(x)=0$. The functions $f$ and $g$ may be univariate or multivariate, linear or nonlinear, convex or nonconvex, and may involve continuous and/or integer variables, subject to additional model constraints. BARON can also infer complementarity relationships implied by problem constraints and variable bounds. As a result, BARON can solve general mathematical programs with equilibrium constraints (MPECs) [30, 12, 18]. This class of problems includes the classical linear complementarity problem

as well as the more general mixed complementarity problem

BARON automatically recognizes and exploits both problems without requiring users to identify the complementarities explicitly.

For difficult problems with integer variables, BARON often spends most of its time solving MIP relaxations. Parallel solution of these MIP subproblems can therefore improve performance [58]. Thethreads option specifies the number of cores available to BARON’s MIP subsolver. Its default value is 1, which restricts the subsolver to a single core.

The threads option also applies to continuous problems for which BARON may use a MIP relaxation or reformulation. It also applies to BARON’s NLP subsolvers and other aspects of the BARON algorithm.

See Section 5.6 for the interaction between parallelism and reproducibility. Keep in mind that parallelism is often inefficient for most problems. Even highly efficient MILP solvers see diminishing returns as the number of threads increases [58, 15].

These options control how finely BARON’s convex relaxation is outer-approximated by linear inequalities; see Section 5.2. Larger values give tighter node relaxations at the cost of larger LP subproblems.

These options control the four range reduction mechanisms described in Section 5.3. All are enabled by default, and disabling them is rarely advantageous except for diagnostic purposes or when using BARON as a multistart heuristic (Section 10.4).

Per-variable branching priorities are set in the input file through the BRANCHING_PRIORITIES section (Section 8.4).

During run time, BARON utilizes a number of files. The generation of some of them is optional. In all cases, file names can be controlled by the user. File names must be unique for each BARON run in case of parallel runs in the same execute directory. The contents of each file are described in Section 9.3.

These options are used only when a model is, or is suspected to be, infeasible; see Section 10.7.

These options let the modeler communicate structural knowledge that BARON may be unable infer. As with CONVEX_EQUATIONS (Section 10.2), an incorrect assertion may cause BARON to return an incorrect answer without a diagnostic.

Upon termination, BARON issues one of the following statements along with the nodeopt value described in Section 9.2. The corresponding numeric solver status appears in parentheses, is written to the time file, and detailed in Section 12.2.

• $\bullet$

  *** Normal completion *** (status 1). This is the most desirable termination status. The problem has been solved within tolerances in this case. If BARON returns a nodeopt of -3, then no feasible solution exists.

• $\bullet$

  *** Max. allowable work units exceeded *** (status 2). The user will need to increase the maximum number of allowable work units. The BARON option is MaxWork. See Section 5.6.

• $\bullet$

  *** Max. allowable BaR iterations reached *** (status 3). The user will need to increase the maximum number of allowable iterations. The BARON option is MaxIter.

• $\bullet$

  *** Max. allowable time exceeded *** (status 4). The user will need to increase the maximum of allowable time. The BARON option is MaxTime.

• $\bullet$

  *** Problem is numerically sensitive *** (status 5). 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 are nonetheless feasible within numerical tolerances. When BARON returns this message, the “Best possible” reported on the objective is likely correct.

• $\bullet$

  *** Search interrupted by user *** (status 6). The run was interrupted by the user (Ctrl-C). The results file will contain the best primal solution found, though not necessarily a corresponding dual.

• $\bullet$

  *** Insufficient Memory for Data structures *** (status 7). 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.

• $\bullet$

  *** Heuristic termination *** (status 12). 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 (Section 10.5).

• $\bullet$

  *** User did not provide appropriate variable bounds ***. This message does not replace one of the termination messages above; it is printed in addition to whichever one applies, including *** Normal completion ***. When bounds are missing, BARON sets values for them itself so that the search can proceed, and reports both counts after root node processing in the following form (where the number 9 is an example and will vary from problem to problem):

  Number of missing variable or expression bounds =     9
  Number of variable or expression bounds autoset =     9
  

  The run then continues normally and may report a finite lower bound, full progress, and normal completion. None of that constitutes a proof because the relaxations were built over autoset rather than user-supplied ranges. Although BARON prints relaxation bounds on the screen to indicate convergence, these bounds may not be valid for the problem at hand. The BARON summary file identifies variables and expressions with missing bounds. Users should modify the model to provide bounds on variables and intermediate expressions that allow BARON to construct reliable relaxations. The message is accompanied 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.

  Section 13.1 provides a worked example of diagnosing and repairing such a model.

• $\bullet$

  *** A potentially catastrophic access violation just took place. In the unlikely event of an access violation, BARON will terminate the search and return the best known solution. Please report problems that lead to this termination condition to (info@minlp.com).

The eighth field of the time file (Section 9.3.1) carries BARON’s solver status, which can take one of the following values:

1. 1.

   If normal completion occurred, i.e., the problem was solved within tolerances.

2. 2.

   If the maximum allowed number of work units was exceeded (increase maxwork).

3. 3.

   If the maximum allowed number of iterations was exceeded (increase maxiter).

4. 4.

   If the maximum allowed time was exceeded (increase maxtime).

5. 5.

   If the problem is numerically sensitive.

6. 6.

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

7. 7.

   If there was insufficient memory to setup BARON’s data structures (increase physical memory).

8. 8.

   This return code is reserved for development purposes.

9. 9.

   If the run was terminated by BARON.

10. 10.

    If the run was terminated by BARON’s parser because of a syntax error in the BARON input file.

11. 11.

    If the run was terminated because of a licensing error.

12. 12.

    If the heuristic termination rule was invoked by the user.

The ninth field of the time file carries BARON’s model status, which can take one of the following values:

1. 1.

   optimal within tolerances

2. 2.

   infeasible

3. 3.

   unbounded

4. 4.

   intermediate feasible

5. 5.

   unknown

If the model status is 4 or 5, the tenth field of the time file gives the number of missing bounds on variables or expressions that made BARON unable to guarantee global optimality.

This is the most common difficulty for new users. It rarely means that the user overlooked an obvious bound. More often, the constraints imply no such bound, and the user must supply one based on knowledge of the underlying problem. As the example below shows, the bound need not be tight or elaborate. A single finite value on one well-chosen variable is often enough for BARON derive the rest. Consider again the model of Section 10.4:

VARIABLES  x1,x2,x3,x4,x5;

EQUATIONS  e1,e2,e3;

e1: x2^2 + x3^2 + x1 == 6.24264068711929;
e2: -x3^2 + x2 + x4 == 0.82842712474619;
e3: x1*x5 == 2;

OBJ: minimize x1^2 + (x1 - x2)^2 + (x2 - x3)^3
             + (x3 - x4)^4 + (x4 - x5)^4;

Run as it stands, BARON does not stop. It finds the solution, announces that bounds are missing, supplies values for them itself, and completes:

 Doing local search
 Preprocessing found feasible solution with value 24.9788
 Solving bounding LP
 Starting multi-start local search
 Preprocessing found feasible solution with value 1.28838
 Done with local search
========================================================================
    Iter       WUs  Time (s)     Mem  Lower bound  Upper bound Progress
       1      0.02      0.09    13MB    -infinity       1.2884       NA
========================================================================
 User did not provide appropriate variable bounds.
 Some model expressions are unbounded.
 We may not be able to guarantee globality.
 Number of missing variable or expression bounds =     13
 Number of variable or expression bounds autoset =     13
========================================================================
       1      0.03      0.10    13MB      -395.78       1.2884       NA
      17      0.10      0.21    13MB       1.2884       1.2884  100.00%
                         *** Normal completion ***
         *** User did not provide appropriate variable bounds ***
               *** Globality is therefore not guaranteed ***

This is the outcome that requires the most caution. The run reports a normal completion, the bounds meet at $1.2884$, and progress reaches 100%, yet the last line says that globality is not guaranteed. Thirteen bounds were missing, and BARON autoset all 13. The root lower bound of $-395.78$, and every lower bound after it, came from relaxations built over those autoset ranges and therefore need not be valid for the model the user wrote.

The reported value happens to be the global minimum, as the multistart run of Section 10.4 suggests, but this run has not proved it. A user who reads only the normal-completion message and the 100% progress indicator may draw a conclusion that the output does not support.

No variable is bounded, and none can be bounded by propagation through the constraints, primarily due to interactions between unbounded variables in the objective.

However, assigning an upper bound of ${10}^6$ to $x_4$ is enough for BARON to solve the problem:

    Iter       WUs  Time (s)     Mem  Lower bound  Upper bound Progress
       1      0.08      0.20    13MB      -17.800       24.657       NA
*      2      0.10      0.23    13MB      -17.800       1.2884       NA
      19      0.16      0.31    13MB       1.2884       1.2884  100.00%

                         *** Normal completion ***

The warning is gone, and the completion is now a proof. Note what the log shows about the root node: the first relaxation over that loose box gives a lower bound of $-17.8$, yet the search closes the gap in nineteen iterations.

BARON uses $x_4\le {10}^6$ and constraint e2 to derive a lower bound of $x_2$. That floor puts a floor under the one objective term that could go to $-\mathrm{\infty }$, which lets the solver constrain the four even-power terms, and then every remaining variable. The precise value of the bound is almost irrelevant ($30$ works as well as ${10}^6$). What matters is that it is finite and small enough to keep the derived bounds within BARON’s usable range.

Check the termination message (Section 12.1) to identify which limit was reached. The reported solution remains valid. It is a feasible point, and the reported lower bound is a valid bound on the global optimum. The gap between them shows how much remains to prove.

If the gap is small, the practical remedy is usually to loosen EpsR rather than to extend the limit. If the gap is large, extending the limit alone is unlikely to help. See Section 13.3.

For reproducible experiments, users should prefer MaxWork over MaxTime (Section 5.6).

In rough order of expected payoff:

1. 1.

   Tighten variable bounds. See Section 4.1. Nothing else in this list is normally as effective.

2. 2.

   Supply a cutoff or a target. If a good solution is known from any source, pass its value through CutOff; this activates range reduction from the first node. If any solution better than a threshold is acceptable, set Target.

3. 3.

   Rescale. Bring variable ranges and constraint coefficients to comparable magnitudes.

4. 4.

   Declare convex constraints with CONVEX_EQUATIONS, and set ProblemIsConvex if the whole continuous relaxation is convex.

5. 5.

   Break symmetry if the model contains interchangeable entities.

6. 6.

   Add valid redundant constraints as RELAXATION_ONLY_EQUATIONS (Section 10.2).

7. 7.

   Accept a heuristic answer. Set DeltaTerm to 1 to stop when progress stalls (Section 10.5), or loosen EpsR.

8. 8.

   Raise threads but don’t expect miracles from parallelization for NP-hard problems (Section 10.9).

If everything else fails, send us the .bar file with your model. We may be able to identify special structure and improve BARON’s performance for your model.

Verify, in order:

1. 1.

   That the termination message is *** Normal completion *** and not one of the limit or missing-bounds messages. A run stopped on a limit reports the best solution found, not the global optimum.

2. 2.

   That no CutOff was supplied that excludes the true optimum, and no Target caused early termination.

3. 3.

   That no constraint was declared with CONVEX_EQUATIONS that is not convex, that no RELAXATION_ONLY_EQUATIONS constraint is invalid, and that ProblemIsConvex was not asserted incorrectly. These three declarations are believed by BARON without verification, and an incorrect one produces a wrong answer silently.

4. 4.

   That the tolerances EpsA and EpsR are as tight as the application requires. A solution within ${10}^{-6}$ relative tolerance may still differ visibly from the optimum when the objective is large.

5. 5.

   That the model as parsed is the model intended: check the summary file, and check for the precedence pitfalls of Section 7.

If you still believe BARON is making an incorrect optimality claim, send us the .bar file with your model. We may be able to identify a bug or address numerical issues for that type of model.

Use CompIIS to obtain an irreducibly inconsistent system (Section 10.7). The IIS localizes the inconsistency to a small subset of constraints and bounds. An infeasibility report is not reliable if BARON issued the missing-bounds message. In that case, BARON also reports *** Infeasibility is therefore not guaranteed ***.

If you still believe BARON is making an incorrect infeasibility claim, send us the .bar file with your model. We may be able to identify a bug or address numerical issues for that type of model.

See Section 5.6. Set threads to 1, fix seed, replace MaxTime with MaxWork, and leave PrWorkFreq nonzero. Confirm that both runs use the same BARON version and the same subsolvers. For example, a machine with CPLEX installed and one without may select different LP subsolvers under the default LPSol setting.

BARON is compiled conservatively to facilitate reproducibility. However, differences in hardware or operating systems may lead to small differences in round-off processes and therefore different search paths or different solutions. All reported solutions obtained remain valid within the specified termination tolerances.

If you still believe BARON is returning inconsistent solutions, send us the .bar file with your model so that we can investigate possible causes.