### Table of Contents

# Introduction

Artelys Knitro is a software package for finding local solutions of both continuous (i.e. smooth) optimization problems, with or without constraints, and discrete optimization problems with integer or binary variables. Even though Knitro has been designed for solving large-scale general problems, it is efficient for solving all of the following classes of optimization problems:

- unconstrained,
- bound constrained,
- equality constrained,
- systems of nonlinear equations,
- least squares problems,
- linear programming problems (LPs),
- quadratic programming problems (QPs),
- general (inequality) constrained problems,
- (convex) mixed integer nonlinear programs (MINLP) of moderate size.

The Knitro package provides the following features:

- Efficient and robust solution of small or large problems,
- Solvers for both continuous and discrete problems,
- Derivative-free, 1st derivative and 2nd derivative options,
- Both interior-point (barrier) and active-set optimizers,
- Both feasible and infeasible versions,
- Both iterative and direct approaches for computing steps,

The problems solved by Knitro have the form

\[ \begin{array}{rclr} \mbox{minimize} & \qquad \qquad & f(x) & \qquad \qquad \qquad (1a) \\ \mbox{subject to} & \qquad \qquad & c^L \leq c(x) \leq c^U & \qquad \qquad \qquad (1b) \\ & \qquad \qquad & b^L \leq x \leq b^U, & \qquad \qquad \qquad (1c) \end{array} \]

where the variables \(x\) can be continuous, binary, or integer. This allows many forms of constraints, including bounds on the variables. Knitro requires that the functions \(f(x)\) and \(c(x)\) be smooth functions.

Knitro implements both state-of-the-art interior-point and active-set methods for solving nonlinear optimization problems. In the interior method (also known as a barrier method), the nonlinear programming problem is replaced by a series of barrier sub-problems controlled by a barrier parameter \(\mu\). The algorithm uses trust regions and a merit function to promote convergence. The algorithm performs one or more minimization steps on each barrier problem, then decreases the barrier parameter, and repeats the process until the original problem (1) has been solved to the desired accuracy.

Knitro provides two procedures for computing the steps within the interior point approach. In the version known as `Interior/CG`

each step is computed using a projected conjugate gradient iteration. This approach differs from most interior methods proposed in the literature in that it does not compute each step by solving a linear system involving the KKT (or primal-dual) matrix. Instead, it factors a projection matrix, and uses the conjugate gradient method, to approximately minimize a quadratic model of the barrier problem.

The second procedure for computing the steps, which we call `Interior/Direct`

, always attempts to compute a new iterate by solving the primal-dual KKT matrix using direct linear algebra. In the case when this step cannot be guaranteed to be of good quality, or if negative curvature is detected, then the new iterate is computed by the `Interior/CG`

procedure.

`Knitro`

also implements an active-set sequential linear-quadratic programming (SLQP) algorithm which we call `Active`

. This method is similar in nature to a sequential quadratic programming method but uses linear programming sub-problems to estimate the active-set at each iteration. This active-set code may be preferable when a good initial point can be provided, for example, when solving a sequence of related problems.

For problems with discrete variables, Knitro provides two variants of the branch and bound algorithm. The first is a standard implementation, while the second is specialized for convex, mixed-integer nonlinear problems.

*We encourage the user to try all algorithmic options to determine which one is more suitable for the application at hand. For guidance on choosing the best algorithm see section Algorithm Options .*

For a detailed description of the algorithm implemented in `Interior/CG`

see [48] and for the global convergence theory see [49] . The method implemented in `Interior/Direct`

is described in [255] . The `Active`

algorithm is described in [51] and the global convergence theory for this algorithm is in [52] . An important component of Knitro is the HSL routine `MA27`

[121] which is used to solve the linear systems arising at every iteration of the algorithm. In addition, the `Active Set`

algorithm in Knitro may make use of the COIN-OR `Clp`

linear programming solver module. The version used in `Knitro`

may be downloaded from http://www.artelys.com/tools/clp/.

# Usage

Basic details of solver usage, including how to choose Knitro as the solver and how to use a solver-specific option file, are part of Chapter Solver Usage.

As an NLP solver, Knitro can also be used to solve linear programs (LP), and both convex and nonconvex quadratic programs (QCP).

# GAMS Options

The following GAMS options are used by the GAMS/Knitro link:

- Option ResLim = x;
Sets the time limit in seconds. If this limit is exceeded the solver will terminate and pass on the current solution to GAMS. See also reslim in section GAMS options .

- Option SysOut = On;
This option sends additional Knitro messages to the GAMS listing file. It is useful in case of a solver failure or to get algorithmic details. See also sysout in section GAMS options

*ModelName*.optCA = x;Absolute gap stop criterion for a discrete problem. The Knitro option mip_integral_gap_abs takes its default from this value. See also optca in section GAMS options.

*ModelName*.optCR = x;Relative gap stop criterion for a discrete problem. The Knitro option mip_integral_gap_rel takes its default from this value. See also optcr in section GAMS options.

# Summary of Knitro Options

The Knitro options file `knitro.opt`

allows the user to easily set options controlling `Knitro`

's behavior. Options are set by specifying a keyword and a corresponding value on a line in the `knitro.opt`

file. Lines that begin with a `#`

character are treated as comments and blank lines are ignored. For example, to set the maximum allowable number of iterations to 500, one could use the following options file:

## General options

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

algorithm | Indicates which algorithm to use to solve the problem | `0` |

blasoption | Specifies the BLAS/LAPACK function library to use for basic vector and matrix computations | `1` |

blasoptionlib | Specifies a dynamic library name that contains object code for BLAS/LAPACK functions | |

bndrange | Specifies max limits on the magnitude of constraint and variable bounds | `1e+20` |

cg_maxit | Determines the maximum allowable number of inner conjugate gradient (CG) iterations per Knitro minor iteration | `-1` |

cg_pmem | Specifies the amount of nonzero elements per column of the Hessian of the Lagrangian which are retained when computing the incomplete Cholesky preconditioner | `10` |

cg_precond | Specifies whether an incomplete Cholesky preconditioner is applied during CG iterations in barrier algorithms | `0` |

cg_stoptol | Specifies the relative stopping tolerance used for the conjugate gradient (CG) subproblem solves | `0.01` |

convex | Declare the problem as convex by setting to 1 or non-convex by setting to 0 | `-1` |

cpuplatform | This option can be used to specify the target instruction set architecture for the machine on which Knitro is running | `-1` |

datacheck | Specifies whether to perform more extensive data checks to look for errors in the problem input to Knitro (in particular, this option looks for errors in the sparse Jacobian and/or sparse Hessian structure) | `0` |

delta | Specifies the initial trust region radius scaling factor used to determine the initial trust region size | `1` |

honorbnds | Indicates whether or not to enforce satisfaction of simple variable bounds throughout the optimization | `-1` |

initpenalty | Specifies the initial penalty parameter used in the Knitro merit functions | `10` |

linesearch | Indicates which linesearch strategy to use for the Interior/Direct or SQP algorithm to search for a new acceptable iterate | `0` |

linesearch_maxtrials | Indicates the maximum allowable number of trial points during the linesearch of the Interior/Direct or SQP algorithm before treating the linesearch step as a failure and generating a new step | `3` |

linsolver | Indicates which linear solver to use to solve linear systems arising in Knitro algorithms | `0` |

linsolver_ooc | Indicates whether to use Intel MKL PARDISO out-of-core solve of linear systems when linsolver = mklpardiso | `0` |

linsolver_pivottol | Specifies the initial pivot threshold used in factorization routines | `1e-08` |

names | Enable to pass variable and equation names to Knitro | `0` |

newpoint | Specifies additional action to take after every iteration in a solve of a continuous problem | `0` |

objrange | Specifies the extreme limits of the objective function for purposes of determining unboundedness | `1e+20` |

option_file | additional option file name - read only by KNITRO solver lib | |

output_time | print output on where time is used | `0` |

presolve | Determine whether or not to use the Knitro presolver to try to simplify the model by removing variables or constraints | `1` |

presolveop_tighten | Determine whether or not to enable the Knitro presolve operation to tighten variable bounds | `-1` |

presolve_initpt | Control whether the Knitro presolver can shift a user-supplied initial point | `-1` |

presolve_level | Set the level of presolve operations to enable through the Knitro presolver | `-1` |

presolve_passes | Set a maximum limit on the number of passes through the Knitro presolve operations | `10` |

presolve_tol | Determines the tolerance used by the Knitro presolver to remove variables and constraints from the model | `1e-06` |

restarts | Specifies whether or not to enable automatic restarts in Knitro | `0` |

restarts_maxit | When restarts are enabled, this option can be used to specify a maximum number of iterations before enforcing a restart | `0` |

scale | Specifies whether to perform problem scaling of the objective function, constraint functions, or possibly variables | `1` |

soc | Specifies whether or not to try second order corrections (SOC) | `1` |

strat_warm_start | Specifies whether or not to invoke a warm-start strategy | `0` |

## Derivative options

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

findiff_relstepsize | Specifies the relative stepsize used for finite-difference gradients | `0` |

findiff_terminate | This option specifies the termination criteria when using finite-difference gradients | `1` |

gradopt | Specifies how to compute the gradients of the objective and constraint functions | `1` |

hessopt | Specifies how to compute the (approximate) Hessian of the Lagrangian | `0` |

lmsize | Specifies the number of limited memory pairs stored when approximating the Hessian using the limited-memory quasi-Newton BFGS option | `10` |

## Termination options

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

feastol | Specifies the final relative stopping tolerance for the feasibility error | `1e-06` |

feastolabs | Specifies the final absolute stopping tolerance for the feasibility error | `0.001` |

fstopval | Used to implement a custom stopping condition based on the objective function value | `maxdouble` |

ftol | The optimization process will terminate if the relative change in the objective function is less than ftol for ftol_iters consecutive feasible iterations | `1e-15` |

ftol_iters | The optimization process will terminate if the relative change in the objective function is less than ftol for ftol_iters consecutive feasible iterations | `5` |

infeastol | Specifies the (relative) tolerance used for declaring infeasibility of a model | `1e-08` |

infeastol_iters | The optimization process will terminate if the relative change in the feasibility error is less than infeastol for infeastol_iters consecutive infeasible iterations | `50` |

maxfevals | Specifies the maximum number of function evaluations before termination | `-1` |

maxit | Specifies the maximum number of iterations before termination | `GAMS iterlim` |

maxtime_cpu | Specifies, in seconds, the maximum allowable CPU time before termination | `100000000` |

maxtime_real | Specifies, in seconds, the maximum allowable real time before termination | `GAMS reslim` |

opttol | Specifies the final relative stopping tolerance for the KKT (optimality) error | `1e-06` |

opttolabs | Specifies the final absolute stopping tolerance for the KKT (optimality) error | `0.001` |

xtol | The optimization process will terminate if the relative change in all components of the solution point estimate is less than xtol for xtol_iters | `1e-12` |

xtol_iters | The optimization process will terminate if the relative change in the solution estimate is less than xtol for xtol_iters consecutive iterations | `0` |

## Barrier options

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

bar_conic_enable | Enable special treatments for conic constraints when using the Interior/Direct algorithm (has no affect when using the Interior/CG algorithm) | `-1` |

bar_directinterval | Controls the maximum number of consecutive conjugate gradient (CG) steps before Knitro will try to enforce that a step is taken using direct linear algebra | `-1` |

bar_feasible | Specifies whether special emphasis is placed on getting and staying feasible in the interior-point algorithms | `0` |

bar_feasmodetol | Specifies the tolerance in equation that determines whether Knitro will force subsequent iterates to remain feasible | `0.0001` |

bar_initmu | Specifies the initial value for the barrier parameter \(\mu\) used with the barrier algorithms | `-1` |

bar_initpi_mpec | Specifies the initial value for the MPEC penalty parameter \(\pi\) used when solving problems with complementarity constraints using the barrier algorithms | `0` |

bar_initpt | Indicates initial point strategy for x, slacks and multipliers when using a barrier algorithm | `0` |

bar_linsys | Indicates which linear system form is used inside the Interior/Direct algorithm for computing primal-dual steps | `-1` |

bar_maxcorrectors | Specifies the maximum number of corrector steps allowed for primal-dual steps | `-1` |

bar_maxcrossit | Specifies the maximum number of crossover iterations before termination | `0` |

bar_maxrefactor | Indicates the maximum number of refactorizations of the KKT system per iteration of the Interior/Direct algorithm before reverting to a CG step | `-1` |

bar_murule | Indicates which strategy to use for modifying the barrier parameter \(mu\) in the barrier algorithms | `0` |

bar_pencons | Indicates whether a penalty approach is applied to the constraints | `-1` |

bar_penrule | Indicates which penalty parameter strategy to use for determining whether or not to accept a trial iterate | `0` |

bar_refinement | Specifies whether to try to refine the barrier solution for better precision | `0` |

bar_relaxcons | Indicates whether a relaxation approach is applied to the constraints | `2` |

bar_slackboundpush | Specifies the amount by which the barrier slack variables are initially pushed inside the bounds | `-1` |

bar_switchobj | Indicates which objective function to use when the barrier algorithms switch to a pure feasibility phase | `1` |

bar_switchrule | Indicates whether or not the barrier algorithms will allow switching from an optimality phase to a pure feasibility phase | `-1` |

bar_watchdog | Specifies whether to enable watchdog heuristic for barrier algorithms | `0` |

## Active-set options

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

act_lpfeastol | Specifies the feasibility tolerance used for linear programming subproblems solved when using the Active Set or SQP algorithms | `1e-08` |

act_lppenalty | Indicates whether to use a penalty formulation for linear programming subproblems in the Knitro Active Set or SQP algorithms | `1` |

act_lppresolve | Indicates whether to apply a presolve for linear programming subproblems in the Knitro Active Set or SQP algorithms | `0` |

act_parametric | Indicates whether to use a parametric approach when solving linear programming (LP) subproblems when using the Knitro Active Set or SQP algorithms | `1` |

act_qpalg | Indicates which algorithm to use to solve quadratic programming (QP) subproblems when using the Knitro Active Set or SQP algorithms | `0` |

act_qppenalty | Indicates whether to use a penalty formulation for quadratic programming subproblems in the Knitro SQP algorithm | `-1` |

## MIP options

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

mip_branchrule | Specifies which branching rule to use for MIP branch and bound procedure | `0` |

mip_clique | Specifies rules for adding clique cuts | `0` |

mip_cutfactor | This value specifies a limit on the number of cuts added to a node subproblem | `1` |

mip_gub_branch | Specifies whether or not to branch on generalized upper bounds (GUBs) | `0` |

mip_heuristic | Specifies which MIP heuristic search approach to apply to try to find an initial integer feasible point | `-1` |

mip_heuristic_maxit | Specifies the maximum number of iterations to allow for MIP heuristic, if one is enabled | `100` |

mip_heuristic_terminate | Specifies the condition for terminating the MIP heuristic | `1` |

mip_implications | Specifies whether or not to add constraints to the MIP derived from logical implications | `1` |

mip_integer_tol | This value specifies the threshold for deciding whether or not a variable is determined to be an integer | `1e-08` |

mip_integral_gap_abs | The absolute integrality gap stop tolerance for MIP | `GAMS optca` |

mip_integral_gap_rel | The relative integrality gap stop tolerance for MIP | `GAMS optcr` |

mip_intvar_strategy | Specifies how to handle integer variables | `0` |

mip_knapsack | Specifies rules for adding MIP knapsack cuts | `1` |

mip_lpalg | Specifies which algorithm to use for any linear programming (LP) subproblem solves that may occur in the MIP branch and bound procedure | `0` |

mip_maxnodes | Specifies the maximum number of nodes explored (0 means no limit) | `GAMS nodlim` |

mip_maxsolves | Specifies the maximum number of subproblem solves allowed (0 means no limit) | `0` |

mip_maxtime_cpu | Specifies the maximum allowable CPU time in seconds for the complete MIP solution | `100000000` |

mip_maxtime_real | Specifies the maximum allowable real time in seconds for the complete MIP solution | `GAMS reslim` |

mip_method | Specifies which MIP method to use | `0` |

mip_mir | Specifies rules for adding mixed integer rounding cuts | `-1` |

mip_nodealg | Specifies which algorithm to use for standard node subproblem solves in MIP (same options as algorithm user option) | `0` |

mip_outinterval | Specifies node printing interval for mip_outlevel when mip_outlevel > 0 | `10` |

mip_outlevel | Specifies how much MIP information to print | `1` |

mip_pseudoinit | Specifies the method used to initialize pseudo-costs corresponding to variables that have not yet been branched on in the MIP method | `0` |

mip_relaxable | Specifies Whether integer variables are relaxable | `1` |

mip_rootalg | Specifies which algorithm to use for the root node solve in MIP (same options as algorithm user option) | `0` |

mip_rounding | Specifies the MIP rounding rule to apply | `-1` |

mip_selectdir | Specifies the MIP node selection direction rule (for tiebreakers) for choosing the next node in the branch and bound tree | `0` |

mip_selectrule | Specifies the MIP select rule for choosing the next node in the branch and bound tree | `0` |

mip_strong_candlim | Specifies the maximum number of candidates to explore for MIP strong branching | `10` |

mip_strong_level | Specifies the maximum number of tree levels on which to perform MIP strong branching | `10` |

mip_strong_maxit | Specifies the maximum number of iterations to allow for MIP strong branching solves | `1000` |

mip_terminate | Specifies conditions for terminating the MIP algorithm | `0` |

mip_zerohalf | Specifies rules for adding zero-half cuts | `0` |

## Multi-algorithm options

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

ma_maxtime_cpu | Specifies, in seconds, the maximum allowable CPU time before termination for the multi-algorithm ("MA") procedure (algorithm=5) | `100000000` |

ma_maxtime_real | Specifies, in seconds, the maximum allowable real time before termination for the multi-algorithm ("MA") procedure (algorithm=5) | `100000000` |

ma_outsub | Enable writing algorithm output to files for the multi-algorithm (algorithm=5) procedure | `0` |

ma_terminate | Define the termination condition for the multi-algorithm (algorithm=5) procedure | `1` |

## Multi-start options

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

ms_deterministic | Indicates whether Knitro multi-start procedure will be deterministic (when ms_terminate = 0) | `1` |

ms_enable | Indicates whether Knitro will solve from multiple start points to find a better local minimum | `0` |

ms_maxbndrange | Specifies the maximum range that an unbounded variable can take when determining new start points | `1000` |

ms_maxsolves | Specifies how many start points to try in multi-start | `0` |

ms_maxtime_cpu | Specifies, in seconds, the maximum allowable CPU time before termination | `100000000` |

ms_maxtime_real | Specifies, in seconds, the maximum allowable real time before termination | `100000000` |

ms_num_to_save | Specifies the number of distinct feasible points to save in a file named knitro_mspoints | `0` |

ms_outsub | Enable writing algorithm output to files for the parallel multistart procedure | `0` |

ms_savetol | Specifies the tolerance for deciding if two feasible points are distinct | `1e-06` |

ms_seed | Seed value used to generate random initial points in multi-start; should be a non-negative integer | `0` |

ms_startptrange | Specifies the maximum range that each variable can take when determining new start points | `1e+20` |

ms_terminate | Specifies the condition for terminating multi-start | `0` |

## Parallelism options

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

par_blasnumthreads | Specify the number of threads to use for BLAS operations when blasoption = 1 | `0` |

par_lsnumthreads | Specify the number of threads to use for linear system solve operations when linsolver = 6 | `0` |

par_msnumthreads | Specify the number of threads to use for multistart (when ms_enable = 1) | `0` |

threads | default thread count | `GAMS threads` |

## Output options

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

outappend | Specifies whether output should be started in a new file, or appended to existing files | `0` |

outdir | Specifies a single directory as the location to write all output files | |

outlev | Controls the level of output produced by Knitro | `2` |

outmode | Specifies where to direct the output from Knitro | `0` |

outname | Use to specify a custom filename when output is written to a file using outmode | |

out_csvinfo | Controls whether or not to generates a file knitro_solve | `0` |

out_csvname | Use to specify a custom csv filename when using out_csvinfo | |

out_hints | Specifies whether to print diagnostic hints (e.g. about user option settings) after solving | `1` |

## Tuner options

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

tuner | Indicates whether to invoke the Knitro-Tuner | `0` |

tuner_maxtimecpu | Specifies, in seconds, the maximum allowable CPU time before terminating the Knitro-Tuner | `100000000` |

tuner_maxtimereal | Specifies, in seconds, the maximum allowable real time before terminating the Knitro-Tuner | `100000000` |

tuner_optionsfile | Can be used to specify the location of a Tuner options file | |

tuner_outsub | Enable writing additional Tuner subproblem solve output to files for the Knitro-Tuner procedure (tuner=1) | `0` |

tuner_terminate | Define the termination condition for the Knitro-Tuner procedure (tuner=1) | `0` |

# Detailed Descriptions of Knitro Options

**act_lpfeastol** *(real)*: Specifies the feasibility tolerance used for linear programming subproblems solved when using the Active Set or SQP algorithms ↵

Range: [

`0`

, ∞]Default:

`1e-08`

**act_lppenalty** *(integer)*: Indicates whether to use a penalty formulation for linear programming subproblems in the Knitro Active Set or SQP algorithms ↵

Default:

`1`

value meaning `1`

(all) penalize all constraints. `2`

(nonlinear) penalize only nonlinear constraints. `3`

(dynamic) dynamically choose which constraints to penalize.

**act_lppresolve** *(boolean)*: Indicates whether to apply a presolve for linear programming subproblems in the Knitro Active Set or SQP algorithms ↵

Default:

`0`

value meaning `0`

(off) presolve turned off for LP subproblems. `1`

(on) presolve turned on for LP subproblems.

**act_parametric** *(integer)*: Indicates whether to use a parametric approach when solving linear programming (LP) subproblems when using the Knitro Active Set or SQP algorithms ↵

Indicates whether to use a parametric approach when solving linear programming (LP) subproblems when using the Knitro Active Set or SQP algorithms. A parametric approach will solve a sequence of closely related LPs instead of one LP. It may increase the cost of an active-set iteration, but perhaps lead to convergence in fewer iterations.

Default:

`1`

value meaning `0`

(no) do not use a parametric solve (i.e. solve a single LP). `1`

(maybe) use a parametric solve sometimes. `2`

(yes) always try a parametric solve.

**act_qpalg** *(integer)*: Indicates which algorithm to use to solve quadratic programming (QP) subproblems when using the Knitro Active Set or SQP algorithms ↵

Indicates which algorithm to use to solve quadratic programming (QP) subproblems when using the Knitro Active Set or SQP algorithms. This option has no effect on the Interior/Direct and Interior/CG algorithms.

Default:

`0`

value meaning `0`

(auto) let Knitro automatically choose an algorithm, based on the problem characteristics. `1`

(direct) use the Interior/Direct algorithm. `2`

(cg) use the Interior/CG algorithm. `3`

(active) use the Active Set algorithm.

**act_qppenalty** *(integer)*: Indicates whether to use a penalty formulation for quadratic programming subproblems in the Knitro SQP algorithm ↵

Default:

`-1`

value meaning `-1`

(auto) let Knitro automatically decide. `0`

(none) do not penalize constraints in QP subproblems. `1`

(all) penalize all constraints in QP subproblems.

**algorithm** *(integer)*: Indicates which algorithm to use to solve the problem ↵

Default:

`0`

value meaning `0`

(auto) let Knitro automatically choose an algorithm, based on the problem characteristics. `1`

(direct) use the Interior/Direct algorithm. `2`

(cg) use the Interior/CG algorithm. `3`

(active) use the Active Set algorithm. `4`

(sqp) use the SQP algorithm. `5`

(multi) run all algorithms, perhaps in parallel (see Algorithms).

**bar_conic_enable** *(integer)*: Enable special treatments for conic constraints when using the Interior/Direct algorithm (has no affect when using the Interior/CG algorithm) ↵

Default:

`-1`

value meaning `-1`

(auto) Let Knitro automatically choose the strategy. `0`

(none) Do not apply any special treatment for conic constraints. `1`

(soc) Apply special treatments for any Second Order Cone (SOC) constraints identified in the model.

**bar_directinterval** *(integer)*: Controls the maximum number of consecutive conjugate gradient (CG) steps before Knitro will try to enforce that a step is taken using direct linear algebra ↵

Controls the maximum number of consecutive conjugate gradient (CG) steps before Knitro will try to enforce that a step is taken using direct linear algebra. This option is only valid for the Interior/Direct algorithm and may be useful on problems where Knitro appears to be taking lots of conjugate gradient steps. Setting bar_directinterval to 0 will try to enforce that only direct steps are taken which may produce better results on some problems.

Range: {

`-1`

, ..., ∞}Default:

`-1`

**bar_feasible** *(integer)*: Specifies whether special emphasis is placed on getting and staying feasible in the interior-point algorithms ↵

Specifies whether special emphasis is placed on getting and staying feasible in the interior-point algorithms. Note This option can only be used with the Interior/Direct and Interior/CG algorithms. If bar_feasible = stay or bar_feasible = get_stay, this will activate the feasible version of Knitro. The feasible version of Knitro will force iterates to strictly satisfy inequalities, but does not require satisfaction of equality constraints at intermediate iterates. This option and the honorbnds option may be useful in applications where functions are undefined outside the region defined by inequalities. The initial point must satisfy inequalities to a sufficient degree; if not, Knitro may generate infeasible iterates and does not switch to the feasible version until a sufficiently feasible point is found. Sufficient satisfaction occurs at a point x if it is true for all inequalities that \(cl + tol \leq c(x) \leq cu - tol\) The constant tol is determined by the option bar_feasmodetol. If bar_feasible = get or bar_feasible = get_stay, Knitro will place special emphasis on first trying to get feasible before trying to optimize.

Default:

`0`

value meaning `0`

(no) No special emphasis on feasibility. `1`

(stay) Iterates must satisfy inequality constraints once they become sufficiently feasible. `2`

(get) Special emphasis is placed on getting feasible before trying to optimize. `3`

(get_stay) Implement both options 1 and 2 above.

**bar_feasmodetol** *(real)*: Specifies the tolerance in equation that determines whether Knitro will force subsequent iterates to remain feasible ↵

Specifies the tolerance in equation that determines whether Knitro will force subsequent iterates to remain feasible. The tolerance applies to all inequality constraints in the problem. This option only has an effect if option bar_feasible = stay or bar_feasible = get_stay.

Range: [

`0`

, ∞]Default:

`0.0001`

**bar_initmu** *(real)*: Specifies the initial value for the barrier parameter \(\mu\) used with the barrier algorithms ↵

Specifies the initial value for the barrier parameter \(\mu\) used with the barrier algorithms. This option has no effect on the Active Set algorithm.

Range: [-∞, ∞]

Default:

`-1`

**bar_initpi_mpec** *(real)*: Specifies the initial value for the MPEC penalty parameter \(\pi\) used when solving problems with complementarity constraints using the barrier algorithms ↵

Specifies the initial value for the MPEC penalty parameter \(\pi\) used when solving problems with complementarity constraints using the barrier algorithms. If this value is non-positive, then Knitro uses an internal formula to initialize the MPEC penalty parameter.

Range: [

`0`

, ∞]Default:

`0`

**bar_initpt** *(integer)*: Indicates initial point strategy for x, slacks and multipliers when using a barrier algorithm ↵

Indicates initial point strategy for x, slacks and multipliers when using a barrier algorithm. Note, this option only alters the initial x values if the user does not specify an initial x. This option has no effect on the Active Set algorithm.

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the strategy. `1`

(convex) Initialization designed for convex models. `2`

(nearbnd) Initialization strategy that stays closer to the bounds. `3`

(central) Initialization strategy that is more central on double-bounded variables.

**bar_linsys** *(integer)*: Indicates which linear system form is used inside the Interior/Direct algorithm for computing primal-dual steps ↵

Indicates which linear system form is used inside the Interior/Direct algorithm for computing primal-dual steps. Eliminating more elements results in a smaller dimensional linear system (but also one that is, perhaps, less numerically stable). The bounds option may be preferable for very large problems with many bounded variables. The ineq option may generate significant speedups on models where the number of variables is small, but the number of inequality constraints is large.

Default:

`-1`

value meaning `-1`

(auto) Let Knitro automatically choose the linear system form. `0`

(full) Use the full linear system. `1`

(slacks) Eliminate the slack variables. `2`

(bounds) Eliminate the slack variables and bounds. `3`

(ineqs) Eliminate the slack variables, bounds, and some inequalities.

**bar_maxcorrectors** *(integer)*: Specifies the maximum number of corrector steps allowed for primal-dual steps ↵

Specifies the maximum number of corrector steps allowed for primal-dual steps. If the value is positive and the algorithm used is Interior/Direct, then Knitro may add at most bar_maxcorrectors corrector steps to the primal-dual step to try to stay closer to the central path. This may speedup convergence on some models (although it may make the cost per iteration a little more expensive). If the value is negative, Knitro automatically determines the maximum number of corrector steps to apply.

Range: {-∞, ..., ∞}

Default:

`-1`

**bar_maxcrossit** *(integer)*: Specifies the maximum number of crossover iterations before termination ↵

Specifies the maximum number of crossover iterations before termination. If the value is positive and the algorithm in operation is Interior/Direct or Interior/CG, then Knitro will crossover to the Active Set algorithm near the solution. The Active Set algorithm will then perform at most bar_maxcrossit iterations to get a more exact solution. If the value is 0, no Active Set crossover occurs and the interior-point solution is the final result. If Active Set crossover is unable to improve the approximate interior-point solution, then Knitro will restore the interior-point solution. In some cases (especially on large-scale problems or difficult degenerate problems) the cost of the crossover procedure may be significant â€“ for this reason, crossover is disabled by default. Enabling crossover generally provides a more accurate solution than Interior/Direct or Interior/CG.

Range: {

`0`

, ..., ∞}Default:

`0`

**bar_maxrefactor** *(integer)*: Indicates the maximum number of refactorizations of the KKT system per iteration of the Interior/Direct algorithm before reverting to a CG step ↵

Indicates the maximum number of refactorizations of the KKT system per iteration of the Interior/Direct algorithm before reverting to a CG step. If this value is set to -1, it will use a dynamic strategy. These refactorizations are performed if negative curvature is detected in the model. Rather than reverting to a CG step, the Hessian matrix is modified in an attempt to make the subproblem convex and then the KKT system is refactorized. Increasing this value will make the Interior/Direct algorithm less likely to take CG steps. If the Interior/Direct algorithm is taking a large number of CG steps (as indicated by a positive value for "CGits" in the output), this may improve performance. This option has no effect on the Active Set algorithm.

Range: {

`-1`

, ..., ∞}Default:

`-1`

**bar_murule** *(integer)*: Indicates which strategy to use for modifying the barrier parameter \(mu\) in the barrier algorithms ↵

Indicates which strategy to use for modifying the barrier parameter \(mu\) in the barrier algorithms. Not all strategies are available for both barrier algorithms, as described below. This option has no effect on the Active Set algorithm.

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the strategy. `1`

(monotone) Monotonically decrease the barrier parameter. Available for both barrier algorithms. `2`

(adaptive) Use an adaptive rule based on the complementarity gap to determine the value of the barrier parameter. Available for both barrier algorithms. `3`

(probing) Use a probing (affine-scaling) step to dynamically determine the barrier parameter. Available only for the Interior/Direct algorithm. `4`

(dampmpc) Use a Mehrotra predictor-corrector type rule to determine the barrier parameter, with safeguards on the corrector step. Available only for the Interior/Direct algorithm. `5`

(fullmpc) Use a Mehrotra predictor-corrector type rule to determine the barrier parameter, without safeguards on the corrector step. Available only for the Interior/Direct algorithm. `6`

(quality) Minimize a quality function at each iteration to determine the barrier parameter. Available only for the Interior/Direct algorithm.

**bar_pencons** *(integer)*: Indicates whether a penalty approach is applied to the constraints ↵

Indicates whether a penalty approach is applied to the constraints. Using a penalty approach may be helpful when the problem has degenerate or difficult constraints. It may also help to more quickly identify infeasible problems, or achieve feasibility in problems with difficult constraints. This option has no effect on the Active Set algorithm.

Default:

`-1`

value meaning `-1`

(auto) Let Knitro automatically choose the strategy. `0`

(none) No constraints are penalized. `2`

(all) A penalty approach is applied to all general constraints. `3`

(equalities) Apply a penalty approach to equality constraints only.

**bar_penrule** *(integer)*: Indicates which penalty parameter strategy to use for determining whether or not to accept a trial iterate ↵

Indicates which penalty parameter strategy to use for determining whether or not to accept a trial iterate. This option has no effect on the Active Set algorithm.

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the strategy. `1`

(single) Use a single penalty parameter in the merit function to weight feasibility versus optimality. `2`

(flex) Use a more tolerant and flexible step acceptance procedure based on a range of penalty parameter values.

**bar_refinement** *(boolean)*: Specifies whether to try to refine the barrier solution for better precision ↵

Specifies whether to try to refine the barrier solution for better precision. If enabled, once the optimality conditions are satisfied, Knitro will apply an additional refinement/postsolve phase to try to obtain more precision in the barrier solution. The effect is similar to the effect of enabling bar_maxcrossit, but it is usually much more efficient since it does not involve switching to the Active Set algorithm.

Default:

`0`

**bar_relaxcons** *(integer)*: Indicates whether a relaxation approach is applied to the constraints ↵

Indicates whether a relaxation approach is applied to the constraints. Using a relaxation approach may be helpful when the problem has degenerate or difficult constraints. This option has no effect on the Active Set algorithm.

Default:

`2`

value meaning `0`

(none) No constraints are relaxed. `1`

(eqs) A relaxation approach is applied to general equality constraints. `2`

(ineqs) A relaxation approach is applied to general inequality constraints. `3`

(all) A relaxation approach is applied to all general constraints.

**bar_slackboundpush** *(real)*: Specifies the amount by which the barrier slack variables are initially pushed inside the bounds ↵

Specifies the amount by which the barrier slack variables are initially pushed inside the bounds. A smaller value may be preferable when warm-starting from a point close to the solution.

Range: [-∞, ∞]

Default:

`-1`

**bar_switchobj** *(integer)*: Indicates which objective function to use when the barrier algorithms switch to a pure feasibility phase ↵

Default:

`1`

value meaning `0`

(none) No (or zero) objective. `1`

(scalarprox) Proximal point objective with scalar weighting. `2`

(diagprox) Proximal point objective with diagonal weighting.

**bar_switchrule** *(integer)*: Indicates whether or not the barrier algorithms will allow switching from an optimality phase to a pure feasibility phase ↵

Indicates whether or not the barrier algorithms will allow switching from an optimality phase to a pure feasibility phase. This option has no effect on the Active Set algorithm.

Default:

`-1`

value meaning `-1`

(auto) Let Knitro determine the switching procedure. `0`

(never) Never switch to feasibility phase. `2`

(moderate) Allow switches to feasibility phase. `3`

(aggressive) Use a more aggressive switching rule.

**bar_watchdog** *(boolean)*: Specifies whether to enable watchdog heuristic for barrier algorithms ↵

Specifies whether to enable watchdog heuristic for barrier algorithms. In general, enabling the watchdog heuristic makes the barrier algorithms more likely to accept trial points. Specifically, the watchdog heuristic may occasionally accept trial points that increase the merit function, provided that subsequent iterates decrease the merit function.

Default:

`0`

**blasoption** *(integer)*: Specifies the BLAS/LAPACK function library to use for basic vector and matrix computations ↵

Default:

`1`

value meaning `0`

(knitro) Use Knitro built-in functions. `1`

(intel) Use Intel Math Kernel Library (MKL) functions on available platforms. `2`

(dynamic) Use the dynamic library specified with option blasoptionlib.

**blasoptionlib** *(string)*: Specifies a dynamic library name that contains object code for BLAS/LAPACK functions ↵

Specifies a dynamic library name that contains object code for BLAS/LAPACK functions. The library must implement all the functions declared in the file include/blas_lapack.h.

**bndrange** *(real)*: Specifies max limits on the magnitude of constraint and variable bounds ↵

Specifies max limits on the magnitude of constraint and variable bounds. Any constraint or variable bounds whose magnitude is greater than or equal to bndrange will be treated as infinite by Knitro. Using very large, finite bounds is discouraged (and is generally an indication of a poorly scaled model).

Range: [

`0`

, ∞]Default:

`1e+20`

**cg_maxit** *(integer)*: Determines the maximum allowable number of inner conjugate gradient (CG) iterations per Knitro minor iteration ↵

Default:

`-1`

value meaning `-1`

Let Knitro automatically determine a value. `0`

Knitro will set a maximum value based on the problem size. `n`

At most n>0 CG iterations may be performed during one minor iteration of Knitro.

**cg_pmem** *(integer)*: Specifies the amount of nonzero elements per column of the Hessian of the Lagrangian which are retained when computing the incomplete Cholesky preconditioner ↵

Default:

`10`

value meaning `n`

At most n>0 nonzero elements per column.

**cg_precond** *(boolean)*: Specifies whether an incomplete Cholesky preconditioner is applied during CG iterations in barrier algorithms ↵

Default:

`0`

value meaning `0`

(no) Not applied. `1`

(chol) Preconditioner is applied.

**cg_stoptol** *(real)*: Specifies the relative stopping tolerance used for the conjugate gradient (CG) subproblem solves ↵

Range: [

`0`

, ∞]Default:

`0.01`

**convex** *(integer)*: Declare the problem as convex by setting to 1 or non-convex by setting to 0 ↵

Declare the problem as convex by setting to 1 or non-convex by setting to 0. Otherwise, Knitro will try to determine this automatically, but may only be able to do so for simple model forms such as QPs or QCQPs. If your model is specified as (or automatically determined to be) convex, this will cause Knitro to apply specializations and tunings that are often beneficial for convex models to speed up the solution. Currently this option is only active for the Interior/Direct algorithm, but may be applied to other algorithms in the future.

Range: {

`-1`

, ...,`1`

}Default:

`-1`

**cpuplatform** *(integer)*: This option can be used to specify the target instruction set architecture for the machine on which Knitro is running ↵

This option can be used to specify the target instruction set architecture for the machine on which Knitro is running. This can be used, for example , to try to produce more consistent Knitro performance across various architectures (at the expense of, perhaps, slower performance on some platforms). This option is currently only used for the Intel Math Kernel Library (MKL) functions used inside Knitro.

Range: {

`-1`

, ...,`5`

}Default:

`-1`

**datacheck** *(boolean)*: Specifies whether to perform more extensive data checks to look for errors in the problem input to Knitro (in particular, this option looks for errors in the sparse Jacobian and/or sparse Hessian structure) ↵

Specifies whether to perform more extensive data checks to look for errors in the problem input to Knitro (in particular, this option looks for errors in the sparse Jacobian and/or sparse Hessian structure). The datacheck may have a non- trivial cost for large problems.

Default:

`0`

**delta** *(real)*: Specifies the initial trust region radius scaling factor used to determine the initial trust region size ↵

Range: [

`1e-14`

, ∞]Default:

`1`

**feastol** *(real)*: Specifies the final relative stopping tolerance for the feasibility error ↵

Specifies the final relative stopping tolerance for the feasibility error. Smaller values of feastol result in a higher degree of accuracy in the solution with respect to feasibility.

Range: [

`0`

, ∞]Default:

`1e-06`

**feastolabs** *(real)*: Specifies the final absolute stopping tolerance for the feasibility error ↵

Synonym: feastol_abs

Specifies the final absolute stopping tolerance for the feasibility error. Smaller values of feastol_abs result in a higher degree of accuracy in the solution with respect to feasibility.

Range: [

`0`

, ∞]Default:

`0.001`

**findiff_relstepsize** *(real)*: Specifies the relative stepsize used for finite-difference gradients ↵

Specifies the relative stepsize used for finite-difference gradients. This option sets the stepsize for all variables.

Range: [-∞, ∞]

Default:

`0`

**findiff_terminate** *(boolean)*: This option specifies the termination criteria when using finite-difference gradients ↵

This option specifies the termination criteria when using finite-difference gradients. The optimality (or KKT) conditions for nonlinear optimization depend on gradient values of the nonlinear objective and constraint functions . When using finite-difference gradients (e.g. gradopt > 1), there will typically be small errors in the computed gradients that will limit the precision in the solution (and the ability to satisfy the optimality conditions). By default, Knitro will try to estimate these finite-difference gradient errors and terminate when it seems that no more accuracy in the solution is possible. The solution will be treated as optimal as long as it is feasible and the optimality conditions are satisfied either by the optimality tolerances (opttol and opttol_abs) or the error estimates. On some problems, the error estimates may result in extra function evaluations on some iterations, but will often prevent extra iterations that produce no significant improvement in the solution. This special termination can be disabled by setting findiff_terminate = 0 (none).

Default:

`1`

value meaning `0`

(none) No special criteria; use the standard stopping conditions. `1`

(errest) Allow termination based on estimates of the finite-difference error (when no more significant progress is likely).

**fstopval** *(real)*: Used to implement a custom stopping condition based on the objective function value ↵

Used to implement a custom stopping condition based on the objective function value. Knitro will stop and declare that a satisfactory solution was found if a feasible objective function value at least as good as the value specified by fstopval is achieved. This stopping condition is only active when the absolute value of fstopval is less than objrange.

Range: [-∞, ∞]

Default:

`maxdouble`

**ftol** *(real)*: The optimization process will terminate if the relative change in the objective function is less than ftol for ftol_iters consecutive feasible iterations ↵

Range: [

`0`

, ∞]Default:

`1e-15`

**ftol_iters** *(integer)*: The optimization process will terminate if the relative change in the objective function is less than ftol for ftol_iters consecutive feasible iterations ↵

Range: {

`1`

, ..., ∞}Default:

`5`

**gradopt** *(integer)*: Specifies how to compute the gradients of the objective and constraint functions ↵

Default:

`1`

value meaning `1`

(exact) User provides a routine for computing the exact gradients. `2`

(forward) Knitro computes gradients by forward finite differences. `3`

(central) Knitro computes gradients by central finite differences.

**hessopt** *(integer)*: Specifies how to compute the (approximate) Hessian of the Lagrangian ↵

Default:

`0`

value meaning `0`

(auto) `1`

(exact) User provides a routine for computing the exact Hessian. `2`

(bfgs) Knitro computes a (dense) quasi-Newton BFGS Hessian. `3`

(sr1) Knitro computes a (dense) quasi-Newton SR1 Hessian. `4`

(product_findiff) Knitro computes Hessian-vector products using finite-differences. `5`

(product) User provides a routine to compute the Hessian-vector products. `6`

(lbfgs) Knitro computes a limited-memory quasi-Newton BFGS Hessian (its size is determined by the option lmsize). `7`

(gauss_newton) Knitro computes a Gauss-Newton approximation of the hessian (available for least-squares only, and default value for least-squares)

**honorbnds** *(integer)*: Indicates whether or not to enforce satisfaction of simple variable bounds throughout the optimization ↵

Indicates whether or not to enforce satisfaction of simple variable bounds throughout the optimization. This option and the bar_feasible option may be useful in applications where functions are undefined outside the region defined by inequalities.

Default:

`-1`

value meaning `-1`

(auto) Knitro automatically determine the best setting. `0`

(no) Knitro does not require that the bounds on the variables be satisfied at intermediate iterates. `1`

(always) Knitro enforces that the initial point and all subsequent solution estimates satisfy the bounds on the variables. `2`

(initpt) Knitro enforces that the initial point satisfies the bounds on the variables.

**infeastol** *(real)*: Specifies the (relative) tolerance used for declaring infeasibility of a model ↵

Specifies the (relative) tolerance used for declaring infeasibility of a model. Smaller values of infeastol make it more difficult to satisfy the conditions Knitro uses for detecting infeasible models. If you believe Knitro incorrectly declares a model to be infeasible, then you should try a smaller value for infeastol.

Range: [

`0`

, ∞]Default:

`1e-08`

**infeastol_iters** *(integer)*: The optimization process will terminate if the relative change in the feasibility error is less than infeastol for infeastol_iters consecutive infeasible iterations ↵

Range: {

`1`

, ..., ∞}Default:

`50`

**initpenalty** *(real)*: Specifies the initial penalty parameter used in the Knitro merit functions ↵

Specifies the initial penalty parameter used in the Knitro merit functions. The Knitro merit functions are used to balance improvements in the objective function versus improvements in feasibility. A larger initial penalty value places more weight initially on feasibility in the merit function.

Range: [

`0`

, ∞]Default:

`10`

**linesearch** *(integer)*: Indicates which linesearch strategy to use for the Interior/Direct or SQP algorithm to search for a new acceptable iterate ↵

Indicates which linesearch strategy to use for the Interior/Direct or SQP algorithm to search for a new acceptable iterate. This option has no effect on the Interior/CG or Active Set algorithm.

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the strategy. `1`

(backtrack) Use a simple backtracking scheme. `2`

(interpolate) Use a cubic interpolation scheme. `3`

(weakwolfe) Use a linesearch that satisfies the weak Wolfe conditions (unconstrained only).

**linesearch_maxtrials** *(integer)*: Indicates the maximum allowable number of trial points during the linesearch of the Interior/Direct or SQP algorithm before treating the linesearch step as a failure and generating a new step ↵

Indicates the maximum allowable number of trial points during the linesearch of the Interior/Direct or SQP algorithm before treating the linesearch step as a failure and generating a new step. This option has no effect on the Interior/CG or Active Set algorithm.

Range: {

`0`

, ..., ∞}Default:

`3`

**linsolver** *(integer)*: Indicates which linear solver to use to solve linear systems arising in Knitro algorithms ↵

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the linear solver. `1`

(internal) Not currently used; reserved for future use. Same as auto for now. `2`

(hybrid) Use a hybrid approach where the solver chosen depends on the particular linear system which needs to be solved. `3`

(qr) Use a dense QR method. This approach uses LAPACK QR routines. Since it uses a dense method, it is only efficient for small problems. It may often be the most efficient method for small problems with dense Jacobians or Hessian matrices. `4`

(ma27) Use the HSL MA27 sparse symmetric indefinite solver. `5`

(ma57) Use the HSL MA57 sparse symmetric indefinite solver. `6`

(mklpardiso) Use the Intel MKL PARDISO (parallel, deterministic) sparse symmetric indefinite solver. `7`

(ma97) Use the HSL MA97 (parallel, deterministic) sparse symmetric indefinite solver. `8`

(ma86) Use the HSL MA86 (parallel, non-deterministic) sparse symmetric indefinite solver.

**linsolver_ooc** *(integer)*: Indicates whether to use Intel MKL PARDISO out-of-core solve of linear systems when linsolver = mklpardiso ↵

Indicates whether to use Intel MKL PARDISO out-of-core solve of linear systems when linsolver = mklpardiso. This option is only active when linsolver = mklpardiso.

Default:

`0`

value meaning `0`

(no) Do not use Intel MKL PARDISO out-of-core option. `1`

(maybe) Maybe solve out-of-core depending on how much space is needed. `2`

(yes) Solve linear systems out-of-core when using Intel MKL PARDISO.

**linsolver_pivottol** *(real)*: Specifies the initial pivot threshold used in factorization routines ↵

Specifies the initial pivot threshold used in factorization routines. The value should be in the range [0, â€¦, 0.5] with higher values resulting in more pivoting (more stable factorizations). Values less than 0 will be set to 0 and values larger than 0.5 will be set to 0.5. If linsolver_pivottol is non-positive, initially no pivoting will be performed. Smaller values may improve the speed of the code but higher values are recommended for more stability (for example, if the problem appears to be very ill-conditioned).

Range: [

`0`

,`0.5`

]Default:

`1e-08`

**lmsize** *(integer)*: Specifies the number of limited memory pairs stored when approximating the Hessian using the limited-memory quasi-Newton BFGS option ↵

Specifies the number of limited memory pairs stored when approximating the Hessian using the limited-memory quasi-Newton BFGS option. The value must be between 1 and 100 and is only used with hessopt = 6. Larger values may give a more accurate, but more expensive, Hessian approximation. Smaller values may give a less accurate, but faster, Hessian approximation. When using the limited memory BFGS approach it is recommended to experiment with different values of this parameter.

Range: {

`1`

, ...,`100`

}Default:

`10`

**maxfevals** *(integer)*: Specifies the maximum number of function evaluations before termination ↵

Specifies the maximum number of function evaluations before termination. Values less than zero imply no limit.

Range: {-∞, ..., ∞}

Default:

`-1`

**maxit** *(integer)*: Specifies the maximum number of iterations before termination ↵

Synonym: iterlim

Default:

`GAMS iterlim`

value meaning `0`

Let Knitro automatically choose a value based on the problem type. Currently Knitro sets this value to 10000 for LPs/NLPs and 3000 for MIP problems. `n`

At most n>0 iterations may be performed before terminating.

**maxtime_cpu** *(real)*: Specifies, in seconds, the maximum allowable CPU time before termination ↵

Range: [

`0`

,`100000000`

]Default:

`100000000`

**maxtime_real** *(real)*: Specifies, in seconds, the maximum allowable real time before termination ↵

Synonym: reslim

Range: [

`0`

,`100000000`

]Default:

`GAMS reslim`

**ma_maxtime_cpu** *(real)*: Specifies, in seconds, the maximum allowable CPU time before termination for the multi-algorithm ("MA") procedure (algorithm=5) ↵

Range: [

`0`

, ∞]Default:

`100000000`

**ma_maxtime_real** *(real)*: Specifies, in seconds, the maximum allowable real time before termination for the multi-algorithm ("MA") procedure (algorithm=5) ↵

Range: [

`0`

, ∞]Default:

`100000000`

**ma_outsub** *(boolean)*: Enable writing algorithm output to files for the multi-algorithm (algorithm=5) procedure ↵

Default:

`0`

value meaning `0`

Do not write detailed algorithm output to files. `1`

Write detailed algorithm output to files named knitro_ma_*.log.

**ma_terminate** *(integer)*: Define the termination condition for the multi-algorithm (algorithm=5) procedure ↵

Default:

`1`

value meaning `0`

Terminate after all algorithms have completed. `1`

Terminate at first locally optimal solution. `2`

Terminate at first feasible solution estimate. `3`

Terminate at first solution estimate of any type.

**mip_branchrule** *(integer)*: Specifies which branching rule to use for MIP branch and bound procedure ↵

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the branching rule. `1`

(most_frac) Use most fractional (most infeasible) branching. `2`

(pseudcost) Use pseudo-cost branching. `3`

(strong) Use strong branching (see options mip_strong_candlim, mip_strong_level and mip_strong_maxit for further control of strong branching procedure).

**mip_clique** *(integer)*: Specifies rules for adding clique cuts ↵

Default:

`0`

value meaning `0`

(none) Do not add clique cuts. `1`

(root) Add cuts derived from equalities at the root node only. `2`

(tree) Add cuts derived from equalities at every node depending on the solution of the relaxation and the cut generation strategy. `3`

(all) Add cuts derived from equalities combining both root and tree cut generations.

**mip_cutfactor** *(real)*: This value specifies a limit on the number of cuts added to a node subproblem ↵

This value specifies a limit on the number of cuts added to a node subproblem. If non-negative, a maximum of mip_cutfactor times the number of constraints is possibly appended.

Range: [

`0`

, ∞]Default:

`1`

**mip_gub_branch** *(boolean)*: Specifies whether or not to branch on generalized upper bounds (GUBs) ↵

Default:

`0`

value meaning `0`

(no) Do not branch on GUBs. `1`

(yes) Allow branching on GUBs.

**mip_heuristic** *(integer)*: Specifies which MIP heuristic search approach to apply to try to find an initial integer feasible point ↵

Specifies which MIP heuristic search approach to apply to try to find an initial integer feasible point. If a heuristic search procedure is enabled, it will run for at most mip_heuristic_maxit iterations, before starting the branch and bound procedure.

Default:

`-1`

value meaning `-1`

(auto) Let Knitro choose the heuristic to apply (if any). `0`

(none) No heuristic search applied. `2`

(feaspump) Apply feasibility pump heuristic. `3`

(mpec) Apply heuristic based on MPEC formulation. `4`

(diving) Apply diving heuristic.

**mip_heuristic_maxit** *(integer)*: Specifies the maximum number of iterations to allow for MIP heuristic, if one is enabled ↵

Range: {

`0`

, ..., ∞}Default:

`100`

**mip_heuristic_terminate** *(integer)*: Specifies the condition for terminating the MIP heuristic ↵

Default:

`1`

value meaning `1`

(feasible) Terminate at first feasible point or iteration limit (whichever comes first). `2`

(limit) Always run to the iteration limit.

**mip_implications** *(boolean)*: Specifies whether or not to add constraints to the MIP derived from logical implications ↵

Default:

`1`

value meaning `0`

(no) Do not add constraints from logical implications. `1`

(yes) Knitro adds constraints from logical implications.

**mip_integer_tol** *(real)*: This value specifies the threshold for deciding whether or not a variable is determined to be an integer ↵

Range: [

`0`

,`1`

]Default:

`1e-08`

**mip_integral_gap_abs** *(real)*: The absolute integrality gap stop tolerance for MIP ↵

Synonym: optca

Range: [

`-1`

, ∞]Default:

`GAMS optca`

**mip_integral_gap_rel** *(real)*: The relative integrality gap stop tolerance for MIP ↵

Synonym: optcr

Range: [

`-1`

, ∞]Default:

`GAMS optcr`

**mip_intvar_strategy** *(integer)*: Specifies how to handle integer variables ↵

Default:

`0`

value meaning `0`

(none) No special treatment applied. `1`

(relax) Relax all integer variables. `2`

(mpec) Convert all binary variables to complementarity constraints.

**mip_knapsack** *(integer)*: Specifies rules for adding MIP knapsack cuts ↵

Default:

`1`

value meaning `0`

(none) Do not add knapsack cuts. `1`

(ineqs) Add knapsack cuts derived from linear (in)equalities at the root node only. `2`

(lifted) Add lifted separation cuts derived at every node from the solution of the relaxation. `3`

(all) Add both root node cuts from (in)equalities and lifted separation cuts.

**mip_lpalg** *(integer)*: Specifies which algorithm to use for any linear programming (LP) subproblem solves that may occur in the MIP branch and bound procedure ↵

Specifies which algorithm to use for any linear programming (LP) subproblem solves that may occur in the MIP branch and bound procedure. LP subproblems may arise if the problem is a mixed integer linear program (MILP), or if using mip_method = HQG. (Nonlinear programming subproblems use the algorithm specified by the algorithm option.)

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose an algorithm, based on the problem characteristics. `1`

(direct) Use the Interior/Direct (barrier) algorithm. `2`

(cg) Use the Interior/CG (barrier) algorithm. `3`

(active) Use the Active Set (simplex) algorithm.

**mip_maxnodes** *(integer)*: Specifies the maximum number of nodes explored (0 means no limit) ↵

Synonym: nodlim

Range: {

`0`

, ..., ∞}Default:

`GAMS nodlim`

**mip_maxsolves** *(integer)*: Specifies the maximum number of subproblem solves allowed (0 means no limit) ↵

Range: {

`0`

, ..., ∞}Default:

`0`

**mip_maxtime_cpu** *(real)*: Specifies the maximum allowable CPU time in seconds for the complete MIP solution ↵

Specifies the maximum allowable CPU time in seconds for the complete MIP solution. Use maxtime_cpu to additionally limit time spent per subproblem solve.

Range: [

`0`

, ∞]Default:

`100000000`

**mip_maxtime_real** *(real)*: Specifies the maximum allowable real time in seconds for the complete MIP solution ↵

Specifies the maximum allowable real time in seconds for the complete MIP solution. Use maxtime_real to additionally limit time spent per subproblem solve.

Range: [

`0`

, ∞]Default:

`GAMS reslim`

**mip_method** *(integer)*: Specifies which MIP method to use ↵

Default:

`0`

value meaning `0`

(auto) Let Knitro automatically choose the method. `1`

(BB) Use the standard branch and bound method. `2`

(HQG) Use the hybrid Quesada-Grossman method (for convex, nonlinear problems only). `3`

(MISQP) Use mixed-integer SQP method (allows for non-relaxable integer variables).

**mip_mir** *(integer)*: Specifies rules for adding mixed integer rounding cuts ↵

Default:

`-1`

value meaning `-1`

(auto) Let Knitro decide whether to add mixed integer rounding cuts. `0`

(none) Do not add mixed integer rounding cuts. `1`

(all) Add cuts derived from equalities at every node depending on the solution of the relaxation and the cut generation strategy. `2`

(nlp) Add mixed-integer rounding cuts at the root node and for nonlinear constraints.

**mip_nodealg** *(integer)*: Specifies which algorithm to use for standard node subproblem solves in MIP (same options as algorithm user option) ↵

Range: {

`0`

, ...,`5`

}Default:

`0`

**mip_outinterval** *(integer)*: Specifies node printing interval for mip_outlevel when mip_outlevel > 0 ↵

Default:

`10`

value meaning `1`

Print output every node. `2`

Print output every 2nd node. `n`

Print output every Nth node.

**mip_outlevel** *(integer)*: Specifies how much MIP information to print ↵

Default:

`1`

value meaning `0`

(none) Do not print any MIP node information. `1`

(iters) Print one line of output for every node. `2`

(iterstime) Also print accumulated time for every node. `3`

(root) Also print detailed log from root node solve.

**mip_pseudoinit** *(integer)*: Specifies the method used to initialize pseudo-costs corresponding to variables that have not yet been branched on in the MIP method ↵

Default:

`0`

value meaning `0`

Let Knitro automatically choose the method. `1`

Initialize using the average value of computed pseudo-costs. `2`

Initialize using strong branching.

**mip_relaxable** *(boolean)*: Specifies Whether integer variables are relaxable ↵

Default:

`1`

value meaning `0`

(none) Integer variables are not relaxable. `1`

(all) All integer variables are relaxable.

**mip_rootalg** *(integer)*: Specifies which algorithm to use for the root node solve in MIP (same options as algorithm user option) ↵

Range: {

`0`

, ...,`5`

}Default:

`0`

**mip_rounding** *(integer)*: Specifies the MIP rounding rule to apply ↵

Default:

`-1`

value meaning `-1`

(auto) Let Knitro choose the rounding rule. `0`

(none) No rounding heuristic is used. `2`

(heur_only) Round using a fast heuristic only. `3`

(nlp_sometimes) Round and solve a subproblem if likely to succeed. `4`

(nlp_always) Always round and solve a subproblem.

**mip_selectdir** *(boolean)*: Specifies the MIP node selection direction rule (for tiebreakers) for choosing the next node in the branch and bound tree ↵

Default:

`0`

value meaning `0`

(down) Choose the down (i.e. <=) node first. `1`

(up) Choose the up (i.e. >=) node first.

**mip_selectrule** *(integer)*: Specifies the MIP select rule for choosing the next node in the branch and bound tree ↵

Default:

`0`

value meaning `0`

(auto) Let Knitro choose the node selection rule. `1`

(depth_first) Search the tree using a depth first procedure. `2`

(best_bound) Select the node with the best relaxation bound. `3`

(combo_1) Use depth first unless pruned, then best bound.

**mip_strong_candlim** *(integer)*: Specifies the maximum number of candidates to explore for MIP strong branching ↵

Range: {-∞, ..., ∞}

Default:

`10`

**mip_strong_level** *(integer)*: Specifies the maximum number of tree levels on which to perform MIP strong branching ↵

Range: {-∞, ..., ∞}

Default:

`10`

**mip_strong_maxit** *(integer)*: Specifies the maximum number of iterations to allow for MIP strong branching solves ↵

Range: {-∞, ..., ∞}

Default:

`1000`

**mip_terminate** *(integer)*: Specifies conditions for terminating the MIP algorithm ↵

Default:

`0`

value meaning `0`

(optimal) Terminate at optimum. `1`

(feasible) Terminate at first integer feasible point.

**mip_zerohalf** *(integer)*: Specifies rules for adding zero-half cuts ↵

Default:

`0`

value meaning `0`

(none) Do not add zero-half cuts. `1`

(root) Add cuts derived from equalities at the root node only. `2`

(tree) Add cuts derived from equalities at every node depending on the solution of the relaxation and the cut generation strategy. `3`

(all) Add cuts derived from equalities combining both root and tree cut generations.

**ms_deterministic** *(boolean)*: Indicates whether Knitro multi-start procedure will be deterministic (when ms_terminate = 0) ↵

Default:

`1`

value meaning `0`

(no) multithreaded multi-start is non-deterministic. `1`

(yes) multithreaded multi-start is deterministic (when ms_terminate = 0).

**ms_enable** *(boolean)*: Indicates whether Knitro will solve from multiple start points to find a better local minimum ↵

Default:

`0`

value meaning `0`

(no) Knitro solves from a single initial point. `1`

(yes) Knitro solves using multiple start points.

**ms_maxbndrange** *(real)*: Specifies the maximum range that an unbounded variable can take when determining new start points ↵

Specifies the maximum range that an unbounded variable can take when determining new start points. If a variable is unbounded in one or both directions, then new start point values are restricted by the option. If \(x_i\) is such a variable, then all initial values satisfy \(\max \{ b^L_i, x_i^0 - {\tt ms\_maxbndrange}/2 \} \leq x_i \leq \min \{ b^U_i, x_i^0 + {\tt ms\_maxbndrange}/2 \},\) where \(x_i^0\) is the initial value of \(x_i\) provided by the user, and \(b^L_i\) and \(b^U_i\) are the variable bounds (possibly infinite) on \(x_i\) . This option has no effect unless ms_enable = yes.

Range: [-∞, ∞]

Default:

`1000`

**ms_maxsolves** *(integer)*: Specifies how many start points to try in multi-start ↵

Specifies how many start points to try in multi-start. This option has no effect unless ms_enable = yes.

Default:

`0`

value meaning `0`

Let Knitro automatically choose a value based on the problem size. The value is min(200, 10 N), where N is the number of variables in the problem. `n`

Try n>0 start points.

**ms_maxtime_cpu** *(real)*: Specifies, in seconds, the maximum allowable CPU time before termination ↵

Specifies, in seconds, the maximum allowable CPU time before termination. The limit applies to the operation of Knitro since multi-start began; in contrast, the value of maxtime_cpu limits how long Knitro iterates from a single start point. Therefore, ms_maxtime_cpu should be greater than maxtime_cpu. This option has no effect unless ms_enable = yes.

Range: [-∞, ∞]

Default:

`100000000`

**ms_maxtime_real** *(real)*: Specifies, in seconds, the maximum allowable real time before termination ↵

Specifies, in seconds, the maximum allowable real time before termination. The limit applies to the operation of Knitro since multi-start began; in contrast, the value of maxtime_real limits how long Knitro iterates from a single start point. Therefore, ms_maxtime_real should be greater than maxtime_real. This option has no effect unless ms_enable = yes.

Range: [-∞, ∞]

Default:

`100000000`

**ms_num_to_save** *(integer)*: Specifies the number of distinct feasible points to save in a file named knitro_mspoints ↵

Specifies the number of distinct feasible points to save in a file named knitro_mspoints.log. Each point results from a Knitro solve from a different starting point, and must satisfy the absolute and relative feasibility tolerances. The file stores points in order from best objective to worst. Points are distinct if they differ in objective value or some component by the value of ms_savetol using a relative tolerance test. This option has no effect unless ms_enable = yes.

Range: {

`0`

, ..., ∞}Default:

`0`

**ms_outsub** *(boolean)*: Enable writing algorithm output to files for the parallel multistart procedure ↵

Default:

`0`

value meaning `0`

Do not write detailed algorithm output to files. `1`

Write detailed algorithm output to files named knitro_ms_*.log.

**ms_savetol** *(real)*: Specifies the tolerance for deciding if two feasible points are distinct ↵

Specifies the tolerance for deciding if two feasible points are distinct. Points are distinct if they differ in objective value or some component by the value of ms_savetol using a relative tolerance test. A large value can cause the saved feasible points in the file knitro_mspoints.log to cluster around more widely separated points. This option has no effect unless ms_enable = yes. and ms_num_to_save is positive.

Range: [-∞, ∞]

Default:

`1e-06`

**ms_seed** *(integer)*: Seed value used to generate random initial points in multi-start; should be a non-negative integer ↵

Range: {

`0`

, ..., ∞}Default:

`0`

**ms_startptrange** *(real)*: Specifies the maximum range that each variable can take when determining new start points ↵

Specifies the maximum range that each variable can take when determining new start points. If a variable has upper and lower bounds and the difference between them is less than or equal to ms_startptrange, then new start point values for the variable can be any number between its upper and lower bounds. If the variable is unbounded in one or both directions, or the difference between bounds is greater than ms_startptrange, then new start point values are restricted by the option. If \(x_i\) is such a variable, then all initial values satisfy \(\max \{ b^L_i, x_i^0 - \tau \} \leq x_i \leq \min \{ b^U_i, x_i^0 + \tau \}, \tau = \min \{ {\tt ms\_startptrange}/2, {\tt ms\_maxbndrange}/2 \}\) where \(x_i^0\) is the initial value of \(x_i\) provided by the user, and \(b^L_i\) and \(b^U_i\) are the variable bounds (possibly infinite) on \(x_i\) . This option has no effect unless ms_enable = yes.

Range: [-∞, ∞]

Default:

`1e+20`

**ms_terminate** *(integer)*: Specifies the condition for terminating multi-start ↵

Specifies the condition for terminating multi-start. This option has no effect unless ms_enable = yes.

Default:

`0`

value meaning `0`

Terminate after ms_maxsolves. `1`

Terminate after the first local optimal solution is found or ms_maxsolves, whichever comes first. `2`

Terminate after the first feasible solution estimate is found or ms_maxsolves, whichever comes first. `3`

Terminate after the first solution estimate of any type is found or ms_maxsolves, whichever comes first.

**names** *(boolean)*: Enable to pass variable and equation names to Knitro ↵

Default:

`0`

**newpoint** *(integer)*: Specifies additional action to take after every iteration in a solve of a continuous problem ↵

Specifies additional action to take after every iteration in a solve of a continuous problem. An iteration of Knitro results in a new point that is closer to a solution. The new point includes values of x and Lagrange multipliers lambda. The "newpoint" feature in Knitro is currently only available for continuous problems (solved via KN_solve()).

Default:

`0`

value meaning `0`

(none) Knitro takes no additional action. `1`

(saveone) Knitro writes x and lambda to the file knitro_newpoint.log. Previous contents of the file are overwritten. `2`

(saveall) Knitro appends x and lambda to the file knitro_newpoint.log. Warning: this option can generate a very large file. All iterates, including the start point, crossover points, and the final solution are saved.

**objrange** *(real)*: Specifies the extreme limits of the objective function for purposes of determining unboundedness ↵

Specifies the extreme limits of the objective function for purposes of determining unboundedness. If the magnitude of the objective function becomes greater than objrange for a feasible iterate, then the problem is determined to be unbounded and Knitro proceeds no further.

Range: [

`0`

, ∞]Default:

`1e+20`

**option_file** *(string)*: additional option file name - read only by KNITRO solver lib ↵

**opttol** *(real)*: Specifies the final relative stopping tolerance for the KKT (optimality) error ↵

Specifies the final relative stopping tolerance for the KKT (optimality) error. Smaller values of opttol result in a higher degree of accuracy in the solution with respect to optimality.

Range: [

`0`

, ∞]Default:

`1e-06`

**opttolabs** *(real)*: Specifies the final absolute stopping tolerance for the KKT (optimality) error ↵

Synonym: opttol_abs

Specifies the final absolute stopping tolerance for the KKT (optimality) error. Smaller values of opttol_abs result in a higher degree of accuracy in the solution with respect to optimality.

Range: [

`0`

, ∞]Default:

`0.001`

**outappend** *(boolean)*: Specifies whether output should be started in a new file, or appended to existing files ↵

Specifies whether output should be started in a new file, or appended to existing files. The option affects knitro.log. It does not affect knitro_newpoint.log, which is controlled by option newpoint.

Default:

`0`

value meaning `0`

(no) Erase any existing files when opening for output. `1`

(yes) Append output to any existing files.

**outdir** *(string)*: Specifies a single directory as the location to write all output files ↵

Specifies a single directory as the location to write all output files. The option should be a full pathname to the directory, and the directory must already exist.

**outlev** *(integer)*: Controls the level of output produced by Knitro ↵

Default:

`2`

value meaning `0`

(none) Printing of all output is suppressed. `1`

(summary) Print only summary information. `2`

(iter_10) Print basic information every 10 iterations. `3`

(iter) Print basic information at each iteration. `4`

(iter_verbose) Print basic information and the function count at each iteration. `5`

(iter_x) Print all the above, and the values of the solution vector x. `6`

(all) Print all the above, and the values of the constraints c at x and the Lagrange multipliers lambda.

**outmode** *(integer)*: Specifies where to direct the output from Knitro ↵

Default:

`0`

value meaning `0`

(screen) Output is directed to standard out (e.g., screen). `1`

(file) Output is sent to a file named knitro.log. `2`

(both) Output is directed to both the screen and file knitro.log.

**outname** *(string)*: Use to specify a custom filename when output is written to a file using outmode ↵

**output_time** *(boolean)*: print output on where time is used ↵

Default:

`0`

**out_csvinfo** *(boolean)*: Controls whether or not to generates a file knitro_solve ↵

Controls whether or not to generates a file knitro_solve.csv containing solve information in comma separated format.

Default:

`0`

value meaning `0`

(no) No solution information file is generated. `1`

(yes) The knitro_solve.csv solution file is generated.

**out_csvname** *(string)*: Use to specify a custom csv filename when using out_csvinfo ↵

**out_hints** *(boolean)*: Specifies whether to print diagnostic hints (e.g. about user option settings) after solving ↵

Default:

`1`

value meaning `0`

(no) Do not print any hints. `1`

(yes) Print diagnostic hints on occasion.

**par_blasnumthreads** *(integer)*: Specify the number of threads to use for BLAS operations when blasoption = 1 ↵

Range: {

`0`

, ..., ∞}Default:

`0`

**par_lsnumthreads** *(integer)*: Specify the number of threads to use for linear system solve operations when linsolver = 6 ↵

Range: {

`0`

, ..., ∞}Default:

`0`

**par_msnumthreads** *(integer)*: Specify the number of threads to use for multistart (when ms_enable = 1) ↵

Specify the number of threads to use for multistart (when ms_enable = 1). 0 (auto) Let Knitro choose the number of threads (currently sets par_msnumthreads based on threads). n>0 Use n threads for the multistart (solve n problems in parallel).

Range: {

`0`

, ..., ∞}Default:

`0`

**presolve** *(boolean)*: Determine whether or not to use the Knitro presolver to try to simplify the model by removing variables or constraints ↵

Default:

`1`

value meaning `0`

(no) Do not use the Knitro presolver. `1`

(yes) Enable the Knitro presolver.

**presolveop_tighten** *(integer)*: Determine whether or not to enable the Knitro presolve operation to tighten variable bounds ↵

Default:

`-1`

value meaning `-1`

(auto) Automatically determined (may depend on the algorithm). `0`

(none) Do not tighten variable bounds (unless it removes a constraint). `1`

(varbnd) Enable tightening variable bounds always.

**presolve_initpt** *(integer)*: Control whether the Knitro presolver can shift a user-supplied initial point ↵

Default:

`-1`

value meaning `-1`

(auto) Let Knitro automatically choose whether to allow shifting. `0`

(noshift) Do not allow presolver to shift user-supplied initial point. `1`

(linshift) Allow presolver to shift user-supplied initial point if it only appears in linear constraints. `2`

(anyshift) Allow presolver to shift any user-supplied initial point.

**presolve_level** *(integer)*: Set the level of presolve operations to enable through the Knitro presolver ↵

Set the level of presolve operations to enable through the Knitro presolver. A higher presolve level enables more complex presolve operations.

Default:

`-1`

value meaning `-1`

(auto) Let Knitro automatically choose the presolve level. `1`

(level1) Enable the most basic presolve operations. `2`

(level2) Enable more advanced presolve operations.

**presolve_passes** *(integer)*: Set a maximum limit on the number of passes through the Knitro presolve operations ↵

Range: {

`0`

, ..., ∞}Default:

`10`

**presolve_tol** *(real)*: Determines the tolerance used by the Knitro presolver to remove variables and constraints from the model ↵

Determines the tolerance used by the Knitro presolver to remove variables and constraints from the model. If you believe the Knitro presolver is incorrectly modifying the model, use a smaller value for this tolerance (or turn the presolver off).

Range: [

`0`

, ∞]Default:

`1e-06`

**restarts** *(integer)*: Specifies whether or not to enable automatic restarts in Knitro ↵

Specifies whether or not to enable automatic restarts in Knitro. When enabled, if a Knitro algorithm seems to be converging slowly or not converging, the algorithm will automatically restart, which may help with convergence.

Default:

`0`

value meaning `0`

No automatic restarts allowed. `n`

At most n>0 automatic restarts may be performed.

**restarts_maxit** *(integer)*: When restarts are enabled, this option can be used to specify a maximum number of iterations before enforcing a restart ↵

Default:

`0`

value meaning `0`

No iteration limit on restarts enforced. `n`

At most n>0 iterations are allowed without convergence before enforcing an automatic restart, if restarts are enabled.

**scale** *(integer)*: Specifies whether to perform problem scaling of the objective function, constraint functions, or possibly variables ↵

Specifies whether to perform problem scaling of the objective function, constraint functions, or possibly variables. If scaling is performed, internal computations, including some aspects of the optimality tests, are based on the scaled values, though the feasibility error is always computed in terms of the original, unscaled values.

Default:

`1`

value meaning `0`

(no) No scaling is performed. `1`

(user_internal) User provided scaling is used if defined, otherwise Knitro internal scaling is applied. `2`

(user_none) User provided scaling is used if defined, otherwise no scaling is applied. `3`

(internal) Knitro internal scaling is applied.

**soc** *(integer)*: Specifies whether or not to try second order corrections (SOC) ↵

Specifies whether or not to try second order corrections (SOC). A second order correction may be beneficial for problems with highly nonlinear constraints.

Default:

`1`

value meaning `0`

(no) No second order correction steps are attempted. `1`

(maybe) Second order correction steps may be attempted on some iterations. `2`

(yes) Second order correction steps are always attempted if the original step is rejected and there are nonlinear constraints.

**strat_warm_start** *(boolean)*: Specifies whether or not to invoke a warm-start strategy ↵

Specifies whether or not to invoke a warm-start strategy. A warm-start strategy may be beneficial when an initial point close to the solution can be provided. For example, this may occur when solving a sequence of closely related problems, and the solution from one problem can be used to initialize (or warm-start) the next problem in the sequence. The Knitro warm-start strategy will use this information to tune the algorithms to try to converge more quickly in this case. If the initial point is not sufficiently close to the solution, or is too infeasible, the warm-start strategy may not be helpful. This option is currently only used for the Knitro barrier/interior-point algorithms. In this case it may also be useful to experiment with different (smaller than default) values for the initial barrier parameter bar_initmu. In general, the closer the initial point is to the solution, the smaller this value should be (Knitro will try by default to initialize this to a good value when applying a warm-start strategy).

Default:

`0`

value meaning `0`

(no) No warm-start strategy is applied. `1`

(yes) Knitro will apply a warm-start strategy with special tunings.

**threads** *(integer)*: default thread count ↵

Synonyms: gthreads par_numthreads

Controls the number of threads to use. Non-positive values are interpreted as the number of cores to leave free so setting

`threads`

to 0 uses all available cores while setting`threads`

to -1 leaves one core free for other tasks.By default, Knitro decides automatically how to use the threads specified. For example, if the multi-start method is enabled, it can run in parallel threads. If the multi-algorithm

`algorithm=5`

is selected, the different algorithms can be run in parallel threads if threads are allocated. In case only one algorithm is running, multiple threads can be allocated to the MKL BLAS library or to the PARDISO linear solver via the`threads`

option: see the`blasoption`

,`par_blasnumthreads`

, and`par_lsnumthreads`

options for details.Range: {-∞, ..., ∞}

Default:

`GAMS threads`

**tuner** *(boolean)*: Indicates whether to invoke the Knitro-Tuner ↵

Default:

`0`

value meaning `0`

(off) Do not invoke the Knitro-Tuner. `1`

(on) Invoke the Knitro-Tuner.

**tuner_maxtimecpu** *(real)*: Specifies, in seconds, the maximum allowable CPU time before terminating the Knitro-Tuner ↵

Specifies, in seconds, the maximum allowable CPU time before terminating the Knitro-Tuner. The limit applies to the operation of Knitro since the Knitro- Tuner began. In contrast, the value of maxtime_cpu places a time limit on each individual Knitro-Tuner solve for a particular option setting. Therefore, tuner_maxtime_cpu should be greater than maxtime_cpu. This option has no effect unless tuner = on.

Range: [

`0`

, ∞]Default:

`100000000`

**tuner_maxtimereal** *(real)*: Specifies, in seconds, the maximum allowable real time before terminating the Knitro-Tuner ↵

Specifies, in seconds, the maximum allowable real time before terminating the Knitro-Tuner. The limit applies to the operation of Knitro since the Knitro- Tuner began. In contrast, the value of maxtime_real places a time limit on each individual Knitro-Tuner solve for a particular option setting. Therefore, tuner_maxtime_real should be greater than maxtime_real. This option has no effect unless tuner = on.

Range: [

`0`

, ∞]Default:

`100000000`

**tuner_optionsfile** *(string)*: Can be used to specify the location of a Tuner options file ↵

**tuner_outsub** *(integer)*: Enable writing additional Tuner subproblem solve output to files for the Knitro-Tuner procedure (tuner=1) ↵

Default:

`0`

value meaning `0`

Do not write detailed solve output to files. `1`

Write summary solve output to a file named knitro_tuner_summary.log. `2`

Write detailed individual solve output to files named knitro_tuner_*.log.

**tuner_terminate** *(integer)*: Define the termination condition for the Knitro-Tuner procedure (tuner=1) ↵

Default:

`0`

value meaning `0`

Terminate after all solves have completed. `1`

Terminate at first locally optimal solution. `2`

Terminate at first feasible solution estimate. `3`

Terminate at first solution estimate of any type.

**xtol** *(real)*: The optimization process will terminate if the relative change in all components of the solution point estimate is less than xtol for xtol_iters ↵

The optimization process will terminate if the relative change in all components of the solution point estimate is less than xtol for xtol_iters. consecutive iterations. If using the Interior/Direct or Interior/CG algorithm and the barrier parameter is still large, Knitro will first try decreasing the barrier parameter before terminating.

Range: [

`0`

, ∞]Default:

`1e-12`

**xtol_iters** *(integer)*: The optimization process will terminate if the relative change in the solution estimate is less than xtol for xtol_iters consecutive iterations ↵

The optimization process will terminate if the relative change in the solution estimate is less than xtol for xtol_iters consecutive iterations. If set to 0, Knitro chooses this value based on the solver and context. Currently Knitro sets this value to 3 unless the MISQP algorithm is being used, in which case the value is set to 1 by default.

Range: {

`0`

, ..., ∞}Default:

`0`

# Knitro Termination Test and Optimality

## Continuous problems

The first-order conditions for identifying a locally optimal solution of the problem (1) are:

\[ \tag{3} \begin{array}{rll} \displaystyle \nabla_x {\cal L}(x,\lambda) = \nabla f(x) + \sum_{i=1 \dots m} \lambda_i^c \nabla c_i(x) + \sum_{j=1 \dots n} \lambda_j^b & = 0 \\ \displaystyle \lambda_i^c \min [(c_i(x)-c_i^L),(c_i^U-c_i(x))] & = 0, & i=1 \dots m \\ \displaystyle \lambda_j^b \min [(x_j-b_j^L),(b_j^U-x_j)] & = 0, & j=1 \dots n \\ \displaystyle c_i^L \leq c_i(x) & \leq c_i^U, & i=1 \dots m \\ \displaystyle b_j^L \leq x_j & \leq b_j^U, & j=1 \dots n \\ \displaystyle \lambda_i^c & \geq 0, & i \in {\cal I}, \ c_i^L=-\infty,\ c_i^U\ \mbox{finite} \\ \displaystyle \lambda_i^c & \leq 0, & i \in {\cal I}, \ c_i^U=+\infty,\ c_i^L\ \mbox{finite} \\ \displaystyle \lambda_j^b & \geq 0, & j \in {\cal B}, \ b_j^L=-\infty,\ b_j^U\ \mbox{finite} \\ \displaystyle \lambda_j^b & \leq 0, & j \in {\cal B}, \ b_j^U=+\infty,\ b_j^L\ \mbox{finite} \end{array} \]

where \({\cal I}\) and \({\cal B}\) represent the sets of indices corresponding to the general inequality constraints and non-fixed variable bound constraints respectively, \(\lambda_i^c\) is the Lagrange multiplier corresponding to constraint \(c_i(x)\), and \(\lambda_j^b\) is the Lagrange multiplier corresponding to the simple bounds on \(x_j\). There is exactly one Lagrange multiplier for each constraint and variable. The Lagrange multiplier may be restricted to take on a particular sign depending on the corresponding constraint or variable bounds.

In Knitro we define the feasibility error (`FeasErr`

) at a point \(x^k\) to be the maximum violation of the constraints of (1), i.e.,

\[ \mbox{FeasErr} = \max_{i=1 \dots m, \ j=1 \dots n} (0, (c_i^L-c_i(x^k)), (c_i(x^k)-c_i^U), (b_j^L-x_j^k), (x_j^k-b_j^U)), \]

while the optimality error (`OptErr`

) is defined as the maximum violation of the first three conditions of (3)

\[ \mbox{OptErr} = \max_{i=1 \dots m, \ j=1 \dots n} (\|\nabla_x {\cal L}(x^k,\lambda^k) \|_\infty, \lambda_i^c \min [(c_i(x)-c_i^L),(c_i^U-c_i(x))], \lambda_j^b \min [(x_j-b_j^L),(b_j^U-x_j)]). \]

The remaining conditions on the sign of the multipliers are enforced explicitly throughout the optimization. In order to take into account problem scaling in the termination test, the following scaling factors are defined In order to take into account problem scaling in the termination test, the following scaling factors are defined

\begin{align*} \tau_1 & = \max (1, (c_i^L-c_i(x^0)), (c_i(x^0)-c_i^U),(b_j^L-x_j^0), , (x_j^0-b_j^U))), \\ \tau_2 & = \begin{cases} \max (1, \|\nabla f(x^k)\|_\infty), & \text{for constrained problems}, \\ \max (1, \min(|f(x^k)| , \|\nabla f(x^0)\|_\infty)), & \text{for unconstrained problems}, \end{cases} \end{align*}

where \(x^0\) represents the initial point. The special treatment for unconstraints problems is necessary, as for these problems, \(\|\nabla f(x^k)\|_\infty \rightarrow 0\) as a solution is approached, thus \(\max (1, \|\nabla f(x^k)\|_\infty)\) would not be effective.

Knitro stops and declares `Locally optimal solution found`

if the following stopping conditions are satisfied:

\begin{equation} \tag{4} \mbox{FeasErr} \le \max (\tau_1*\mbox{feastol},\mbox{feastolabs}) \end{equation}

\begin{equation}\tag{5} \mbox{OptErr} \le \max (\tau_2*\mbox{opttol}, \mbox{opttolabs}) \end{equation}

where feastol, opttol, feastolabs and opttolabs are user-defined options (see section Usage ).

This stopping test is designed to give the user much flexibility in deciding when the solution returned by Knitro is accurate enough. One can use a purely scaled stopping test (which is the recommended and default option) by setting feastolabs and opttolabs equal to `0.0e0`

. Likewise, an absolute stopping test can be enforced by setting feastol and opttol equal to `0.0e0`

.

**Unbounded problems**

Since by default Knitro uses a relative/scaled stopping test it is possible for the optimality conditions to be satisfied for an unbounded problem. For example, if \(\tau_2 \to \infty\) while the optimality error `OptErr`

stays bounded, condition (5) will eventually be satisfied for some `opttol>0`

. If you suspect that your problem may be unbounded, using an absolute stopping test will allow Knitro to detect this.

## Discrete problems

Algorithms for solving versions of (1) where one or more of the variables are restricted to take on only discrete values, proceed by solving a sequence of continuous relaxations, where the discrete variables are *relaxed* such that they can take on any continuous value. The *global* solutions \(f(x_R)\) of these relaxed problems provide a lower bound on the optimal objective value for problem (1) (upper bound if maximizing). If a feasible point is found for problem (1) that satisfies the discrete restrictions on the variables, then this provides an upper bound on the optimal objective value of problem (1) (lower bound if maximizing). We will refer to these feasible points as *incumbent* points and denote the objective value at an incumbent point by \(f(x_I)\). Assuming all the continuous subproblems have been solved to global optimality (if the problem is convex, all local solutions are global solutions), an optimal solution of problem (1) is verified when the lower bound and upper bound are equal.

Knitro declares optimality for a discrete problem when the gap between the best (i.e., largest) lower bound \(f(x_R)\) and the best (i.e., smallest) upper bound \(f(x_I)\) is less than a threshold determined by the user options mip_integral_gap_abs and mip_integral_gap_rel. Specifically, Knitro declares optimality when either

\[ f(x_I) - f(x_R) \leq mip\_integral\_gap\_abs \]

or

\[ f(x_I) - f(x_R) \leq mip\_integral\_gap\_rel \cdot \max (1,|f(x_I)|), \]

where mip_integral_gap_abs and mip_integral_gap_rel are typically small positive numbers. Since these termination conditions assume that the continuous subproblems are solved to global optimality and Knitro only finds local solutions of nonconvex, continuous optimization problems, they are only reliable when solving convex, mixed integer problems. The integrality gap \(f(x_I) - f(x_R)\) should be non-negative although it may become slightly negative from roundoff error, or if the continuous subproblems are not solved to sufficient accuracy. If the integrality gap becomes largely negative, this may be an indication that the model is nonconvex, in which case `Knitro`

may not converge to the optimal solution, and will be unable to verify optimality (even if it claims otherwise).

Note that the default values for mip_integral_gap_abs and mip_integral_gap_rel are taken from the GAMS options optCA and optCR, but an explicit setting of mip_integral_gap_abs or mip_integral_gap_rel will override those.

# Knitro Output

If `outlev=0`

then all printing of output is suppressed. The description below assumes the default output level (`outlev=2`

) except where indicated:

**Nondefault Options:**

This output lists all user options (see section Usage) which are different from their default values. If nothing is listed in this section then all user options are set to their default values.

**Problem Characteristics:**

The output begins with a description of the problem characteristics.

**Iteration Information - Continuous Problems:**

An iteration, in the context of Knitro, is defined as a step which generates a new solution estimate (i.e., a successful step). The columns of the iteration log are as follows:

`Iter`

Iteration number.`fCount`

The cumulative number of function evaluations, only included if (`outlev>3`

)`Objective`

Gives the value of the objective function at the current iterate.`FeasErr`

Gives a measure of the feasibility violation at the current iterate.`OptErr`

Gives a measure of the violation of the Karush-Kuhn-Tucker (KKT) (first-order) optimality conditions (not including feasibility) at the current iterate.`||Step||`

The 2-norm length of the step (i.e., the distance between the new iterate and the previous iterate).`CG its`

The number of Projected Conjugate Gradient (CG) iterations required to compute the step.

If `outlev=2`

, information is printed every 10 major iterations. If `outlev=3`

information is printed at each major iteration. If `outlev>4`

addition information is included in the log.

**Iteration Information - Discrete Problems**:

By default, the GAMS/Knitro link prints a log line at every 10'th node. This frequency can be changed via the mip_outinterval option. To turn off the node log completely, set the mip_outlevel option to 0. The columns of the iteration log for discrete models are as follows:

`Node`

The node number. If an integer feasible point was found at a given node, it is marked with a *`Left`

The current number of active nodes left in the branch and bound tree.`Iinf`

The current number of active nodes left in the branch and bound tree.`Objective`

Gives the value of the objective function at the solution of the relaxed subproblem solved at the current node. If the subproblem was infeasible or failed, this is indicated. Additional symbols may be printed at some nodes if the node was pruned (`pr`

), integer feasible (`f`

), or an integer feasible point was found through rounding (`r`

).`Best relaxatn`

The value of the current best relaxation (lower bound on the solution if minimizing).`Best incumbent`

The value of the current best integer feasible point (upper bound on the solution if minimizing).

**Termination Message:** At the end of the run a termination message is printed indicating whether or not the optimal solution was found and if not, why the solver terminated. Below is a list of some possible termination messages.

`EXIT: Locally optimal solution found.`

Knitro found a locally optimal point which satisfies the stopping criterion (see section Knitro Termination Test and Optimality) for more detail on

program), then this point corresponds to a globally optimal solution.

`EXIT: Iteration limit reached.`

The iteration limit was reached before being able to satisfy the required stopping criteria.

`EXIT: Convergence to an infeasible point. Problem appears to be locally infeasible.`

The algorithm has converged to an infeasible point from which it cannot further decrease the infeasibility measure. This happens when the problem is infeasible, but may also occur on occasion for feasible problems with nonlinear constraints or badly scaled problems. It is recommended to try various initial points. If this occurs for a variety of initial points, it is likely the problem is infeasible.

`EXIT: Problem appears to be unbounded.`

The objective function appears to be decreasing without bound, while satisfying the constraints.

`EXIT: Current point cannot be improved.`

No more progress can be made. If the current point is feasible it is likely it may be optimal, however the stopping tests cannot be satisfied perhaps because of degeneracy, ill-conditioning or bad scaling).

`EXIT: Current point cannot be improved. Point appears to be optimal, but desired accuracy could not be achieved.`

No more progress can be made, but the stopping tests are close to being satisfied (within a factor of 100) and so the current approximate solution is believed to be optimal.

`EXIT: Time limit reached.`

The time limit was reached before being able to satisfy the required stopping criteria.

`EXIT: Evaluation error.`

This termination value indicates that an evaluation error occurred (e.g., divide by 0, taking the square root of a negative number), preventing the optimization from continuing.

`EXIT: Not enough memory available to solve problem.`

This termination value indicates that there was not enough memory available to solve the problem.

**Final Statistics:**

Following the termination message some final statistics on the run are printed. Both relative and absolute error values are printed.

**Solution Vector/Constraints:**

If `outlev=5`

, the values of the solution vector are printed after the final statistics. If `outlev=6`

, the final constraint values are also printed before the solution vector and the values of the Lagrange multipliers (or dual variables) are printed next to their corresponding constraint or bound.

# Algorithm Options

## Automatic

By default, `Knitro`

will automatically try to choose the best optimizer for the given problem based on the problem characteristics.

## Interior/Direct

If the Hessian of the Lagrangian is ill-conditioned or the problem does not have a large-dense Hessian, it may be advisable to compute a step by directly factoring the KKT (primal-dual) matrix rather than using an iterative approach to solve this system. Knitro offers the Interior/Direct optimizer which allows the algorithm to take direct steps by setting `algorithm=1`

. This option will try to take a direct step at each iteration and will only fall back on the iterative step if the direct step is suspected to be of poor quality, or if negative curvature is detected.

Using the Interior/Direct optimizer may result in substantial improvements over Interior/CG when the problem is ill-conditioned (as evidenced by Interior/CG taking a large number of Conjugate Gradient iterations). We encourage the user to try both options as it is difficult to predict in advance which one will be more effective on a given problem. In each case, also experiment with the bar_murule option, as it is difficult to predict which update rule will work best.

**NOTE:** Since the Interior/Direct algorithm in Knitro requires the explicit storage of a Hessian matrix, this version can only be used with Hessian options, `hessopt=1, 2, 3`

or `6`

. It may not be used with Hessian options, `hessopt=4`

or `5`

, which only provide Hessian-vector products. Both the Interior/Direct and Interior/CG methods can be used with the bar_feasible option.

## Interior/CG

Since Knitro was designed with the idea of solving large problems, the Interior/CG optimizer in Knitro offers an iterative Conjugate Gradient approach to compute the step at each iteration. This approach has proven to be efficient in most cases and allows Knitro to handle problems with large, dense Hessians, since it does not require factorization of the Hessian matrix. The Interior/CG algorithm can be chosen by setting `algorithm=2`

. It can use any of the Hessian options as well as the bar_feasible option.

## Active Set

Knitro includes an active-set Sequential Linear-Quadratic Programing (SLQP) optimizer. This optimizer is particular advantageous when "warm starting" (i.e., when the user can provide a good initial solution estimate, for example, when solving a sequence of closely related problems). This algorithm is also the preferred algorithm for detecting infeasible problems quickly. The Active Set algorithm can be chosen by setting `algorithm=3`

. It can use any of the Hessian options.

# Other Knitro special features

This section describes in more detail some of the more important special features of Knitro and provides some guidance on how use them so that Knitro runs most efficiently for the problem at hand.

## Second derivative options

The default version of Knitro assumes that exact second derivatives of the objective function and constraint functions can be computed. If this is possible and the cost of computing the second derivatives is not overly expensive, it is highly recommended to use exact second derivatives. However, Knitro also offers other options which are described in detail below.

**(Dense) Quasi-Newton BFGS**

The quasi-Newton BFGS option uses gradient information to compute a symmetric, *positive-definite* approximation to the Hessian matrix. Typically this method requires more iterations to converge than the exact Hessian version. However, since it is only computing gradients rather than Hessians, this approach may be more efficient in many cases. This option stores a *dense* quasi-Newton Hessian approximation so it is only recommended for small to medium problems ( \(n < 1000\)). The quasi-Newton BFGS option can be chosen by setting options value `hessopt=2`

.

**(Dense) Quasi-Newton SR1**

As with the BFGS approach, the quasi-Newton SR1 approach builds an approximate Hessian using gradient information. However, unlike the BFGS approximation, the SR1 Hessian approximation is not restricted to be positive-definite. Therefore the quasi-Newton SR1 approximation may be a better approach, compared to the BFGS method, if there is a lot of negative curvature in the problem since it may be able to maintain a better approximation to the true Hessian in this case. The quasi-Newton SR1 approximation maintains a *dense* Hessian approximation and so is only recommended for small to medium problems ( \(n < 1000\)). The quasi-Newton SR1 option can be chosen by setting options value `hessopt=3`

.

**Finite-difference Hessian-vector product option**

If the problem is large and gradient evaluations are not the dominate cost, then Knitro can internally compute Hessian-vector products using finite-differences. Each Hessian-vector product in this case requires one additional gradient evaluation. This option can be chosen by setting options value `hessopt=4`

. This option is generally only recommended if the exact gradients are provided.

**NOTE:** This option may not be used when `algorithm=1`

.

**Exact Hessian-vector products**

In some cases the problem which the user wishes to solve may have a large, dense Hessian which makes it impractical to store or work with the Hessian directly. The performance of this option should be nearly identical to the exact Hessian option but requires much less storage. This option can be chosen by setting options value `hessopt=5`

.

**NOTE**: This option may not be used when `algorithm=1`

.

**Limited-memory Quasi-Newton BFGS**

The limited-memory quasi-Newton BFGS option is similar to the dense quasi-Newton BFGS option described above. However, it is better suited for large-scale problems since, instead of storing a dense Hessian approximation, it only stores a limited number of gradient vectors used to approximate the Hessian. In general it requires more iterations to converge than the dense quasi-Newton BFGS approach but will be much more efficient on large-scale problems. This option can be chosen by setting options value `hessopt=6`

.

## Feasible version

Knitro offers the user the option of forcing intermediate iterates to stay feasible with respect to the *inequality* constraints (it does not enforce feasibility with respect to the *equality* constraints however). Given an initial point which is *sufficiently* feasible with respect to all inequality constraints and selecting `bar_feasible = 1`

, forces all the iterates to strictly satisfy the inequality constraints throughout the solution process. For the feasible mode to become active the iterate \(x\) must satisfy

\begin{equation}\tag{21} cl + tol \le c(x) \le cu - tol \end{equation}

for *all* inequality constraints (i.e., for \(cl \ne cu\)). The tolerance \(tol>0\) by which an iterate must be strictly feasible for entering the feasible mode is determined by the parameter `bar_feasmodetol`

which is `1.0e-4`

by default. If the initial point does not satisfy (21) then the default infeasible version of Knitro will run until it obtains a point which is sufficiently feasible with respect to all the inequality constraints. At this point it will switch to the feasible version of Knitro and all subsequent iterates will be forced to satisfy the inequality constraints.

For a detailed description of the feasible version of Knitro see [50] .

**NOTE:** This option may only be used when `algorithm=2`

.

## Honor Bounds

By default Knitro does not enforce that the simple bounds on the variables (1c) are satisfied throughout the optimization process. Rather, satisfaction of these bounds is only enforced at the solution. In some applications, however, the user may want to enforce that the initial point and all intermediate iterates satisfy the bounds \(bl \le x \leq bu\). This can be enforced by setting `honorbnds=1`

.

## Crossover

Interior-point (or barrier) methods are a powerful tool for solving large-scale optimization problems. However, one drawback of these methods is that they do not always provide a clear picture of which constraints are active at the solution. In general they return a less exact solution and less exact sensitivity information. For this reason, Knitro offers a crossover feature in which the interior-point method switches to the Active Set method at the interior-point solution estimate, in order to "clean up" the solution and provide more exact sensitivity and active set information. The crossover procedure is controlled by the bar_maxcrossit option. If this option is greater than 0, then Knitro will attempt to perform bar_maxcrossit Active Set crossover iterations after the interior-point method has finished, to see if it can provide a more exact solution. This can be viewed as a form of post-processing. If bar_maxcrossit is not positive, then no crossover iterations are attempted.

The crossover procedure will not always succeed in obtaining a more exact solution compared with the interior-point solution. If crossover is unable to improve the solution within bar_maxcrossit crossover iterations, then it will restore the interior-point solution estimate and terminate. By default, Knitro will then print a message indicating that it was unable to improve the solution within the iterations allowed. In this case, you may want to increase the value of bar_maxcrossit and try again. If Knitro determines that the crossover procedure will not succeed, no matter how many iterations are tried, then a message of the form `Crossover mode unable to improve solution.`

will be printed.

The extra cost of performing crossover is problem dependent. In most small or medium scale problems, the crossover cost is a small fraction of the total solve cost. In these cases it may be worth using the crossover procedure to obtain a more exact solution. On some large scale or difficult degenerate problems, however, the cost of performing crossover may be significant. It is recommended to experiment with this option to see whether improvement in the exactness of the solution is worth the additional cost.

## Tuner

The Knitro-Tuner can help you identify some non-default options settings that may improve performance on a particular model or set of models. The Knitro tuner is enabled with the tuner option and controlled via the tuner_ family of options. If you are unsure about what Knitro options should be tuned to try to improve performance, you can run the default Knitro-Tuner by simply setting the option tuner=1 when solving with Knitro. This will cause Knitro to run your model with a variety of automatically determined option settings, and report some statistics at the end. Any Knitro options that have been set in the usual way will remain fixed throughout the tuning procedure.

If you have some ideas about which Knitro options you want to tune, you can tell Knitro which options you want it to tune, as well as specify the values for particular options that you want Knitro to explore. This can be done by specifying a Tuner options file. A Tuner options file is a simple text file that is similar to a standard Knitro options file, with some important differences:

- You can define multiple values (separated by spaces) for each option. This tells Knitro the values you want it to explore.
- You can specify an option name without any values. This will tell Knitro to explore all possible option values for that option. This only works for options that have a finite set of possible option value settings.
- A Tuner options file is loaded via the tuner_optionsfile option.

All possible combinations of options/values specified in a Tuner options file will be explored by Knitro, while any Knitro options that have been set in the usual way will remain fixed throughout the tuning procedure.

## Solving Systems of Nonlinear Equations

Knitro is quite effective at solving systems of nonlinear equations. To solve a square system of nonlinear equations using Knitro one should specify the nonlinear equations as equality constraints (i.e., constraints with \(cl = cu\)), and specify the objective function (1a) as zero (i.e., \(f(x)=0\)).

## Solving Least Squares Problems

There are two ways of using Knitro for solving problems in which the objective function is a sum of squares of the form

\[ f(x) = \textstyle\frac{1}{2} \sum_{j=1}^q r_j(x)^2. \]

If the value of the objective function at the solution is not close to zero (the large residual case), the least squares structure of \(f\) can be ignored and the problem can be solved as any other optimization problem. Any of the Knitro options can be used.

On the other hand, if the optimal objective function value is expected to be small (small residual case) then Knitro can implement the Gauss-Newton or Levenberg-Marquardt methods which only require first derivatives of the residual functions, \(r_j(x)\), and yet converge rapidly. To do so, the user need only define the Hessian of \(f\) to be

\[ \nabla^2 f(x) = J(x)^TJ(x), \]

where

\[ J(x) = \left[ \frac{\partial r_j}{\partial x_i} \right]_{\begin{array}{c} j=1,2,\dots,q \\ i=1,2,\dots,n \end{array}}. \]

The actual Hessian is given by

\[ \nabla^2 f(x) = J(x)^T J(x) + \sum_{j=1}^q r_j(x) \nabla^2 r_j(x); \]

the Gauss-Newton and Levenberg-Marquardt approaches consist of ignoring the last term in the Hessian.

Knitro will behave like a Gauss-Newton method by setting `algorithm=1`

, and will be very similar to the classical Levenberg-Marquardt method when `algorithm=2`

. For a discussion of these methods see, for example, [192] .