USING CONOPT WITH AMPL
Using CONOPT with AMPL
AMPL/CONOPT is an optimization system for nonlinear mathematical programs in
continuous variables. It has been developed jointly by AMPL Optimization LLC, responsible for
the AMPL/CONOPT interface, and ARKI Consulting & Development A/S, responsible for the
CONOPT solution engine. Sales are handled by AMPL Optimization LLC.
This supplement to AMPL: A Modeling Language for Mathematical Programming
describes the most important features of CONOPT for users of AMPL.
Section 1 describes the kinds of problems to which CONOPT is applicable, and section 2
explains how solver specific options can be passed from AMPL to CONOPT. Section 3 describes
the iteration log, section 4 describes the many types of termination messages that CONOPT can
produce, and section 5 discusses Function Evaluation Errors. Appendix A gives a short overview
over the CONOPT algorithm. Appendix B gives a list of the options that control the interface
between AMPL and CONOPT and Appendix C gives a list of the options that control the
CONOPT algorithm. The solve_result_num values and the corresponding text string in the
solve_message text is returned by a solve statement are given in Appendix D. References are
given in Appendix E.
1 Applicability
CONOPT is designed to solve “smooth” nonlinear programs as described in chapter 13 of
AMPL: A Modeling Language for Mathematical Programming (in the following referred to as
The AMPL Book). CONOPT can accommodate both smooth nonlinear functions in the objective
and in the constraints. When no objective is specified, CONOPT seeks a point that satisfies the
given constraints and thus can be used to solve systems of nonlinear equations and/or inequalities.
Non-smooth nonlinearities will also be accepted, but CONOPT is not designed for them; the
algorithm is based on the assumption that all functions are smooth and it will in general not
produce reliable results when they are not.
CONOPT can also be used to solve linear programs, but other solvers specifically designed
for linear programs will in general be more efficient.
CONOPT does not solve integer programs as described in Chapter 15 of the AMPL Book.
When presented with an integer program, CONOPT ignores the integrality restrictions on the
variables, as indicated by a message such as
CONOPT 3.014R: ignoring integrality of 10 variables
It then solves the continuous relaxation of the resulting problem, and returns a solution in which
some of the integer variables may have fractional values. Solvers that can handle integrality
constraints can be found at the AMPL website.
Like most other nonlinear programming solvers CONOPT will attempt to find a local
optimum, i.e., a solution that is the best in a neighborhood around the solution. Better solutions
may in general exist elsewhere in the solution space. Some models have the property that a local
optimum is also a global optimum, i.e., a solution that is the best among all solutions. Among
these models are convex optimization models, where the set of feasible solutions is convex and
1
, USING CONOPT WITH AMPL
the objective function is convex (minimization). It is the responsibility of the modeler to ensure
that the model is convex, that the model for some other reason only has one local solution, or that
the solution produced by CONOPT is an acceptable local solution.
Models with piecewise-linear terms as described in the AMPL Book (chapter 17 of the
second edition, 14 of the first) can be used with CONOPT. AMPL will automatically convert the
piecewise-linear terms into a sum of linear terms (assuming option pl_linearize has its default
value 1), send the latter to CONOPT, and convert the solution back; the conversion has the effect
of adding a variable to correspond to each linear piece. The piecewise-linear terms are
mathematically non-smooth, but AMPL’s expansion converts them into a sum of smooth terms
that satisfies the smoothness assumptions in CONOPT. If you use option pl_linearize 0
AMPL will send the non-smooth model to CONOPT and CONOPT will attempt to solve it as if it
was smooth; the result is a high likelihood that CONOPT will get stuck in one of the non-smooth
points.
Piecewise-linear terms can still give rise to difficulties due to non-convexities. They are
only safe provided they satisfy certain convexity rules: Any piecewise-linear term in a minimized
objective must be convex, i.e., its slopes must form an increasing sequence as in:
<<-1,1,3,5; -5,-1,0,1.5,3>> x[j]
Any piecewise-linear term in a maximized objective must be concave, i.e., its slopes must form a
decreasing sequence as in:
<<1,3; 1.5,0.5,0.25>> x[j]
In constraints, any piecewise-linear term must be either convex and on the left-hand side of a <
constraint (or equivalently, the right-hand side of a > constraint), or else concave and on the left-
hand side of a > constraint (or equivalently, the right side of a < constraint). Piecewise-linear
programs that violate the above rules are converted using integer variables, but CONOPT will
ignore the integrality and just issue a message like the one shown above and it may put the pieces
together in the wrong order and return a solution that does not correspond to AMPL’s definition
of the piecewise linear term.
Piecewise-linear terms can be used to convert certain non-smooth functions into a form
more suitable for CONOPT. Examples are abs, min, and max where abs(x) can be replaced by
<<0;-1,1>>x, min(0,x) by <<0;-1,0>>x, and max(0,x) by <<0;0,1>>x.
2 Controlling CONOPT from AMPL
In many instances, you can successfully use CONOPT by simply specifying a model and
data, setting the solver option to conopt, and typing solve. For larger or more difficult
nonlinear models, however, you may need to pass specific options to CONOPT to obtain the
desired results. You will also need options to get more detailed messages and iteration output that
may help you to diagnose problems.
To give directives to CONOPT, you must first assign an appropriate character string to the
AMPL option called conopt_options. When solve invokes CONOPT, CONOPT breaks this
string into a series of individual options. Here is an example:
2
, USING CONOPT WITH AMPL
ampl: model pindyck.mod;
ampl: data pindyck.dat;
ampl: option solver conopt;
ampl: option conopt_options 'workmeg=2 \
ampl? maxiter=2000';
ampl: solve;
CONOPT 3.14R: workmeg=2
maxiter=2000
CONOPT 3.14R: Locally optimal; objective 1170.486285
16 iterations; evals: nf = 35, ng = 0, nc = 58, nJ = 15, nH = 2, nHv = 13
All the directives described below have the form of an identifier, an = sign, and a value. You may
store any number of concatenated options in conopt_options. The example above shows how to
type all directives in one long string, using the \ character to indicate that the string continues on
the next line. Alternatively, you can list several strings, which AMPL will automatically
concatenate:
ampl: option conopt_options 'workmeg=2'
ampl? ' maxiter=2000';
In this form, you must take care to supply the space that goes between the options; here we have
put it before maxiter. Alternatively, when specifying only a few options, you can simply put
them all on one line:
ampl: option conopt_options 'workmeg=2 maxiter=2000';
If you have specified the directive above, and then want to set maxtime to 500 you may
think to type:
ampl: option conopt_options
ampl? ' maxtime=500';
This will replace the previous conopt_options string, however; the other previously specified
options such as workmeg and maxiter will revert to their default values. (CONOPT supplies a
default value for every option not explicitly specified; the defaults are indicated in the discussion
below and in Appendices B and C.) To append new options to conopt_options, use this form:
ampl: option conopt_options $conopt_options
ampl? ' maxtime=500';
The $ in front of an option name denotes the current value of that option, so this statement
appends more options to the current option string. Note the space before maxtime.
The available options can be divided into two groups: Interface options are related to the
way AMPL and CONOPT communicates with each other; they are described in Appendix B.
Algorithmic options control aspects of the CONOPT solution algorithm; they are described in
Appendix C.
3
, USING CONOPT WITH AMPL
3 Iteration Output
Following the AMPL conventions CONOPT will by default display very little output. You
may get something like:
CONOPT 3.14R: Locally optimal; objective 1170.486285
16 iterations; evals: nf = 35, ng = 0, nc = 58, nJ = 15, nH = 2, nHv = 13
The first line gives an identification of the solver, a classification of the solution status, and
the final objective function value. The second line gives some statistics: number of iterations and
number of function calls of various types: nf = number of objective function evaluations, ng =
number of gradient evaluations (this particular model has a linear objective function so the
gradient is constant and is not evaluated repeatedly), nc = number of constraint evaluations, nJ =
number of evaluations of the Jacobian of the constraints, nH = number of evaluations of the
Hessian of the Lagrangian function, and nHv = number of evaluations of the Hessian of the
Lagrangian multiplied by a vector.
To get more information from CONOPT you must increase the output level, outlev. With
outlev=2 general messages from CONOPT (except the iteration log) will go to stdout and the
model above may give something like:
CONOPT 3.14R: outlev=2
The model has 112 variables and 97 constraints
with 332 Jacobian elements, 80 of which are nonlinear.
The Hessian of the Lagrangian has 32 elements on the diagonal,
48 elements below the diagonal, and 64 nonlinear variables.
** Optimal solution. Reduced gradient less than tolerance.
CONOPT time Total 0.141 seconds
of which: Function evaluations 0.000 = 0.0%
1st Derivative evaluations 0.000 = 0.0%
2nd Derivative evaluations 0.000 = 0.0%
Directional 2nd Derivative 0.000 = 0.0%
CONOPT 3.14R: Locally optimal; objective 1170.486285
16 iterations; evals: nf = 35, ng = 0, nc = 58, nJ = 15, nH = 2, nHv = 13
The time spend in various types of function evaluation are listed. Function evaluations correspond
to nf + nc, 1st Derivative evaluation correspond to ng + nJ, 2nd Derivative evaluations correspond
to nH, and Directional 2nd Derivatives correspond to nHv. On problems that are solved quickly,
some times may be reported as zero, as in this example, due to the granularity of the timer.
With outlev=3 you will also get information about the individual iterations similar to the
following:
4