Table of Contents
Introduction
The GAMS/NLPEC solver, developed jointly by Michael Ferris of UW-Madison and GAMS Development, solves MPEC and MCP models via reformulation of the complementarity constraints. The resulting sequence of NLP models are parameterized by a scalar
GAMS/NLPEC serves a number of purposes. In many cases, it is an effective tool for solving MPEC models, the first such tool available within GAMS. It also serves as a way to experiment with the many reformulation strategies proposed for solving MPEC and MCP models. Without something like NLPEC (and a library of models to test with) a comprehensive and thorough test and comparison of the various reformulation strategies would not be possible. To better serve these purposes, NLPEC has an open architecture. The model reformulations are written out as GAMS source for solution via an NLP solver, so it is possible to view this source and modify it if desired.
A brief note about notation is in order. The GAMS keyword positive
is used to indicate nonnegative variables. The same holds for nonpositive variables and the GAMS keyword negative
.
Usage
GAMS/NLPEC can solve models of two types: MPEC and MCP. If you did not specify NLPEC as the default MPEC or MCP solver, use the following statement in your GAMS model before the solve statement:
option MPEC=nlpec; { or MCP }
You can also make NLPEC the default solver via the command line:
gams nash MPEC=nlpec MCP=nlpec
You can use NLPEC with its default strategy and formulation, but most users will want to use an options file (Section Options) after reading about the different types of reformulations possible (Section Reformulation). In addition, an understanding of the architecture of NLPEC (Section Open Architecture) will be helpful in understanding how GAMS options are treated. Although NLPEC doesn't use the GAMS options workspace
, workfactor
, optcr
, optca
, reslim
, iterlim
, and domlim
directly, it passes these options on in the reformulated model so they are available to the NLP subsolver.
Reformulation
In this section we describe the different ways that the NLPEC solver can reformulate an MPEC as an NLP. The description also applies to MCP models: just consider MCP to be an MPEC with a constant objective. The choice of reformulation, and the subsidiary choices each reformulation entails, are controlled by the options described in the section on Setting the Reformulation Options and referenced throughout this section.
The original MPEC model is given as:
In most of the reformulations, the objective function (1) is included in the reformulated model without change. In some cases, it may be augmented with a penalty function. The variables
The constraints (2) are standard nonlinear programming constraints specified in GAMS in the standard fashion. In particular, these constraints may be less than inequalities as shown above, or equalities or greater than inequalities. The constraints will be unaltered by all our reformulations. These constraints may involve both
The constraints of interest are the equilibrium constraints (3), where (3) signifies that
As a special case of (4), consider the case where
namely that
The different ways to force (6) to hold using (smooth) NLP constraints are the basis of the NLPEC solver.
We introduce a simple example now that we will use throughout this document for expositional purposes:
This problem has the unique solution
and
This example is written very succinctly in GAMS notation as:
$TITLE simple mpec example variable f, x1, x2, y1, y2; positive variable y1; y2.lo = -1; y2.up = 1; equations cost, g, h1, h2; cost.. f =E= x1 + x2; g.. sqr(x1) + sqr(x2) =L= 1; h1.. x1 =G= y1 - y2 + 1; h2.. x2 + y2 =N= 0; model example / cost, g, h1.y1, h2.y2 /; solve example using mpec min f;
Note that the equation cost
is used to define g
defines the function h1
and h2
. The complementarity constraints utilize the standard GAMS convention of specifying the orthogonality relationship between model
statement. The interpretation of the "." relies on the bounds positive
, negative
, or lo
and up
keywords in GAMS. Note that since h2
really specifies a function =N=
to ensure this is clear here. Since the relationships satisfied by =G=
could also be replaced by =N=
in h1
.
In describing the various reformulations for (6), it is convenient to partition the
We will assume (without loss of generality) that
Product reformulations
Product reformulations all involve products of
Note that each inner product is a summation of products of nonnegative terms: a slack variable and the difference between a variable and its bound. In each of these products, either the slack variable or its complement must be zero in order to have a solution. Complementarity is forced by the multiplication of these two terms. The above reformulation is specified using option reftype mult
.
There are a number of variations on this theme, all of which can be specified via an options file. All of the inner products could be put into the same equation, left as in (7) above, or broken out into individual products (one for each
or
These different levels of aggregation are chosen using option aggregate none|partial|full
.
Since all of the inner products in (7) involve nonnegative terms, we can set the inner products equal to zero or set them constraint equality|inequality
.
As a concrete example, consider the option file
reftype mult aggregate none constraint inequality
applied to the simple example given above. Such an option file generates the nonlinear programming model:
By default, a single model is generated with the value InitMu 1e-2
), to decrease it by a constant factor in a series of looped solves (e.g. NumSolves 4
, UpdateFac 0.1
), and to solve one last time with a final value for FinalMu 0
). If the following lines are added to the option file
initmu 1.0 numsolves 4
then five consecutive solves of the nonlinear program (8) are performed, the first one using
As a final example, we use a combination of these options to generate a sequence of nonlinear programs whose solutions attempt to trace out the "central path" favored by interior point and barrier algorithms:
reftype mult constraint equality initmu 1.0 numsolves 4 updatefac 0.1 finalmu 1e-6
produces 6 nonlinear programs of the form
for values of
Slacks and doubly bounded variables
Slack variables can be used to reduce the number of times a complex nonlinear expression appears in the nonlinear programming model, as was carried out in (7). For a simpler illustrative example the NCP constraints (5) are equivalent to the constraints:
This reformulation has an additional equality constraint, and additional variables slack none|positive
controls the use of the
When there are doubly bounded variables present, these two slack options work slightly differently. For the positive
case, the reformulation introduces two nonnegative variables slack
, the example (8) shows what ensues to both singly and doubly bounded variables under this setting.
For the case slack none
, Scholtes proposed a way to use a multiplication to force complementarity that requires no slack variables:
Note that unlike the inner products in Section Reformulation, we can expect that one of the inequalities in (9) is unlikely to be binding at a solution (i.e. when constraint inequality
and aggregate none
on the doubly bounded variables, even if the user specifies a conflicting option. Thus the option file
reftype mult slack none
results in the model
Note that the complementarity constraint associated with
In the case of doubly bounded variables, a third option is available for the slack variables, namely slack one
. In this case, only one slack is introduced, and this slack removes the need to write the function
Note that the slack variable
We take this opportunity to introduce a simple extension to our option mechanism, namely the ability to set the options for singly and doubly bounded variables differently. For example, the option file
reftype mult slack positive one
sets the option slack positive
for the singly bounded variables and the option slack one
for the doubly bounded variables resulting in the model
Additional options such as
initmu 1.0 3.0 numsolves 2 updatefac 0.1 0.2
allow the values of
NCP functions
An NCP-function is a function
Clearly, finding a zero of an NCP-function solves a complementarity problem in
Examples of NCP functions include the min function, min(r,s)
, and the Fischer-Burmeister function
There is no requirement that an NCP function be nonnegative everywhere (it may be strictly negative at some points), so there is little point in setting the option constraint
; it will automatically take on the value constraint equality
. NCP functions cannot be aggregated, so the aggregate
option will always be set to none
.
Since the arguments to the NCP functions are going to be nonnegative at solution, we cannot use the functions positive
or free
, since the NCP function will force positivity at solution. For the singly-bounded variables, slacks are optional, and can also be positive
or free
.
Both of the NCP functions mentioned above suffer from being non-differentiable at the origin (and at points where
You can choose these particular NCP functions using option RefType min|FB|fFB
. The difference between the last two is that RefType FB
writes out GAMS code to compute the function RefType fFB
makes use of the GAMS intrinsic function NCPFB(r,s,mu) that computes
As an example, the option file
reftype fFB slack free initmu 1e-2
generates the reformulation
with a value of
Each of the two arguments to the NCP function will be nonnegative at solution, but for each argument we have the option of including a nonnegativity constraint explicitly as well. This results in the 4 values for the option NCPBounds none|all|function|variable
. When no slacks are present, this option controls whether to bound the function NCPBounds none|variable
is consistent with free slack variables and NCPBounds all|function
is consistent with positive slack variables.
Thus, the option file
reftype min slack positive NCPBounds function
generates the reformulation
The NCPBounds function
option means that the variable argument to the NCP function (in this case dnlp
model (instead of an nlp
model) in GAMS.
A smoothed version of the min function was proposed by Chen & Mangasarian:
This function is not symmetric in its two arguments, so RefType CMxf|CMfx|fCMxf|fCMfx
chooses a reformulation based on the function
Doubly bounded variables
Like the mult reformulation (7), reformulations using NCP functions are appropriate as long as we split the function
Use option RefType Bill|fBill
to choose such a reformulation for the doubly-bounded variables. The first option value writes out the function in explicit GAMS code, while the second writes it out using the GAMS intrinsic function NCPFB.
Penalty functions
All of the reformulations discussed so far have reformulated the complementarity conditions as constraints. It is also possible to treat these by moving them into the objective function with a penalty parameter
subject to the constraints
Choose this treatment using option refType penalty
. The options aggregate
and constraint
are ignored, since the inner products here are all aggregated and there are no relevant constraints. It is possible to do a similar reformulation without using slacks, so the options slack none|positive
can be used in conjunction with this reformulation type.
The following option file shows the use of the penalty
reformulation, but also indicates how to use a different reformulation for the singly and doubly bounded variables:
reftype penalty mult slack none * initmu 1.0 numsolves 2 updatefac 0.1 0.2
The "*" value allows the slack
option to take on its existing value, in this case positive
. Applied to our simple example given above, such an option file generates the nonlinear programming model:
The penalty parameter initmu
has only one value, so both the singly and doubly bounded
Testing for complementarity
In some cases a solution to the reformulated model may not satisfy the complementarity constraints of the original MPEC, e.g. if a large penalty parameter is used in the reformulation. It can also happen that the solution tolerances used in the NLP solver allow solutions with small error in the NLP model but large error in the original MPEC. For example if testtol
option.
Options
For details on how to create and use an option file, see the introductory chapter on solver usage.
For most GAMS solvers, the use of an options file is discouraged, at least for those unfamiliar with the solver. For NLPEC, however, we expect that most users will want to use an options file from the very beginning. NLPEC is as much a tool for experimentation as it is a solver, and as such use of the options file is encouraged.
Option values can take many different types (e.g. strings, integers, or reals). Perhaps the most important option to remember is one with no value at all: the help
option. Help
prints a list of the available options, along with their possible values and some helpful text. The options file is read sequentially, so in case an option value is set twice, the latter value takes precedence. However, any consistency checks performed on the options values (e.g. RefType fBill
cannot be used with aggregate full
) are made after the entire options file is read in, so the order in which different options appear is not important, provided the options are not specified twice.
Setting the Reformulation Options
While NLPEC has many options, there is a small set of five options that, taken together, serve to define the type of reformulation used. Listed in order of importance (highest priority items first), these reformulation options are the RefType
, slack
, constraint
, aggregate
and NCPBounds
options. In some cases, setting the highest-priority option RefType
is enough to completely define a reformulation (e.g. RefType penalty
in the case of doubly-bounded variables). In most cases though, the lower-priority options play a role in defining or modifying a reformulation. It's useful to consider the reformulation options in priority order when creating option files to define reformulations.
Some of the combinations of the reformulation options don't make sense. For example, the use of an NCP function to force complementarity between its two input arguments requires a separate function for each complementary pair, so setting both RefType min
and aggregate full
is inconsistent. NLPEC implements consistency checks on the reformulation options using the priority order: Given a consistent setting of the higher priority options, the next-highest priority option is checked and, if necessary, reset to be consistent with the items of higher priority. The end result is a set of consistent options that will result in a working reformulation. NLPEC prints out the pre- and post-checked sets of reformulation options, as well as warning messages about changes made. In case you want to use an option that NLPEC doesn't think is consistent, you can use the NoCheck
option: this supresses the consistency checks.
Each of the reformulation options in the table below takes two values - one for the singly-bounded variables in
RefType fCMxf RefType * fBill
first sets the RefType
to fCMxf
for all variable types, and then resets the RefType
to fBill
for doubly-bounded variables.
Reformulation Options
General Options
The Outdated equreform Option
In the early versions of NLPEC the only way to set the reform type was via the equreform
option. Each valid equreform
value represented a preselected combination of the options from Section Setting the Reformulation Options. This made it difficult to experiment with combinations not preselected, so the options in Section Setting the Reformulation Options were added. Be default, the equreform
option has value 0 and is not used. To get the old behavior, set equreform
to a positive value - this will force the options in Section Setting the Reformulation Options to be ignored. The general options in Section General Options are used no matter how the reformulation type is selected - via RefType
or equreform
.
Option | Description | Default |
---|---|---|
equreform | Old way to set the type of reformulation used. | 0 |
The values allowed for equreform
and their implications are given by the following table.

Open Architecture
In this section we describe the architecture of the NLPEC solver, i.e. the way the solver is put together. This should be useful to anybody using NLPEC for experiments or to those wanting to know the details of how NLPEC works.
The foundation for the NLPEC solver is the software library (also used in the GAMS/CONVERT solver) that allows us to write out a scalar GAMS model that is mathematically equivalent to the original, or to write out selected pieces of such a model. Using this software, NLPEC creates a GAMS NLP model using one of the reformulation strategies from Section Reformulation. This model may contain many new variables and/or equations, but it will surely contain the (non)linear expressions defining the original model as well. Once the scalar model has been created, NLPEC calls GAMS to solve this model, using the current NLP solver. The option parmFile can be used to pass on additional options to this GAMS job. After the model has solved, NLPEC reads the NLP solution, extracts the MPEC solution from it, and passes this MPEC solution back to GAMS as it terminates.
There are a number of advantages to this architecture. First, its openness makes it easy to see exactly what reformulation is being done. The intermediate scalar GAMS NLP model can be made available after the run by either saving the scratch directory (i.e. run with keep=1
) or using the dotGams
option to select an alternate file name. This intermediate model contains all the details of the reformulation. It can be used for debugging in case things didn't work out as expected. It is also possible to modify this file to do some quick and dirty experiments with similar reformulation strategies. Another advantage is the variety of NLP solvers that can be plugged in to solve the reformulated model. There is no need to program (and debug) an interface to an NLP package to run experiments with an NLP solver - the existing GAMS link is all that is needed. It is also easy to experiment with non-default solver options that may be more appropriate for reformulated MPEC models or for a particular choice of reformulation.