Couenne User Manual

couenne-user-manual

User Manual:

Open the PDF directly: View PDF .
Page Count: 13

couenne: a user's manual

couenne: a user’s manual

Pietro Belotti⋆

Dept. of Mathematical Sciences, Clemson University

Clemson SC 29634.

Abstract. This is a short user’s manual for the couenne open-source

software for global optimization. It provides downloading and installation

instructions, an explanation to all options available in couenne, and

suggestions on when to use some of its features.

1 Introduction

couenne is an Open Source code for solving Global Optimization problems, i.e.,

problems of the form

(P) min f(x)

s.t. gj(x)≤0∀j∈M

i≤xi≤xu

i∀i∈N0

xi∈Z∀i∈NI

0⊆N0,

where f:Rn→Rand, for all j∈M,gj:Rn→Rare multivariate (possibly

nonconvex) functions, n=|N0|is the number of variables, and x= (xi)i∈N0is

the n-vector of variables. We assume that fand all gj’s are factorable, i.e., they

are expressed as PhQkηhk(x), where all functions ηhk(x) are univariate.

couenne is part of the COIN-OR infrastructure for Operations Research

software1. It is a reformulation-based spatial branch&bound (sBB) [10,11,12],

and it implements:

–linearization;

–branching;

–heuristics to ﬁnd feasible solutions;

–bound reduction.

Its main purpose is to provide the Optimization community with an Open-

Source tool that can be specialized to handle speciﬁc classes of MINLP problems,

or improved by adding more eﬃcient linearization, branching, heuristic, and

bound reduction techniques.

⋆Email: pbelott@clemson.edu

1See http://www.coin-or.org

Web resources. The homepage of couenne is on the COIN-OR website:

http://www.coin-or.org/Couenne

and shows a brief description of couenne and some useful links. The couenne

project page can be found at https://projects.coin-or.org/Couenne. It provides

quick installation instructions and other useful information on the project.

Mailing lists. Questions, suggestions, complaints, and wish lists about couenne

can be sent to the mailing list address couenne@lists.coin-or.org. Visit

http://list.coin-or.org/mailman/listinfo/couenne for subscription options.

In order to submit bug reports, the COIN-OR framework uses a ticket sys-

tem2. If you think you have found a bug in couenne, you are encouraged to

https://projects.coin-or.org/Couenne/report

Tickets can also be submitted and discussed on the couenne ticket mailing list:

http://list.coin-or.org/mailman/listinfo/couenne-tickets

Licensing. couenne is Open-Source and is subject to the Eclipse Public Li-

cense [7]. As a user, you are responsible for checking that the use you make of

couenne abides by the EPL rules.

Remark. As for all software, couenne evolves. This manual is periodically

updated when new features are added to couenne, therefore the version you

are reading may not be the latest one. Check http://www.coin-or.org/Couenne

for the updated version.

2 Download and installation

As for many packages in the Coin-OR infrastructure, couenne has a “stable”

and a “trunk” version. The former is recommended for almost all users, as it has

been thoroughly tested and provides an optimal solution to all instances tested

— its only disadvantage is that it is not the cutting edge version. The “trunk”

version, instead, contains the most recent features that are, however, still being

tested. Therefore, it does not guarantee its results: it may (although in some rare

cases) return a sub-optimal solution, an infeasible solution, or may just crash.

couenne can be downloaded in three ways: as a Subversion repository, as a

source code tarball, or as a binary tarball.

2See http://www.coin-or.org/faqs.html#q10

Subversion3.On *nix operating systems, simply run the following command:

svn co https://project.coin-or.org/svn/Couenne/stable/0.1 Couenne-0.1

if you wish to download the stable version, otherwise

svn co https://project.coin-or.org/svn/Couenne/trunk Couenne-trunk

will download the trunk version. Both commands create a local Subversion repos-

itory, which is a copy of what is currently being developed in any of the two ver-

sions. Although a copy of the source code will require that you build the source,

the process is usually straightforward and requires only a few commands. The

other advantage of an svn copy is that, in order to update your copy with the

latest features or bugﬁxes, you simply have to run the command

svn update

from the directory of your copy. For Windows4systems, several svn clients are

available, such as TortoiseSVN5.

Source tarball. as a source tarball, directly from the Coin-OR project website:

http://www.coin-or.org/download/source/Couenne

Binary tarball. couenne is also available as a binary tarball, again from the

Coin-OR website:

http://www.coin-or.org/download/binary/Couenne

While the last option gives you a pre-compiled version of couenne, the ﬁrst two

options allow to download and modify its source code.

2.1 Installing couenne

These instructions are necessary when downloading the source code, i.e. through

svn or as a tarball. We refer to general installation instructions for COIN-OR

projects at https://projects.coin-or.org/BuildTools. In short, ﬁrst run the fol-

lowing command (assuming you have checked out the stable version):

cd Couenne-0.1/ThirdParty

and download all the third party software tools that will be used in building

couenne: the Ampl Solver Library (ASL), Blas, Lapack, and MUMPS or HSL.

Instructions on how to download them are included in the INSTALL.* ﬁle in each

directory. Then, in order to build couenne proper you need to run the following

commands (assuming you have gone back to the Couenne-0.1 directory)

3See http://subversion.tigris.org for details.

4Windows is a trademark of Microsoft Corporation.

5See http://tortoisesvn.tigris.org

mkdir build

cd build

../configure -C

make

make install

The above commands place Couenne in the Couenne/build/bin/ directory,

libraries in Couenne/build/lib/, and include ﬁles in Couenne/build/include/.

An alternative directory can be speciﬁed with the --prefix option of conﬁgure.

For instance, when replacing “../configure -C” above with

../configure -C --prefix=/usr/local

the Couenne executable will be installed in /usr/local/bin/, the libraries in

/usr/local/lib/, and the include ﬁles in /usr/local/include/, assuming you

have writing permission in these directories. Couenne is run as follows:

couenne instance.nl

where instance.nl is an AMPL stub (.nl) ﬁle. Such ﬁles can be generated from

AMPL with the command “write gfilename;” (notice the “g” before the ﬁle

name), for example.

You may also specify a set of options to tweak the performance of Couenne.

These are found in the couenne.opt option ﬁle. A sample option ﬁle is given in

the Couenne/src/ directory.

3 How couenne works

Couenne is a reformulation-based branch-and-bound. The initial problem is re-

formulated by introducing a new set of variables, called auxiliary variables. After

reformulation, the problem looks as follows:

(P′) min wn+q

s.t. wi=ϑi(x, wn+1, wn+2 ...,wi−1)i∈Q

i≤wi≤wu

ii∈Q

i≤xi≤xu

ii∈N0

xi∈Zi∈NI

0⊆N0

wi∈Zi∈QI⊆Q.

Reformulation does not make the problem easier to solve, as it simply creates

a bunch of new variables. It is easier, however, to obtain a lower bound on the

optimal solution of (P′) than it is for (P). Whenever this manual mentions

an auxiliary variable, it means a variable that has been created during this

reformulation phase.

After reformulation, a linearization step allows to obtain a Linear Program-

ming relaxation of (P′) — and hence of (P), which can be easily embedded in a

branch-and-bound framework. couenne adds the following components:

– bound tightening techniques: these are used to infer better bounds on all

variables (both original and auxiliary), in order to get a tighter lower bound;

– heuristics to obtain a feasible solution;

– branching techniques for partitioning the set of solutions.

The options discussed below allow to tweak the performance of couenne on

these three components. For a thorough discussion on their meaning, we refer to

the introductory work on couenne by Belotti et al. [2].

4 Using couenne

While we are working to make couenne available from several modeling lan-

guages, it currently accepts ﬁles in AMPL nonlinear format, i.e., ﬁles with a .nl

extension. Therefore, there are currently two ways to use couenne:

–as a solver from the AMPL modeling language [5,6];

–as a standalone solver that reads ﬁles with extension .nl.

Suppose you want to use couenne from AMPL and you have a problem

described in a mymodel.mod ﬁle as follows:

var x1 >= 1 <= 2;

var x2 >= 0 integer;

minimize obj: x1^2.23 + 2*x2;

subject to c1: x1^2 + x2^2 <= 4;

subject to c2: x1 + x2 >= 0;

Then you can issue the following commands to AMPL:

ampl: model mymodel.mod

ampl: option solver couenne;

ampl: solve;

If, instead, you wish to run couenne on your own .nl ﬁles, just run

$ couenne myproblem.nl

at the command line. Notice that the couenne executable must be visible from

the command line, i.e., the directory where the executable is stored must be in

some PATH environment variable.

Option ﬁle. Couenne reads its run-time parameters from option ﬁle couenne.opt.

All parameters that are not speciﬁed in the option ﬁle are set to their default

value. All options are discussed in Section 6.

5 Output of couenne

Suppose we are solving the ex1221 instance of the minlplib library of MINLP

problems [4], translated into AMPL format through the convert utility of the

GAMS modeling language [3]. The original problem is as follows:

min 2x0+ 3x1+ 1.5y2+ 2y3−0.5y4

s.t. x2

0+y2= 1.25

x1.5

1+ 1.5y3= 3

y2+x0≤1.6

y3+ 1.333x1≤3

y4−y3−y2≤0

0≤x0≤10

0≤x1≤10

y2, y3, y4∈ {0,1}.

Without any couenne.opt option ﬁle, the output of couenne run on ex1221 is

as follows:

objectives:

min ( +2*x_0 +3*x_1 +1.5*y_2 +2*y_3 -0.5*y_4)

constraints:

((x_0^2) +1*y_2) = 1.25

((x_1^1.5) +1.5*y_3) = 3

( +1*y_2 +1*x_0) <= 1.6

( +1*y_3 +1.333*x_1) <= 3

( +1*y_4 -1*y_3 -1*y_2) <= 0

variables:

x_0 [ 0 , 10 ]

x_1 [ 0 , 10 ]

y_2 binary

y_3 binary

y_4 binary

end

Problem size before reformulation: 5 variables (3 integer), 5 constraints.

Problem size after reformulation: 13 variables (4 integer), 3 constraints.

NLP0012I

Num Status Obj It time

NLP0013I 1 OPT 7.667180052199679 9 0.012

Cbc0012I Integer solution of 7.66718 found by Init Rounding NLP

after 0 iterations and 0 nodes (0.00 seconds)

NLP0013I 2 OPT 7.667180051588896 3 0.004

Cbc0001I Search completed - best objective 7.667180068813135, took 0 iterations

and 0 nodes (0.01 seconds)

Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost

couenne: Optimal

"Finished"

The ﬁrst part of the output is a visualization of the problem itself. Variable

names may be diﬀerent from the AMPL version. couenne uses a similar in-

dexing standard to AMPL (the ﬁrst variable indexed by zero), but a diﬀerent

naming standard, which helps in case you print out the reformulated version of

the problem. For example, you may see the following variable names:

–x_3 is the fourth variable. It is an original variable of the problem, and is

continuous;

–y_5 is the sixth variable of the problem, an original variable, and constrained

to be integer;

–w_34 is the 35-th variable; it is auxiliary, that is, it was introduced by refor-

mulation, and is continuous (or at least couenne couldn’t understand if it

is constrained to be integer);

–z_43 is the 44-th variable; it is auxiliary and associated with a function that

can only take on integer values.

The visualization of the problem is rather straightforward, and is closed by

the keyword “end.” The following line shows that the original problem has ﬁve

variables, three of which are integer, and ﬁve constraints. The line following it

shows that, after reformulation, there are 13 variables (including original and

auxiliary), four of which are integer (so there is an integer auxiliary), and three

constraints. Two constraints (the ﬁrst two) have been eliminated from the orig-

inal problem because they are of the form

akxk+f(x1, x2...,xk−1, xk+1 ...,xn) = c

so couenne ﬁgured out it might just change xkinto an auxiliary associated

with the function −1

a(f(x1, x2...,xk−1, xk+1 ...,xn) + c).

The following output comes from the three fundamental COIN-OR software

packages that couenne uses: Cbc,Clp, and Ipopt. Lines starting with Cbc are

output from the branch-and-bound interface, and show number of total nodes

created, number of unvisited nodes, and current upper/lower bound, or show a

new feasible solution for the MINLP whenever one is found, or again a summary

line when the optimization has ended. Output by Clp is switched oﬀ by default,

while output by Ipopt consists in the objective value of a solution found.

6 Options

Options are speciﬁed in a ﬁle named couenne.opt, which has to be in the same

directory from which couenne is run. Each option is speciﬁed with the format

option name value

and anything between a “#” and the end of the line is ignored. There is a

sample couenne.opt ﬁle in the Couenne/src directory of the source code, with

comments and hints on how to use/change these options. The following is a list

of options that allow to tweak the result of couenne, and it is expected to

change as new features are introduced. Next to each option name, its default

value is given in brackets.

6.1 Output options

These options control the amount and type of output of couenne. Although

most of these options are for debugging purposes, some of them provide useful

(and limited) output. By default, all but problem print level are zero as they

produce a lot of output that is in general not needed.

–problem_print_level (4): this is probably the most useful. An option value

of 4 prints out the initial problem, while a value of 7 prints the reformulated

problem as well.

–branching_print_level (0): branching rules.

–boundtightening_print_level: bound tightening.

–convexifying_print_level (0): generation of linearization cuts.

–disjcuts_print_level (0): (verbose) output on the generation of disjunc-

tive cuts.

–nlpheur_print_level: heuristics.

–reformulate_print_level (0): output on the reformulation phase.

Print levels for other parts of couenne are as follows:

–lp_log_level (0): Clp output level;

–mip_log_level (1): Cbc output level;

–nlp_log_level (1): Ipopt output level.

Finally, if the option display_stats is set to “yes,” a line at the end of

execution is printed with some data about the optimization (lower-upper bound,

branch-and-bound time, separation time, etc.).

6.2 Linearization options

–convexification_cuts (4): number of rounds of cuts applied at each branch-

and-bound node.

–convexification_points (3): for the lower envelopes of convex functions,

this is the number of points where a supporting hyperplane is generated.

This only holds for the initial linearization, as all other linearizations only

add at most one cut per expression.

–delete_redundant (yes): some problems are reformulated in such a way

that some auxiliary variables are associated with functions that are other

variables, or wi=xj. By default, couenne gets rid of wi, but by setting

this option to “no” it will keep it as a variable.

–use_quadratic (no): this is still under testing. Quadratic form are not re-

formulated and therefore decomposed as a sum of auxiliary variables, each

associated with a bilinear term, but rather taken as a whole expression.

Envelopes for these expressions are generated through α-convexiﬁcation [1].

–violated_cuts_only (yes): only add those linearization cuts that are vio-

lated.

–lp_solver (clp): the Linear Programming solver used to ﬁnd lower bounds.

By default, CLP is used, but the user can also specify that Couenne uses the

Cplex commercial software. In the latter case, the configure script has to

be (re-)run with the following options:

--with-cplex-lib="/your/path/to/libcplex.a -lpthread"

--with-cplex-incdir=/your/path/to/include/ilcplex

6.3 Branching options

–branch_conv_cuts (no): after applying a branching rule and before re-

solving the subproblem, generate a round of linearization cuts with the new

bounds enforced by the rule (currently not working).

–branch_fbbt (yes): after applying a branching rule and before re-solving the

subproblem, apply Bound Tightening.

–branching_object (var_object): the source of infeasibility of a problem.

This option can take one of the following values: “var_obj”, “expr_obj”,

and “vt_obj”. The ﬁrst indicates that infeasibility is associated with each

variable. For example, suppose the optimal solution to the LP relaxation

is denoted by x⋆. If two auxiliary variables w2=f2(x1) and w3=f3(x1)

have an optimal value in the LP solution such that w⋆

26=f2(x⋆

1) and w⋆

36=

f3(x⋆

1), then x2will be associated an “infeasibility” measure dependent on

|w⋆

2−f2(x⋆

1)|and |w⋆

3−f3(x⋆

1)|. With option “expr_obj,” the infeasibility

is attributed to auxiliaries w2and w3, but this is not recommended. Fi-

nally, using “vt_obj” allows to use Violation Transfer, a branching variable

selection technique presented by Tawarmalani and Sahinidis [14]. A better

treatment of the branching process is given by Belotti et al. [2].

–cont_var_priority (1000): branching priority of continuous variables. When

branching, this is compared to the priority of integer variables, whose prior-

ity is ﬁxed to 1000. Higher values mean smaller priority, so if this parameter

is set to 1001 or higher, if a branch-and-bound node has at least one inte-

ger variable whose value is fractional branching will be performed on that

variable.

–enable_sos (no): use SOS branching objects, that are generated from con-

straints of the form Pk

h=1 yh= 1 with all variables yhbinary (still testing).

6.4 Bound tightening options

Bound tightening is a very important part of couenne. It allows to substantially

reduce the feasible set, and therefore the total running time.

–feasibility_bt (yes): apply Feasibility-Based Bound Tightening (FBBT),

a pre-processing technique to reduce the bounding box, before the generation

of linearization cuts. This is a quick and eﬀective way to reduce the solution

set, and it is highly recommended to keep it active.

–redcost_bt (yes): Use reduced costs of the LP in order to infer better vari-

able bounds.

–aggressive_fbbt (yes): apply Aggressive FBBT [2], a version of probing

[8,13] that also allow to reduce the solution set, although it is not as quick

as FBBT. It can be applied up to a certain depth of the branch&bound tree

— see below. In general, this option is useful but can be switched oﬀ if a

problem is too large and seems not to beneﬁt from it.

–optimality_bt (yes): apply Optimality-Based Bound Tightening (OBBT)

[9], which is another bound reduction technique aiming at reducing the so-

lution set by looking at the initial LP relaxation. This technique is compu-

tationally expensive, and should be used only when necessary.

–log_num_abt_per_level (3): depth of the branch&bound tree at which us-

age of Aggressive FBBT should be reduced. As mentioned above, this bound

tightening technique is rather time consuming, so it is useful to limit its ap-

plication to all branch&bound nodes up to a certain depth d, which is by

default equal to 3. At depths t > d, Aggressive FBBT will be applied with

probability 2d−t.

–log_num_obbt_per_level (4): Similarly to the previous option, this allow to

limit the number of times OBBT is used by setting a branch&bound depth

below which the usage of OBBT is reduced.

6.5 Disjunctive cut options

A recently added feature is the generation of disjunctive cuts. Cuts that are

guarantee to eliminate suboptimal solutions are generated by using disjunctions

naturally arising within a nonconvex MINLP. Their generation reﬂects the sepa-

ration of similar cuts for Mixed-Integer Linear Programming and, in this initial

version, is rather time consuming.

–minlp_disj_cuts (0): how often to generate disjunctive cuts. A “0” means

they are never generates, while any positive number ninstructs couenne

to generate them at every nnodes of the branch&bound tree. A negative

number −nmeans that generation should be attempted at the root node,

and if successful it can be repeated at every nnodes, otherwise it is stopped

altogether.

–disj_depth_level (3): at what depth of the branch&bound tree genera-

tion of disjunctive cuts should be reduced. This has a similar behavior as

log_num_obbt_per_level. A value of −1 means generation can be done at

all nodes.

–disj_depth_stop (10): at what depth of the branch&bound tree generation

of disjunctive cuts should be stopped. A value of −1 means generation is not

stopped

–disj_active_cols (yes): only consider violated variable bounds when creat-

ing the Linear Programming problem (the so-called CGLP, Cut Generating

LP); this reduces the size of the CGLP, but may produce less eﬃcient cuts.

–disj_active_rows (yes): only consider violated linear inequalities when cre-

ating the CGLP. Similar considerations apply.

–disj_cumulative (no): when generating disjunctive cuts on a set of dis-

junctions 1,2...,k, introduce the cut relative to the previous disjunction

i−1 in the CGLP used for disjunction i. Notice that, although this makes

the cut generated more eﬃcient, it increases the rank of the disjunctive cut

generated.

–disj_init_number (10): maximum number of disjunctions to be used at

every round of disjunctive cuts.

–disj_init_perc (0.2): maximum percentage of all disjunctions currently vi-

olated by the problem used for generating cuts (to be compared with the

parameter above to decide how many disjunctions to actually use for gener-

ating cuts).

6.6 Nonlinear solver options

–local_optimization_heuristic (yes): use a heuristic with Ipopt to ﬁnd

feasible solutions for the problem. It is highly recommended that this option

be set to active, as it would be diﬃcult to ﬁnd feasible solutions otherwise.

–log_num_local_optimization_per_level (2): at what depth of the bran-

ch&bound tree should the calls to the heuristic be reduced. Behavior similar

to log_num_obbt_per_level.

6.7 Tolerance options

–art_cutoff (+∞): cutoﬀ for the problem. Useful to fathom all nodes known

to have a lower bound above this cutoﬀ value, it reduces the total CPU time.

Notice that it is useful in practice only when a solution whose value is equal

to the cutoﬀ is known.

–art_lower (−∞): value of a lower bound to the optimal solution.

–feas_tolerance (10−6): tolerance to be applied when checking for the fea-

sibility of a MINLP solution. If a constraint gi(x)≤0 within this tolerance,

it is deemed satisﬁed.

6.8 Debug options

The general couenne user won’t need these options. They can be rather useful

when testing new components of couenne in order to check their validity.

A ﬁrst debugging feature of couenne is the possibility to store an optimal

solution in a ﬁle. The ﬁle must be named as the .nl instance ﬁle, but with exten-

sion .txt instead, and must be stored in the same directory where couenne is

called. For instance, if the current directory is ~/Couenne/build/ and we want

to debug couenne on an instance that has 12 variables and that is stored in

~/myInstances/trouble.nl, we may write a ﬁle ~/Couenne/build/trouble.txt

containing 13 lines: the ﬁrst line contains the value of the optimal solution, and

the remaining 12 contain the value of the variables in an optimal solution.

In order to check whether couenne is correct, set option problem_print_level

to 7. If a branch&bound node that is supposed to contain that optimal solution is

fathomed, or an inequality is added that cuts oﬀ the optimal solution, a warning

message will be displayed. Other options are below:

–check_lp (no): saves the .lp ﬁle of any LP generated to obtain a lower

bound. Unless the problem is small, this will create a lot of ﬁles, slow down

couenne signiﬁcantly, and occupy a lot of hard disk space.

–couenne_check (+∞): the value of a known optimal solution for the prob-

lem. Used to check whether couenne indeed ﬁnds an optimal solution.

–opt_window (+∞): if an optimal solution xopt is provided as described above,

this value allows to restrict the lower and upper bound of each variable xi

to [xopt

i−opt window ·(1 + |xopt

i|), xopt

i+opt window ·(1 + |xopt

i|)].

–test_mode (no): avoid pop-up windows reporting a memory access violation

(which happens when debugging).

–time_limit (7200): CPU time limit in seconds.

Options of Bonmin,Cbc,Clp, and Ipopt.The option ﬁle can also contain

option from the other components of couenne, namely Bonmin,Cbc,Clp, and

Ipopt. These have to be speciﬁed with a preﬁx equal to the corresponding name,

so if you want to specify the Bonmin option to use a B-BB algorithm, add a line

bonmin.algorithm B-BB

while all couenne options do not need any “couenne.” preﬁx.

References

1. I. P. Androulakis, C. D. Maranas, and C. A. Floudas. αbb: A global optimization

method for general constrained nonconvex problems. Journal of Global Optimiza-

tion, 7(4):337–363, December 1995.

2. P. Belotti, J. Lee, L. Liberti, F. Margot, and A. W¨achter. Branching and bounds

tightening techniques for non-convex MINLP. Optimization Methods and Software,

24(4-5):597–634, 2009.

3. A. Brooke, D. Kendrick, and A. Meeraus. GAMS: A User’s Guide, Release 2.25.

The Scientiﬁc Press, 1992. http://citeseer.ist.psu.edu/brooke92gams.html.

4. M. R. Bussieck, A. S. Drud, and A. Meeraus. MINLPLib – a col-

lection of test models for mixed-integer nonlinear programming. IN-

FORMS Journal of Computing, 15(1):114–119, 2003. Available online at

http://www.gamsworld.org/minlp/minlplib/minlpstat.htm.

5. R. Fourer, D. M. Gay, and B. W. Kernighan. AMPL: a modeling language for

mathematical programming. Boyd and Fraser Publishing Company, 1993.

6. D. M. Gay. Hooking your solver to AMPL. Technical Report 93-10, AT&T Bell

Laboratories, Murray Hill, NJ, 1993, revised 1997.

7. Eclipse Legal Resources. Eclipse public license v 1.0.

http://www.eclipse.org/legal/epl-v10.html.

8. M. W. P. Savelsbergh. Preprocessing and probing techniques for mixed integer

programming problems. ORSA Journal on Computing, 6(4):445–454, 1994.

9. J. P. Shectman and N. V. Sahinidis. A ﬁnite algorithm for global minimization of

separable concave programs. Journal of Global Optimization, 12:1–36, 1998.

10. E. M. B. Smith. On the Optimal Design of Continuous Processes. PhD thesis, Im-

perial College of Science, Technology and Medicine, University of London, October

1996.

11. E. M. B. Smith and C. C. Pantelides. Global optimisation of nonconvex MINLPs.

Computers & Chem. Engineering, 21:S791–S796, 1997.

12. E. M. B. Smith and C. C. Pantelides. A symbolic reformulation/spatial branch-

and-bound algorithm for the global optimisation of nonconvex MINLPs. Computers

& Chem. Eng., 23:457–478, 1999.

13. M. Tawarmalani and N. V. Sahinidis. Convexiﬁcation and global optimization in

continuous and mixed-integer nonlinear programming: Theory, algorithms, soft-

ware and applications, volume 65 of Nonconvex Optimization and Its Applications.

Kluwer Academic Publishers, Dordrecht, 2002.

14. M. Tawarmalani and N. V. Sahinidis. Global optimization of mixed-integer nonlin-

ear programs: A theoretical and computational study. Mathematical Programming,

99(3):563–591, 2004.

Couenne User Manual