Table of Contents
Complementarity
A fundamental problem of mathematics is to find a solution to a square system of nonlinear equations. Two generalizations of nonlinear equations have been developed, a constrained nonlinear system which incorporates bounds on the variables, and the complementarity problem (MCP). This document is primarily concerned with the complementarity problem.
The PATH solver for MCP models is a Newton-based solver that combines a number of the most effective variations, extensions, and enhancements of this powerful technique. See PATH vs MILES for a comparison with MILES. Algorithmic details can also be found in papers and technical reports by Dirkse, Ferris, and Munson on Ferris' Home Page.
The complementarity problem adds a combinatorial twist to the classic square system of nonlinear equations, thus enabling a broader range of situations to be modeled. In its simplest form, the combinatorial problem is to choose from
Our development of complementarity is done by example. We begin by looking at the optimality conditions for a transportation problem and some extensions leading to the nonlinear complementarity problem. We then discuss a Walrasian equilibrium model and use it to motivate the more general mixed complementarity problem. We conclude this chapter with information on solving the models using the PATH solver and interpreting the results.
Transportation Problem
The transportation model is a linear program where demand for a single commodity must be satisfied by suppliers at minimal transportation cost. The underlying transportation network is given as a set
where
The derivation of the optimality conditions for this linear program begins by associating with each constraint a multiplier, alternatively termed a dual variable or shadow price. These multipliers represent the marginal price on changes to the corresponding constraint. We label the prices on the supply constraint
Consider the case when
where the
Similarly, at each node
Furthermore, the model assumes all prices are nonnegative,
The supply price at
We combine the three conditions into a single problem,
This model defines a linear complementarity problem that is easily recognized as the complementary slackness conditions [36] of the linear program (1). For linear programs the complementary slackness conditions are both necessary and sufficient for
termed the dual linear program (hence the nomenclature "dual variables").
Looking at (2) a bit more closely we can gain further insight into complementarity problems. A solution of (2) tells us the arcs used to transport goods. A priori we do not need to specify which arcs to use, the solution itself indicates them. This property represents the key contribution of a complementarity problem over a system of equations. If we know what arcs to send flow down, we can just solve a simple system of linear equations. However, the key to the modeling power of complementarity is that it chooses which of the inequalities in (2) to satisfy as equations. In economics we can use this property to generate a model with different regimes and let the solution determine which ones are active. A regime shift could, for example, be a back stop technology like windmills that become profitable if a
GAMS Code
The GAMS code for the complementarity version of the transportation problem is given in Figure 1; the actual data for the model is assumed to be given in the file transmcp.dat
. Note that the model written corresponds very closely to (2). In GAMS, the model
statement with a ".". It is precisely at this point that the pairing of variables and equations shown in (2) occurs in the GAMS code. For example, the function defined by rational
is complementary to the variable x
. To inform a solver of the bounds, the standard GAMS statements on the variables can be used, namely (for a declared variable
z.lo(i) = 0;
or alternatively
positive variable z;
Further information on the GAMS syntax can be found in [154]. Note that GAMS requires the modeler to write F(z) =g= 0
whenever the complementary variable is lower bounded, and does not allow the alternative form 0 =l= F(z)
.
Figure 1: A simple MCP model in GAMS, transmcp.gms
sets i canning plants, j markets ; parameter s(i) capacity of plant i in cases, d(j) demand at market j in cases, c(i,j) transport cost in thousands of dollars per case ; $include transmcp.dat positive variables x(i,j) shipment quantities in cases p_demand(j) price at market j p_supply(i) price at plant i; equations supply(i) observe supply limit at plant i demand(j) satisfy demand at market j rational(i,j); supply(i) .. s(i) =g= sum(j, x(i,j)) ; demand(j) .. sum(i, x(i,j)) =g= d(j) ; rational(i,j) .. p_supply(i) + c(i,j) =g= p_demand(j) ; model transport / rational.x, demand.p_demand, supply.p_supply /; solve transport using mcp;
Extension: Model Generalization
While many interior point methods for linear programming exploit this complementarity framework (so-called primal-dual methods [202] ), the real power of this modeling format is the new problem instances it enables a modeler to create. We now show some examples of how to extend the simple model (2) to investigate other issues and facets of the problem at hand.
Demand in the model of Figure 1 is independent of the prices
Note that the demand is rather strange if
Another feature that can be added to this model are tariffs or taxes. In the case where a tax is applied at the supply point, the third general inequality in (2) is replaced by
The taxes can be made endogenous to the model, details are found in [154] .
The key point is that with either of the above modifications, the complementarity problem is not just the optimality conditions of a linear program. In many cases, there is no optimization problem corresponding to the complementarity conditions.
Nonlinear Complementarity Problem
We now abstract from the particular example to describe more carefully the complementarity problem in its mathematical form. All the above examples can be cast as nonlinear complementarity problems (NCPs) defined as follows:
(NCP) Given a function
Recall that the
Walrasian Equilibrium
A Walrasian equilibrium can also be formulated as a complementarity problem (see [131] ). In this case, we want to find a price
where
GAMS Code
A GAMS implementation of (3) is given in Figure 2. Many large scale models of this nature have been developed. An interested modeler could, for example, see how a large scale complementarity problem was used to quantify the effects of the Uruguay round of talks [94] .
Figure 2: Walrasian equilibrium as an NCP, walras1.gms
$include walras.dat positive variables p(i), y(j); equations S(i), L(j); S(i).. b(i) + sum(j, A(i,j)*y(j)) - c(i)*sum(k, g(k)*p(k)) / p(i) =g= 0; L(j).. -sum(i, p(i)*A(i,j)) =g= 0; model walras / S.p, L.y /; solve walras using mcp;
Extension: Intermediate Variables
In many modeling situations, a key tool for clarification is the use of intermediate variables. As an example, the modeler may wish to define a variable corresponding to the demand function d
to store the demand function referred to in the excess supply equation. The model walras
now contains a mixture of equations and complementarity constraints. Since constructs of this type are prevalent in many practical models, the GAMS syntax allows such formulations.
Figure 3: Walrasian equilibrium as an MCP, walras2.gms
$include walras.dat positive variables p(i), y(j); variables d(i); equations S(i), L(j), demand(i); demand(i).. d(i) =e= c(i)*sum(k, g(k)*p(k)) / p(i) ; S(i).. b(i) + sum(j, A(i,j)*y(j)) - d(i) =g= 0 ; L(j).. -sum(i, p(i)*A(i,j)) =g= 0 ; model walras / demand.d, S.p, L.y /; solve walras using mcp;
Note that positive variables are paired with inequalities, while free variables are paired with equations. A crucial point misunderstood by many modelers (new and experienced alike) is that the bounds on the variable determine the relationships satisfied by the function demand
is an equality. Similarly, since S
is a (greater-than) inequality. See the MCP definition below for details.
A simplification is allowed to the model statement in Figure 3. It is not required to match free variables explicitly to equations; we only require that there are the same number of free columns (i.e. single variables) as unmatched rows (i.e. single equations). Thus, in the example of Figure 3, the model statement could be replaced by
model walras / demand, S.p, L.y /;
This extension allows existing GAMS models consisting of a square system of nonlinear equations to be easily recast as a complementarity problem - the model statement is unchanged. GAMS generates a list of all variables appearing in the equations found in the model statement, performs explicitly defined pairings and then checks that the number of remaining equality rows equals the number of remaining free columns. However, if an explicit match is given, the PATH solver can frequently exploit the information for better solution. Note that all variables that are not free and all inequalities must be explicitly matched.
Mixed Complementarity Problem
A mixed complementarity problem (MCP) is specified by three pieces of data, namely the lower bounds
(MCP) Given lower bounds
These relationships define a general MCP (sometimes termed a rectangular variational inequality [93] ). We will write these conditions compactly as
As the MCP model type as defined above is the one used in GAMS, there are some consequences of the definition worth emphasizing here. Firstly, the bounds on the variable determine the relationships satisfied by the function =G=
, =L=
) chosen plays no role in defining the problem. This being the case, it is acceptable (and perhaps advisable!) to use an =N=
in the definition of all equations used in complementarity models to highlight the dependence on the variable bounds in defining the MCP. This is not required, however. The constraint types =G=
, =L=
and =E=
are also allowed. If the variable bounds are inconsistent with the constraint type chosen, GAMS will either reject the model (e.g. an =L=
row matched with a lower-bounded variable) or silently and temporarily ignore the issue (e.g. an =E=
row matched with a lower-bounded variable). In the latter case, if equality does not hold at solution (allowable if the variable is at lower bound) the is marked in the listing file with a redef.
Secondly, note the contrast between complementarity conditions like
The nonlinear complementarity problem of Nonlinear Complementarity Problem is a special case of the MCP. For example, to formulate an NCP in the GAMS/MCP format we set
z.lo(I) = 0;
or declare
positive variable z;
Another special case is a square system of nonlinear equations
(NE) Given a function
In order to formulate this in the GAMS/MCP format we just declare
free variable z;
In both the above cases, we must not modify the lower and upper bounds on the variables later (unless we wish to drastically change the problem under consideration).
An advantage of the extended formulation described above is the pairing between "fixed" variables (ones with equal upper and lower bounds) and a component of
Simple bounds on the variables are a convenient modeling tool that translates into efficient mathematical programming tools. For example, specialized codes exist for the bound constrained optimization problem
The first order optimality conditions for this problem class are precisely MCP(
Upper bounds can be used to extend the utility of existing models. For example, in Figure 3 it may be necessary to have an upper bound on the activity level
y.up(j) = 10; L(j).. -sum(i, p(i)*A(i,j)) =e= 0 ;
Here, for bounded variables, we do not know beforehand if the constraint will be satisfied as an equation, less-than inequality or greater-than inequality, since this determination depends on the values of the solution variables. However, let us interpret the relationships that the above change generates. If
Solution
We will assume that a file named transmcp.gms
has been created using the GAMS syntax which defines an MCP model transport
as developed in Transportation Problem . The modeler has a choice of the complementarity solver to use. We are going to further assume that the modeler wants to use PATH.
There are two ways to ensure that PATH is used as opposed to any other GAMS/MCP solver. These are as follows:
- Add the following line to the
transmcp.gms
file prior to thesolve
statement> PATH will then be used instead of the default solver provided.option mcp = path;
- Choose PATH as the default solver for MCP (via the IDE on Windows or elsewhere by rerunning
gamsinst
from the GAMS system directory).
To solve the problem, the modeler executes the command:
gams transmcp
where transmcp
can be replaced by any filename containing a GAMS model. Many other command line options for GAMS exist; the reader is referred to List of Command Line Parameters for further details.
At this stage, control is handed over to the solver which creates a log providing information on what the solver is doing as time elapses. See Section PATH for details about the log file. After the solver terminates, a listing file is generated containing the solution to the problem. We now describe the listing file output specifically related to complementarity problems.
Listing File
The listing file is the standard GAMS mechanism for reporting model results. This file contains information regarding the compilation process, the form of the generated equations in the model, and a report from the solver regarding the solution process.
We now detail the last part of this output, an example of which is given in Figure 4 . We use "..." to indicate where we have omitted continuing similar output.
Figure 4: Listing File for solving transmcp.gms
S O L V E S U M M A R Y MODEL TRANSPORT TYPE MCP SOLVER PATH FROM LINE 45 **** SOLVER STATUS 1 NORMAL COMPLETION **** MODEL STATUS 1 OPTIMAL RESOURCE USAGE, LIMIT 0.057 1000.000 ITERATION COUNT, LIMIT 31 10000 EVALUATION ERRORS 0 0 Work space allocated -- 0.06 Mb ---- EQU RATIONAL LOWER LEVEL UPPER MARGINAL seattle .new-york -0.225 -0.225 +INF 50.000 seattle .chicago -0.153 -0.153 +INF 300.000 seattle .topeka -0.162 -0.126 +INF . ... ---- VAR X shipment quantities in cases LOWER LEVEL UPPER MARGINAL seattle .new-york . 50.000 +INF . seattle .chicago . 300.000 +INF . ... **** REPORT SUMMARY : 0 NONOPT 0 INFEASIBLE 0 UNBOUNDED 0 REDEFINED 0 ERRORS
After a summary line indicating the model name and type and the solver name, the listing file shows a solver status and a model status. Table 1 and Table 2 display the relevant codes that are returned under different circumstances. A modeler can access these codes within the transmcp.gms
file using transport.solveStat
and transport.modelStat
respectively.
Code | String | Meaning |
---|---|---|
1 | Normal completion | Solver finished normally |
2 | Iteration interrupt | Solver reached the iterations limit |
3 | Resource interrupt | Solver reached the time limit |
4 | Terminated by solver | Solver reached an unspecified limit |
8 | User interrupt | The user interrupted the solution process |
Code | String | Meaning |
---|---|---|
1 | Optimal | Solver found a solution of the problem |
6 | Intermediate infeasible | Solver failed to solve the problem |
After this, a listing of the time and iterations used is given, along with a count on the number of evaluation errors encountered. If the number of evaluation errors is greater than zero, further information can typically be found later in the listing file, prefaced by "****". Information provided by the solver is then displayed.
Next comes the solution listing, starting with each of the equations in the model. For each equation passed to the solver, four columns are reported, namely the lower bound, level, upper bound and marginal. GAMS moves all parts of a constraint involving variables to the left hand side, and accumulates the constants on the right hand side. The lower and upper bounds correspond to the constants that GAMS generates. For equations, these should be equal, whereas for inequalities one of them should be infinite. The level value of the equation (an evaluation of the left hand side of the constraint at the current point) should be between these bounds, otherwise the solution is infeasible and the equation is marked as follows:
seattle .chicago -0.153 -2.000 +INF 300.000 INFES
The marginal column in the equation contains the value of the variable that was matched with this equation.
For the variable listing, the lower, level and upper columns indicate the lower and upper bounds on the variables and the solution value. The level value returned by PATH will always be between these bounds. The marginal column contains the value of the slack on the equation that was paired with this variable. If a variable appears in one of the constraints in the model statement but is not explicitly paired to a constraint, the slack reported here contains the internally matched constraint slack. The definition of this slack is the minimum of equ.l - equ.lower and equ.l - equ.upper, where equ is the paired equation.
Finally, a summary report is given that indicates how many errors were found. Figure 4 is nicely-solved case; when the model has infeasibilities, these can be found by searching for the string "INFES" as described above.
Redefined Equations
Unfortunately, this is not the end of the story. Some equations may have the following form:
LOWER LEVEL UPPER MARGINAL new-york 325.000 350.000 325.000 0.225 REDEF
This should be construed as a warning from GAMS, as opposed to an error. In principle, the REDEF
should only occur if the paired variable to the constraint has a finite lower and/or upper bound and the variable is at one of those bounds. In this case, at the solution of the complementarity problem the sense of the constraint (e.g. =E=
) may not be satisfied. This occurs when GAMS constraints are used to define the function REDEF
label when the solution found leads to a violated "constraint". To avoid REDEF
warnings the =N=
can be used to define all complementarity functions.
Note that a REDEF
is not an error, just a warning. The solver has solved the complementarity problem specified. GAMS gives this report to ensure that the modeler understands that the complementarity problem derives the relationships on the equations from the variable bounds, not from the equation definition.
Pitfalls
As indicated above, the ordering of an equation is important in the specification of an MCP. Since the data of the MCP is the function
For example, if we have the optimization problem,
then the first order optimality conditions are
which has a unique solution,
Figure 5: First order conditions as an MCP, first.gms
variables x; equations d_f; x.lo = 0; x.up = 2; d_f.. 2*(x - 1) =e= 0; model first / d_f.x /; solve first using mcp;
However, if we accidentally write the valid equation
d_f.. 0 =e= 2*(x - 1);
the problem given to the solver is
which has three solutions,
not the problem we intended to solve.
Continuing with the example, when
However, in difficult (singular or near singular) cases, the substitution cannot be performed, and instead a perturbation is applied to
Furthermore, underlying model convexity is important. For example, if we have the linear program
we can write the first order optimality conditions as either
or, equivalently,
because we have an equation. The former is a linear complementarity problem with a positive semidefinite matrix, while the latter is almost certainly indefinite. Also, if we need to perturb the problem because of numerical problems, the former system will become positive definite, while the later becomes highly nonconvex and unlikely to solve. The rule of thumb here is to consider what happens when the dual multiplier
Finally, users are strongly encouraged to match equations and free variables when the matching makes sense for their application. Structure and convexity can be destroyed if it is left to the solver to perform the matching. For example, in the above example, we could lose the positive semidefinite matrix with an arbitrary matching of the free variables.
PATH
Newton's method, perhaps the most famous solution technique, has been extensively used in practice to solve square systems of nonlinear equations. The basic idea is to construct a local approximation of the nonlinear equations around a given point,
PATH uses a generalization of this method on a nonsmooth reformulation of the complementarity problem. To construct the Newton direction, we use the normal map [150] representation
associated with the MCP, where
Versions of PATH prior to 4.x are based entirely on this formulation using the residual of the normal map
as a merit function. However, the residual of the normal map is not differentiable, meaning that if a subproblem is not solvable then a "steepest descent" step on this function cannot be taken. PATH 4.x considers an alternative nonsmooth system [62] ,
The remainder of this chapter details the interpretation of output from PATH and ways to modify the behavior of the code. To this end, we will assume that the modeler has created a file named transmcp.gms
which defines an MCP model transport
as described in Section Transportation Problem and is using PATH 4.x to solve it. See Section Solution for information on changing the solver.
Log File
We will now describe the behavior of the PATH algorithm in terms of the output typically produced. An example of the log for a particular run is given in Figure 6 and Figure 7.
Figure 6: Log File from PATH for solving transmcp.gms
--- Starting compilation --- trnsmcp.gms(46) 1 Mb --- Starting execution --- trnsmcp.gms(27) 1 Mb --- Generating model transport --- trnsmcp.gms(45) 1 Mb --- 11 rows, 11 columns, and 24 non-zeroes. --- Executing PATH Work space allocated -- 0.06 Mb Reading the matrix. Reading the dictionary. Path v4.3: GAMS Link ver037, SPARC/SOLARIS 11 row/cols, 35 non-zeros, 28.93% dense. Path 4.3 (Sat Feb 26 09:38:08 2000) Written by Todd Munson, Steven Dirkse, and Michael Ferris INITIAL POINT STATISTICS Maximum of X. . . . . . . . . . -0.0000e+00 var: (x.seattle.new-york) Maximum of F. . . . . . . . . . 6.0000e+02 eqn: (supply.san-diego) Maximum of Grad F . . . . . . . 1.0000e+00 eqn: (demand.new-york) var: (x.seattle.new-york) INITIAL JACOBIAN NORM STATISTICS Maximum Row Norm. . . . . . . . 3.0000e+00 eqn: (supply.seattle) Minimum Row Norm. . . . . . . . 2.0000e+00 eqn: (rational.seattle.new-york) Maximum Column Norm . . . . . . 3.0000e+00 var: (p_supply.seattle) Minimum Column Norm . . . . . . 2.0000e+00 var: (x.seattle.new-york) Crash Log major func diff size residual step prox (label) 0 0 1.0416e+03 0.0e+00 (demand.new-york) 1 1 3 3 1.0029e+03 1.0e+00 1.0e+01 (demand.new-york) pn_search terminated: no basis change.
Figure 7: Log File from PATH for solving transmcp.gms
(continued)
Major Iteration Log major minor func grad residual step type prox inorm (label) 0 0 2 2 1.0029e+03 I 9.0e+00 6.2e+02 (demand.new-york) 1 1 3 3 8.3096e+02 1.0e+00 SO 3.6e+00 4.5e+02 (demand.new-york) ... 15 2 17 17 1.3972e-09 1.0e+00 SO 4.8e-06 1.3e-09 (demand.chicago) FINAL STATISTICS Inf-Norm of Complementarity . . 1.4607e-08 eqn: (rational.seattle.chicago) Inf-Norm of Normal Map. . . . . 1.3247e-09 eqn: (demand.chicago) Inf-Norm of Minimum Map . . . . 1.3247e-09 eqn: (demand.chicago) Inf-Norm of Fischer Function. . 1.3247e-09 eqn: (demand.chicago) Inf-Norm of Grad Fischer Fcn. . 1.3247e-09 eqn: (rational.seattle.chicago) FINAL POINT STATISTICS Maximum of X. . . . . . . . . . 3.0000e+02 var: (x.seattle.chicago) Maximum of F. . . . . . . . . . 5.0000e+01 eqn: (supply.san-diego) Maximum of Grad F . . . . . . . 1.0000e+00 eqn: (demand.new-york) var: (x.seattle.new-york) ** EXIT - solution found. Major Iterations. . . . 15 Minor Iterations. . . . 31 Restarts. . . . . . . . 0 Crash Iterations. . . . 1 Gradient Steps. . . . . 0 Function Evaluations. . 17 Gradient Evaluations. . 17 Total Time. . . . . . . 0.020000 Residual. . . . . . . . 1.397183e-09 --- Restarting execution
The first few lines on this log file are printed by GAMS during its compilation and generation phases. The model is then passed off to PATH at the stage where the "Executing PATH" line is written out. After some basic memory allocation and problem checking, the PATH solver checks if the modeler required an option file to be read. In the example this is not the case. If PATH is directed to read an option file (see PATH Options below), then the following output is generated after the PATH banner.
Reading options file PATH.OPT > output_linear_model yes; Options: Read: Line 2 invalid: hi_there; Read of options file complete.
If the option reader encounters an invalid option (as above), it reports this but carries on executing the algorithm. Following this, the algorithm starts working on the problem.
Diagnostic Information
Some diagnostic information is initially generated by the solver at the starting point. Included is information about the initial point and function evaluation. The log file here tells the value of the largest element of the starting point and the variable where it occurs. Similarly, the maximum function value is displayed along with the row producing it. The maximum element in the gradient is also presented with the equation and variable where it is located.
The second block provides more information about the Jacobian at the starting point. This information can be used to help scale the model. See Section Advanced Topics for complete details.
Crash Log
The first phase of the code is a crash procedure attempting to quickly determine which of the inequalities should be active. This procedure is documented fully in [45] , and an example of the Crash Log can be seen in Figure 6. The first column of the crash log is just a label indicating the current iteration number, the second gives an indication of how many function evaluations have been performed so far. Note that precisely one Jacobian (gradient) evaluation is performed per crash iteration. The number of changes to the active set between iterations of the crash procedure is shown under the "diff" column. The crash procedure terminates if this becomes small. Each iteration of this procedure involves a factorization of a matrix whose size is shown in the next column. The residual is a measure of how far the current iterate is from satisfying the complementarity conditions (MCP); it is zero at a solution. See Merit Functions for further information. The column "step" corresponds to the steplength taken in this iteration - ideally this should be 1. If the factorization fails, then the matrix is perturbed by an identity matrix scaled by the value indicated in the "prox" column. The "label" column indicates which row in the model is furthest away from satisfying the conditions (MCP). Typically, relatively few crash iterations are performed. Section PATH Options gives mechanisms to affect the behavior of these steps.
Major Iteration Log
After the crash is completed, the main algorithm starts as indicated by the "Major Iteration Log" flag (see Figure 7). The columns that have the same labels as in the crash log have precisely the same meaning described above. However, there are some new columns that we now explain. Each major iteration attempts to solve a linear mixed complementarity problem using a pivotal method that is a generalization of Lemke's method [116] . The number of pivots performed per
major iteration is given in the "minor" column.
The "grad" column gives the cumulative number of Jacobian evaluations used; typically one evaluation is performed per iteration. The "inorm" column gives the value of the error in satisfying the equation indicated in the "label" column.
At each iteration of the algorithm, several different step types can be taken, due to the use of nonmonotone searches [44] , [55] which are used to improve robustness. In order to help the PATH user, we have added two code letters indicating the return code from the linear solver and the step type to the log file. Table 3 explains the return codes for the linear solver and Table 4 explains the meaning of each step type. The ideal output in this column is "SO"; "SD" and "SB" also indicate reasonable progress. Codes different from these are not catastrophic, but typically indicate the solver is having difficulties due to numerical issues or nonconvexities in the model.
Code | Meaning |
---|---|
C | A cycle was detected. |
E | An error occurred in the linear solve. |
I | The minor iteration limit was reached. |
N | The basis became singular. |
R | An unbounded ray was encountered. |
S | The linear subproblem was solved. |
T | Failed to remain within tolerance after factorization was performed. |
Code | Meaning |
---|---|
B | A Backtracking search was performed from the current iterate to the Newton point in order to obtain sufficient decrease in the merit function. |
D | The step was accepted because the Distance between the current iterate and the Newton point was small. |
G | A gradient step was performed. |
I | Initial information concerning the problem is displayed. |
M | The step was accepted because the Merit function value is smaller than the nonmonotone reference value. |
O | A step that satisfies both the distance and merit function tests. |
R | A Restart was carried out. |
W | A Watchdog step was performed in which we returned to the last point encountered with a better merit function value than the nonmonotone reference value (M, O, or B step), regenerated the Newton point, andperformed a backtracking search. |
Minor Iteration Log
If more than 500 pivots are performed, a minor log is output that gives more details of the status of these pivots. A listing from transmcp
model follows, where we have set the output_minor_iteration_frequency
option to 1.
Minor Iteration Log minor t z w v art ckpts enter leave 1 4.2538e-01 8 2 0 0 0 t[ 0] z[ 11] 2 9.0823e-01 8 2 0 0 0 w[ 11] w[ 10] 3 1.0000e+00 9 2 0 0 0 z[ 10] t[ 0]
t
is a parameter that goes from zero to 1 for normal starts in the pivotal code. When the parameter reaches 1, we are at a solution to the subproblem. The t
column gives the current value for this parameter. The next columns report the current number of problem variables ckpts
column. Finally, the minor iteration log displays the entering and leaving variables during the pivot sequence.
Restart Log
The PATH code attempts to fully utilize the resources provided by the modeler to solve the problem. Versions of PATH after 3.0 have been much more aggressive in determining that a stationary point of the residual function has been encountered. When it is determined that no progress is being made, the problem is restarted from the initial point supplied in the GAMS file with a different set of options. These restarts give the flexibility to change the algorithm in the hopes that the modified algorithm leads to a solution. The ordering and nature of the restarts were determined by empirical evidence based upon tests performed on real-world problems.
The exact options set during the restart are given in the restart log, part of which is reproduced below.
Restart Log proximal_perturbation 0 crash_method none crash_perturb yes nms_initial_reference_factor 2 proximal_perturbation 1.0000e-01
If a particular problem solves under a restart, a modeler can circumvent the wasted computation by setting the appropriate options as shown in the log. Note that sometimes an option is repeated in this log. In this case, it is the last option that is used.
Solution Log
A solution report is now given by the algorithm for the point returned. The first component is an evaluation of several different merit functions. Next, a display of some statistics concerning the final point is given. This report can be used detect problems with the model and solution as detailed in Section Advanced Topics .
At the end of the log file, summary information regarding the algorithm's performance is given. The string "** EXIT - solution found". is an indication that PATH solved the problem. Any other EXIT string indicates a termination at a point that may not be a solution. These strings give an indication of what modelStat
and solveStat
will be returned to GAMS. After this, the "Restarting execution" flag indicates that GAMS has been restarted and is processing the results passed back by PATH.
Status File
If for some reason the PATH solver exits without writing a solution, or the sysout
flag is turned on, the status file generated by the PATH solver will be reported in the listing file. The status file is similar to the log file, but provides more detailed information. The modeler is typically not interested in this output.
User Interrupts
A user interrupt can be effected by typing Ctrl-C. We only check for interrupts every major iteration. If a more immediate response is wanted, repeatedly typing Ctrl-C will eventually kill the job. The number needed is controlled by the interrupt_limit
option. In this latter case, when a kill is performed, no solution is written and an execution error will be generated in GAMS.
Preprocessing
The purpose of a preprocessor is to reduce the size and complexity of a model to achieve improved performance by the main algorithm. Another benefit of the analysis performed is the detection of some provably unsolvable problems. A comprehensive preprocessor has been incorporated into PATH as developed in [57] .
The preprocessor reports its finding with some additional output to the log file. This output occurs before the initial point statistics. An example of the preprocessing on the forcebsm
model is presented below.
Zero: 0 Single: 112 Double: 0 Forced: 0 Preprocessed size: 72
The preprocessor looks for special polyhedral structure and eliminates variables using this structure. These are indicated with the above line of text. Other special structure is also detected and reported.
On exit from the algorithm, we must generate a solution for the original problem. This is done during the postsolve. Following the postsolve, the residual using the original model is reported.
Postsolved residual: 1.0518e-10
This number should be approximately the same as the final residual reported on the presolved model.
Constrained Nonlinear System
Modelers typically add bounds to their variables when attempting to solve nonlinear problems in order to restrict the domain of interest. For example, many square nonlinear systems are formulated as
where typically, the bounds on
Internally, PATH reformulates a constrained nonlinear system of equations to an equivalent complementarity problem. The reformulation adds variables,
This is the MCP model passed on to the PATH solver.
PATH Options
The default options of PATH should be sufficient for most models. If desired, PATH-specific options can be specified by using a solver option file. While the content of an option file is solver-specific, the details of how to create an option file and instruct the solver to use it are not. This topic is covered in section The Solver Options File.
We give a list of the available PATH options along with their defaults and meaning below. Note that only the first three characters of every word are significant.
General options
Output options
GAMS controls the total number of pivots allowed via the iterlim
option. If more pivots are needed for a particular model then either of the following lines should be added to the transmcp.gms
file before the solve statement
option iterlim = 2000; transport.iterlim = 2000;
Problems with a singular basis matrix can be overcome by using the proximal_perturbation
option [22] , and linearly dependent columns can be output with the output_factorization_singularities
option. For more information on singularities, we refer the reader to Section Advanced Topics.
As a special case, PATH can emulate Lemke's method [38] , [116] for LCP with the following options:
crash_method none crash_perturb no major_iteration_limit 1 lemke_start first nms no
If instead, PATH is to imitate the Successive Linear Complementarity method (SLCP, often called the Josephy Newton method) [100] , [131] , [130] for MCP with an Armijo style linesearch on the normal map residual, then the options to use are:
crash_method none crash_perturb no lemke_start always nms_initial_reference_factor 1 nms_memory size 1 nms_mstep_frequency 1 nms_searchtype line merit_function normal
Note that nms_memory_size 1
and nms_initial_reference_factor
1 turn off the nonmonotone linesearch, while nms_mstep_frequency
1 turns off watchdogging [34] . nms_searchtype line
forces PATH to search the line segment between the initial point and the solution to the linear model, while merit_function normal
tell PATH to use the normal map for calculating the residual.
Advanced Topics
This chapter discusses some of the difficulties encountered when dealing with complementarity problems. We start off with a very formal definition of a complementarity problem (similar to the one given previously) which is used in later sections on merit functions and ill-defined, poorly-scaled, and singular models.
Formal Definition of MCP
The mixed complementarity problem is defined by a function,
This formulation is a special case of the variational inequality problem defined by
(generated by
(generated using
Algorithmic Features
We now describe some of the features of the PATH algorithm and the options affecting each.
Merit Functions
A solver for complementarity problems typically employs a merit function to indicate the closeness of the current iterate to the solution set. The merit function is zero at a solution to the original problem and strictly positive otherwise. Numerically, an algorithm terminates when the merit function is approximately equal to zero, thus possibly introducing spurious "solutions".
The modeler needs to be able to determine with some reasonable degree of accuracy whether the algorithm terminated at solution or if it simply obtained a point satisfying the desired tolerances that is not close to the solution set. For complementarity problems, we can provide several indicators with different characteristics to help make such a determination. If one of the indicators is not close to zero, then there is some evidence that the algorithm has not found a solution. We note that if all of the indicators are close to zero, we are reasonably sure we have found a solution. However, the modeler has the final responsibility to evaluate the "solution" and check that it makes sense for their application.
For the NCP, a standard merit function is
with the first two terms measuring the infeasibility of the current point and the last term indicating the complementarity error. In this expression, we use
where
There are several reformulations of the MCP as a system of nonlinear (nonsmooth) equations for which the corresponding residual is a natural merit function. Some of these are as follows:
- Generalized Minimum Map:
- Normal Map:
- Fischer Function:
, where with
Note that
if and only if . A straightforward extension of to the MCP format is given for example in [60] .
In the context of nonlinear complementarity problems the generalized minimum map corresponds to the classic minimum map
The squared norm of
The merit functions and the information PATH provides at the solution can be useful for diagnostic purposes. By default, PATH 4.x returns the best point with respect to the merit function because this iterate likely provides better information to the modeler. As detailed in Section PATH Options, the default merit function in PATH 4.x is the Fischer function. To change this behavior the merit_function
option can be used.
Crashing Method
The crashing technique [45] is used to quickly identify an active set from the user-supplied starting point. At this time, a proximal perturbation scheme [23] , [24] is used to overcome problems with a singular basis matrix. The proximal perturbation is introduced in the crash method, when the matrix factored is determined to be singular. The value of the perturbation is based on the current merit function value.
Even if the crash method is turned off, for example via the option crash_method none
, perturbation can be added. This is determined by factoring the matrix that crash would have initially formed. This behavior is extremely useful for introducing a perturbation for singular models. It can be turned off by issuing the option crash_perturb no
.
Nonmontone Searches
The first line of defense against convergence to stationary points is the use of a nonmonotone linesearch [89] , [90] , [55] . In this case we define a reference value,
Depending upon the choice of the reference value, this allows the merit function to increase from one iteration to the next. This strategy can not only improve convergence, but can also avoid local minimizers by allowing such increases.
We now need to detail our choice of the reference value. We begin by letting nms_initial_reference_factor
option;
Having defined the values of
When we decide to use a gradient step, it is beneficial to let
A watchdog strategy [34] is also available for use in the code.The method employed allows steps to be accepted when they are "close" to the current iterate. Nonmonotonic decrease is enforced every nms_mstep_frequency
option.
Linear Complementarity Problems
PATH solves a linear complementarity problem at each major iteration. Let
where
The objective of the linear model solver is to construct a path from a given complementary triple
where
The addition of artificial variables enables us to construct an initial invertible basis consistent with the given starting point even under rank deficiency. The procedure consists of two parts: constructing an initial guess as to the basis and then recovering from rank deficiency to obtain an invertible basis. The crash technique gives a good approximation to the active set. The first phase of the algorithm uses this information to construct a basis by partitioning the variables into three sets:
Since
We use a modified version of EXPAND [82] to perform the ratio test. Variables are prioritized as follows:
leaving at its upper bound.- Any artificial variable.
- Any
, , or variable.
If a choice as to the leaving variable can be made while maintaining numerical stability and sparsity, we choose the variable with the highest priority (lowest number above).
When an artificial variable leaves the basis and a
If the code is forced to use a ray start at each iteration (lemke_start always
), then the code carries out Lemke's method, which is known [38] not to cycle. However,by default, we use a regular start to guarantee that the generated path emanates from the current iterate. Under appropriate conditions, this guarantees a decrease in the nonlinear residual. However, it is then possible for the pivot sequence in the linear model to cycle. To prevent this undesirable outcome, we attempt to detect the formation of a cycle with the heuristic that if a variable enters the basis more that a given number of times, we are cycling. The number of times the variable has entered is reset whenever
Another heuristic is added when the linear code terminates on a ray. The returned point in this case is not the base of the ray. We move a slight distance up the ray and return this new point. If we fail to solve the linear subproblem five times in a row, a Lemke ray start will be performed in an attempt to solve the linear subproblem. Computational experience has shown this to be an effective heuristic and generally results in solving the linear model. Using a Lemke ray start is not the default mode, since typically many more pivots are required.
For times when a Lemke start is actually used in the code, an advanced ray can be used. We basically choose the "closest" extreme point of the polytope and choose a ray in the interior of the normal cone at this point. This helps to reduce the number of pivots required. However, this can fail when the basis corresponding to the cell is not invertible. We then revert to the Lemke start.
Since the EXPAND pivot rules are used, some of the variables may be nonbasic, but slightly infeasible, as the solution. Whenever the linear code finishes, the nonbasic variables are put at their bounds and the basic variables are recomputed using the current factorization. This procedure helps to find the best possible solution to the linear system.
The resulting linear solver as modified above is robust and has the desired property that we start from
Other Features
Some other heuristics are incorporated into the code. During the first iteration, if the linear solver fails to find a Newton point, a Lemke start is used. Furthermore, under repeated failures during the linear solve, a Lemke start will be attempted. A gradient step can also be used when we fail repeatedly.
The proximal perturbation is reduced at each major iteration. However, when numerical difficulties are encountered, it will be increased to a fraction of the current merit function value. These are determined when the linear solver returns a Reset or Singular status.
Spacer steps are taken every major iteration, in which the iterate is chosen to be the best point for the normal map. The corresponding basis passed into the Lemke code is also updated.
Scaling is done based on the diagonal of the matrix passed into the linear solver.
We finally note, that if the merit function fails to show sufficient decrease over the last 100 iterates, a restart will be performed, as this indicates we are close to a stationary point.
Difficult Models
Ill-Defined Models
A problem can be ill-defined for several different reasons. We concentrate on the following particular cases. We will call
We will say that
PATH uses both function and Jacobian information in its attempt to solve the MCP. Therefore, both of these definitions are relevant. We discuss cases where the function and Jacobian are ill-defined in the next two subsections. We illustrate uses for the merit function information and final point statistics within the context of these problems.
Function Undefined We begin with a one-dimensional problem for which
Here
We are able to perform this analysis because the dimension of the problem is small. Preprocessing linear problems can be done by the solver in an attempt to detect obviously inconsistent problems, reduce problem size, and identify active components at the solution. Similar processing can be done for nonlinear models, but the analysis becomes more difficult to perform. Currently, PATH only checks the consistency of the bounds and removes fixed variables and the corresponding complementary equations from the model.
A modeler would likely not know a priori that a problem has no solution and would thus attempt to formulate and solve it. GAMS code for the model above is provided in Figure 8. We must specify an initial value for
Figure 8: GAMS Code for Ill-Defined Function
positive variable x; equations F; F.. 1 / x =g= 0; model simple / F.x /; x.l = 1e-6; solve simple using mcp;
After setting the starting point, GAMS generates the model, and PATH proceeds to "solve" it. A portion of the output relating statistics about the solution is given in Figure 9 PATH uses the Fischer Function indicator as its termination criteria by default, but evaluates all of the merit functions given in Section Merit Functions at the final point. The Normal Map merit function, and to a lesser extent, the complementarity error, indicate that the "solution" found does not necessarily solve the MCP.
Figure 9: PATH Output for Ill-Defined Function
FINAL STATISTICS Inf-Norm of Complementarity . . 1.0000e+00 eqn: (F) Inf-Norm of Normal Map. . . . . 1.1181e+16 eqn: (F) Inf-Norm of Minimum Map . . . . 8.9441e-17 eqn: (F) Inf-Norm of Fischer Function. . 8.9441e-17 eqn: (F) Inf-Norm of Grad Fischer Fcn. . 8.9441e-17 eqn: (F) FINAL POINT STATISTICS Maximum of X. . . . . . . . . . 8.9441e-17 var: (X) Maximum of F. . . . . . . . . . 1.1181e+16 eqn: (F) Maximum of Grad F . . . . . . . 1.2501e+32 eqn: (F) var: (X)
To indicate the difference between the merit functions, Figure 10 plots them all for this simple example. We note that as

The natural residual and Fischer function tend toward
for a fixed
Figure 11: PATH Output for Well-Defined Function
FINAL STATISTICS Inf-Norm of Complementarity . . 1.0000e-14 eqn: (G) Inf-Norm of Normal Map. . . . . 1.0000e+06 eqn: (G) Inf-Norm of Minimum Map . . . . 1.0000e-20 eqn: (G) Inf-Norm of Fischer Function. . 1.0000e-20 eqn: (G) Inf-Norm of Grad Fischer Fcn. . 1.0000e-20 eqn: (G) FINAL POINT STATISTICS Maximum of X. . . . . . . . . . 1.0000e-20 var: (X) Maximum of F. . . . . . . . . . 1.0000e+06 eqn: (G) Maximum of Grad F . . . . . . . 1.0000e+12 eqn: (G) var: (X)
In this case, the Normal Map is quite large and we might think that the function and Jacobian are undefined. When only the normal map is non-zero, we may have just mis-identified the optimal basis. By setting the merit_function normal
option, we can resolve the problem, identify the correct basis, and solve the problem with all indicators being close to zero. This example illustrates the point that all of these tests are not infallible. The modeler still needs to do some detective work to determine if they have found a solution or if the algorithm is converging to a point where the function is ill-defined.
Jacobian Undefined Since PATH uses a Newton-like method to solve the problem, it also needs the Jacobian of
Using PATH and starting from the point
Figure 12: PATH Output for Ill-Defined Jacobian
FINAL STATISTICS Inf-Norm of Complementarity . . 1.0000e-07 eqn: (F) Inf-Norm of Normal Map. . . . . 1.0000e-07 eqn: (F) Inf-Norm of Minimum Map . . . . 1.0000e-07 eqn: (F) Inf-Norm of Fischer Function. . 2.0000e-07 eqn: (F) Inf-Norm of Grad FB Function. . 2.0000e+00 eqn: (F) FINAL POINT STATISTICS Maximum of X. . . . . . . . . . 1.0000e-14 var: (X) Maximum of F. . . . . . . . . . 1.0000e-07 eqn: (F) Maximum of Grad F . . . . . . . 5.0000e+06 eqn: (F) var: (X)
We can see that the gradient of the Fischer Function is nonzero and the Jacobian is beginning to become large. These conditions indicate that the Jacobian is undefined at the solution. It is therefore important for a modeler to inspect the given output to guard against such problems.
If we start from
Poorly Scaled Models
Well-defined problems can still have various numerical problems that impede the algorithm's convergence. One particular problem is a badly scaled Jacobian. In such cases, we can obtain a poor "Newton" direction because of numerical problems introduced in the linear algebra performed. This problem can also lead the code to a point from which it cannot recover.
The final model given to the solver should be scaled such that we avoid numerical difficulties in the linear algebra. The output provided by PATH can be used to iteratively refine the model so that we eventually end up with a well-scaled problem. We note that we only calculate our scaling statistics at the starting point provided. For nonlinear problems these statistics may not be indicative of the overall scaling of the model. Model specific knowledge is very important when we have a nonlinear problem because it can be used to appropriately scale the model to achieve a desired result.
We look at the titan.gms
model in MCPLIB, that has some scaling problems. The relevant output from PATH for the original code is given in Figure 13.
Figure 13: PATH Output - Poorly Scaled Model
INITIAL POINT STATISTICS Maximum of X. . . . . . . . . . 4.1279e+06 var: (w.29) Maximum of F. . . . . . . . . . 2.2516e+00 eqn: (a1.33) Maximum of Grad F . . . . . . . 6.7753e+06 eqn: (a1.29) var: (x1.29) INITIAL JACOBIAN NORM STATISTICS Maximum Row Norm. . . . . . . . 9.4504e+06 eqn: (a2.29) Minimum Row Norm. . . . . . . . 2.7680e-03 eqn: (g.10) Maximum Column Norm . . . . . . 9.4504e+06 var: (x2.29) Minimum Column Norm . . . . . . 1.3840e-03 var: (w.10)
The maximum row norm is defined as
and the minimum row norm is
Similar definitions are used for the column norm. The norm numbers for this particular example are not extremely large, but we can nevertheless improve the scaling. We first decided to reduce the magnitude of the a1
block of equations as indicated by PATH. Using the GAMS modeling language, we can scale particular equations and variables using the .scale attribute. To turn the scaling on for the model we use the .scaleopt model attribute. After scaling the a1
block, we re-ran PATH and found an additional block of equations that also needed scaling, a2
. We also scaled some of the variables, g
and w
. The code added to the model follows:
titan.scaleopt = 1; a1.scale(i) = 1000; a2.scale(i) = 1000; g.scale(i) = 1/1000; w.scale(i) = 100000;
By scaling these equation and variable blocks, we have improved the model scaling. The statistics for the manually scaled model are given in Figure 14.
Figure 14: PATH Output - Well-Scaled Model
INITIAL POINT STATISTICS Maximum of X. . . . . . . . . . 1.0750e+03 var: (x1.49) Maximum of F. . . . . . . . . . 3.9829e-01 eqn: (g.10) Maximum of Grad F . . . . . . . 6.7753e+03 eqn: (a1.29) var: (x1.29) INITIAL JACOBIAN NORM STATISTICS Maximum Row Norm. . . . . . . . 9.4524e+03 eqn: (a2.29) Minimum Row Norm. . . . . . . . 2.7680e+00 eqn: (g.10) Maximum Column Norm . . . . . . 9.4904e+03 var: (x2.29) Minimum Column Norm . . . . . . 1.3840e-01 var: (w.10)
For this particular problem PATH cannot solve the unscaled model, while it can find a solution to the scaled model. Using the scaling features of the GAMS language and the information provided by PATH we are able to remove some of the problem's difficulty and obtain better performance from PATH.
It is possible to get even more information on initial point scaling by inspecting the GAMS listing file. The equation row listing gives the values of all the entries of the Jacobian at the starting point. The row norms generated by PATH give good pointers for starting to use the row listing.
Not all of the numerical problems are directly attributable to poorly scaled models. Problems for which the Jacobian of the active constraints is singular or nearly singular can also cause numerical difficulty as illustrated next.
Singular Models
Assuming that the problem is well-defined and properly scaled, we can still have a Jacobian for which the active constraints are singular or nearly singular (i.e. it is ill-conditioned). When problems are singular or nearly singular, we are also likely to have numerical problems. As a result the "Newton" direction obtained from the linear problem solver can be very bad. In PATH, we can use proximal perturbation or add artificial variables to attempt to remove the singularity problems from the model. However, it is most often beneficial for solver robustness to remove singularities if possible.
The easiest problems to detect are those for which the Jacobian has zero rows and columns. A simple problem for which we have zero rows and columns is:
Note that the Jacobian,
Figure 15: PATH Output - Zero Rows and Columns
INITIAL POINT STATISTICS Zero column of order. . . . . . 0.0000e+00 var: (X) Zero row of order . . . . . . . 0.0000e+00 eqn: (F) Total zero columns. . . . . . . 1 Total zero rows . . . . . . . . 1 Maximum of F. . . . . . . . . . 1.0000e+00 eqn: (F) Maximum of Grad F . . . . . . . 0.0000e+00 eqn: (F) var: (X)
We display in the code the variables and equations for which the row/column in the Jacobian is close to zero. These situations are problematic and for nonlinear problems likely stem from the modeler providing an inappropriate starting point or fixing some variables resulting in some equations becoming constant. We note that the solver may perform well in the presence of zero rows and/or columns, but the modeler should make sure that these are what was intended.
Singularities in the model can also be detected by the linear solver. This in itself is a hard problem and prone to error. For matrices which are poorly scaled, we can incorrectly identify "linearly dependent" rows because of numerical problems. Setting output_factorization_singularities yes
in an options file will inform the user which equations the linear solver thinks are linearly dependent. Typically, singularity does not cause a lot of problems and the algorithm can handle the situation appropriately. However, an excessive number of singularities are cause for concern. A further indication of possible singularities at the solution is a lack of quadratic convergence to the solution.
Case Study: Von Thunen Land Model
We now turn our attention towards using the diagnostic information provided by PATH to improve an actual model. The Von Thunen land model is a problem recognized in the mathematical programming literature for its computational difficulty. We attempt to understand more carefully the facets of the problem that make it difficult to solve. This will enable us to outline and identify these problems and furthermore to extend the model to a more realistic and computationally more tractable form.
Classical Model
The problem is cast in the Arrow-Debreu framework as an equilibrium problem.The basic model is a closed economy consisting of three economic agents, a landowner, a worker and a porter. There is a central market, around which concentric regions of land are located. Since the produced goods have to be delivered to the market, this is an example of a spatial price equilibrium. The key variables of the model are the prices of commodities, land, labour and transport. Given these prices, it is assumed that the agents demand certain amounts of the commodities, which are supplied so as to maximize profit in each sector. Walras' law is then a consequence of the assumed competitive paradigm, namely that supply will equal demand in the equilibrium state.
We now describe the problems that the consumers and the producers face. We first look at consumption and derive a demand function for each of the consumer agents in the economy. Each of these agents has a utility function, that they wish to maximize subject to their budgetary constraints. As is typical in such problems, the utility function is assumed to be Cobb-Douglas:
where the
where
Note that this assumes the prices of the commodities
The supply side of the economy is similar. The worker earns a wage
Consider the production
where
Considering all such demands, this clearly assumes the prices of inputs
Transportation is provided by a porter, earning a wage
where
This is intuitively clear; it states that commodity
The above derivations assumed that the producers and consumers acted as price takers. Walras' law is now invoked to determine the prices so that markets clear. The resulting complementarity problem is:
Note that in (15), (16) and (17), the amounts of labour, land and transport are bounded from above, and hence the prices on these inputs are determined as multipliers (or shadow prices) on the corresponding constraints. The final relationship (18) in the above complementarity problem corresponds to market clearance; prices are nonnegative and can only be positive if supply equals demand. (Some modelers multiply the last inequality throughout by
The Arrow-Debreu theory guarantees that the problem is homogeneous in prices;
Unfortunately, in this formulation even after fixing a numeraire, some of the variables
In order to test our diagnostic information, we implemented a version of the above model in GAMS. The model corresponds closely to the MCPLIB model pgvon105.gms except we added more regions to make the problem even more difficult. The model file has been documented more fully, and the data rounded to improve clarity.
Our first trial was to solve the model without fixing a numeraire. In this case, PATH 4.x failed to find a solution. At the starting point, the indicators described in Sectiion Ill-Defined Models are reasonable, and there are no zero rows/columns in the Jacobian. At the best point found, all indicators are still reasonable. However, the listing file indicates a large number of division by zero problems occurring in (16). We also note that a nonzero proximal perturbation is used in the first iteration of the crash method. This is an indication of singularities. We therefore added an option to output factorization singularities, and singularities appeared in the first iteration. At this point, we decided to fix a numeraire to see if this alleviated the problem.
We chose to fix the labour wage rate to 1. After increasing the iterations allowed to 100,000, PATH 4.x solved the problem. The statistics at the solution are cause for concern. In particular, the gradient of the Fischer function is 7 orders of magnitude larger than all the other residuals. Furthermore, the Jacobian is very large at the solution point. Looking further in the listing file, a large number of division by zero problems occur in (16).
To track down the problem further, we added an artificial lower bound on the variables
Although the problem is solved, there is concern on two fronts. Firstly, the gradient of the Fischer function should go to zero at the solution. Secondly, if a modeler happens to make the artificial lower bounds on the variables a bit larger, then they become active at the solution, and hence the constraint that has been dropped by fixing the price of labour at 1 is violated at this point. Of course, the algorithm is unable to detect this problem, since it is not part of the model that is passed to it, and the corresponding output looks satisfactory.
We are therefore led to the conclusion that the model as postulated is ill-defined. The remainder of this section outlines two possible modeling techniques to overcome the difficulties with ill-defined problems of this type.
Intervention Pricing
The principal difficulty is the fact that the rental prices on land go to zero as proximity to the market decreases, and become zero for sufficiently remote rings. Such a property is unlikely to hold in a practical setting. Typically, a landowner has a minimum rental price (for example, land in fallow increases in value). As outlined above, a fixed lower bound on the rental price violates the well-established homogeneity property. A suggestion postulated by Professor Thomas Rutherford is to allow the landowner to intervene and "purchase-back" his land whenever the rental cost gets smaller than a certain fraction of the labour wage.
The new model adds a (homogeneous in price) constraint
and modifies (16) and (18) as follows:
Given the intervention purchase, we can now add a lower bound on
Nested Production and Maintenance
Another observation that can be used to overcome the land price going to zero is the fact that land typically requires some maintenance labour input to keep it usable for crop growth. Traditionally, in economics, this is carried out by providing a nested CES function as technology input to the model. The idea is that commodity
Note that the variable
Here
After making the appropriate modifications to the model file, PATH 4.x solved the problem on defaults without any difficulties. All indicators showed the problem and solution found to be well-posed.