Vous êtes sur la page 1sur 57

GRG2 USER'S GUIDE

Leon S. Lasdon* Allan D. Waren**

October 2, 1997

*Department of Management Science and Information Systems, The University of Texas at Austin, Austin, Texas 78712-1175 **Department of Computer and Information Science, College of Business

Administration, Cleveland State University, Cleveland, Ohio 44115

Contents Section 1. 2. Introduction........................................................................... Installing GRG2 on a Particular Machine............................ 2.1 Machine Dependent Parameters................................ 2.2 Program Structure and Memory Requirements........ 2.3 Input and Output Units............................................... Memory Allocation .............................................................. User-Supplied Subroutines................................................... 4.1 Required Subroutine GCOMP................................... 4.2 Optional Subroutine PARSH..................................... 4.3 Optional Subroutine REPORT................................... Organization of the Input Data File...................................... 5.1 Problem Size .............................................................. 5.2 Problem Name............................................................ 5.3 Problem and Optimizer Data..................................... 5.3.1 Variables Sections........................................ a. Specification of Bounds....................... b. Initial Values......................................... c. Variable Names.................................... 5.3.2 Functions Sections........................................ a. Specifications of Bounds on Functions b. Function Names.................................... 5.3.3 Program Parameters Sections...................... a. Output Print Control............................. b. Limits on Iterations............................... c. Tolerances............................................. d. Methods................................................. 5.4 Commands .............................................................. Example Problem--Data File Interface................................ 6.1 Problem Statement..................................................... 6.2 GCOMP .............................................................. 6.3 Input Data .............................................................. 6.4 Output Data .............................................................. 6.4.1 Echo of Input Data....................................... 6.4.2 Initial Values................................................. 6.4.3 Final Results................................................. 6.4.4 Run statistics................................................. 6.4.5 Expanded output........................................... GRG2 Termination Messages............................................... Page 1 3 3 3 4 5 6 6 7 8 10 10 10 11 11 11 12 13 13 13 14 14 14 15 16 17 18 19 19 19 20 20 20 22 24 25 26 31

3. 4.

5.

6.

7.

Section 8. GRG2 Options and Tolerances............................................. 8.1 Tolerances ............................................................ 8.2 Algorithmic Options................................................... 8.3 Revise Option ............................................................ Things to Try if GRG2 Isn't Working................................... 9.1 Errors in the Input Data or in GCOMP..................... 9.2 Incorrect User-Supplied Derivatives......................... 9.3 Inaccurate Numerical Derivatives............................. 9.4 Scaling......................................................................... 9.5 Bounds Which Must Not be Violated........................ 9.6 Local and Global Optima........................................... 9.7 Solution Not Accurate Enough.................................. 9.8 Changing GRG2 Tolerances or Options.................... Using GRG2 as Part of a Larger System.............................. 10.1 GRG2 Subroutine Interface GRGSUB...................... 10.2 Example Problem Using GRGSUB........................... 10.2.1 Problem Statement....................................... 10.2.2 GCOM for GRGSUB Example Problem.... 10.2.3 Program for GRGSUB Example Problem... 10.2.4 Output for GRGSUB Example Problem..... Unconstrained Minimization and Optimal Control.............

Page 32 32 32 33 34 34 34 34 35 36 36 36 37 38 38 42 42 43 44 47 48 50

9.

10.

11.

References.............................................................................................

ii

GRG2 USER'S GUIDE 1. Introduction GRG2 is a FORTRAN program which solves nonlinear problems of the following form: minimize or maximize gk(x) subject to 1b(n+i)<gi(x)<ub(n+i) i = 1,2,...,m but i not equal to k (1) 1b(i)<xi<ub(i) i = 1,2,...,n. In the above problem x is a vector of n real-valued variables. The gi are real-valued functions of x, and may be linear or nonlinear. There are m such functions, one of which is the objective and the others are equality constraints, inequality constraints, or ignored. Upper and lower bounds on the variables are optional and if present are not treated as additional constraint functions but are handled separately. The program solves problems of this form by the Generalized Reduced Gradient (GRG) algorithm (see references 1-4 for a description and further references). The user is required to prepare a subroutine GCOMP which computes the values of g1,...,gm for any given vector x. The user also provides data specifying the upper and lower bounds as well as other parameters. GRG2 uses first partial derivatives of each function g1 with respect to each xi variable. These are automatically computed by finite difference approximation (either forward or central differences) unless the user supplies a subroutine PARSH, which evaluates them using formulas or other methods. GRG2 optimizes using two phases. If the initial point supplied by the user does not satisfy all gi constraints, a phase I optimization is started. The phase I objective function is the sum of the constraint violations plus, optionally, a fraction of the true objective. This optimization terminates either with a message that the problem is infeasible or with a feasible solution. Beware, if an infeasibility message is produced, the program may have become stuck at a local minimum of the phase I objective (or too large a part of the true objective was incorporated), and the problem may actually have feasible solutions. The suggested remedy, if you suspect that this is so, is to choose a different starting point (or reduce the proportion of the true objective) and try again. Phase II begins with a feasible solution, either found by phase I or with the user provided starting point if it is feasible, and attempts to optimize the objective function provided by the user. It produces a sequence of feasible points, whose objective value never worsens (and usually improves). There are two ways to use GRG2--through a file interface and as a subroutine. The file interface employs a sequential file consisting of fixed format 80 character records to
1

communicate problem data, and GRG2 parameters and options to GRG2. Solution information is written to an output file or a printer. The file interface is described in sections 5 and 6. The subroutine interface permits GRG2 to be called from a user program, with all input and output (except for specification of the problem functions) passed through the argument list of subroutine GRGSUB. It is described in section 10. GRG2 will run on any machine which has a FORTRAN compiler and sufficient memory.

2.

Installing GRG2 on a Particular Machine

2.1 Machine Dependent Parameters All computations in GRG2 are performed using double precision arithmetic, and all real variables are declared double precision. GRG2 uses some parameters whose values depend on the computer being used. These are all set in subroutine INITLZ. When installing GRG2 on any machine, the user should check INITLZ to see that all values defined there are the correct ones for that machine. Incorrect values can cause GRG2 to malfunction. The parameters a user needs to set in INITLZ are EPS, IWORDI, and IWORDR. EPS is the machine precision, i.e., the largest positive number, e, such that 1 + e = 1 on the machine being used. IWORDR is the number of single precision REAL variables (REAL *4 on byte oriented machines) contained in one word of the Z array (see section 2.2 for an explanation of what Z is). IWORDI is the number of INTEGER variables contained in one word of the Z array. Proper values for most machines are EPS = 1.0D-16, IWORDI = IWORDR =2. 2.2 Program Structure and Memory Requirements GRG2 is a modular program consisting of a number of subroutines, communicating by labelled COMMON blocks and argument lists, and a brief MAIN calling program. It can also be called as a subroutine as described in section 10. It has been written to provide the appearance of dynamic memory allocation with all arrays set up as portions of one large main array Z, so that redimensioning of arrays is never required. GRG2 contains about Fortran statements (excluding comments). The object code, with NCORE (see below) set at 7000, requires approximately bytes of core on a PC. The additional memory needed to solve a given problem depends on problem size, as explained below and in section 3. The following is a listing of the MAIN program: DOUBLE PRECISION Z(7000) INTEGER IOIN,IOOUT,IODUMP COMMON/IOUNIT/IOIN,IOOUT,IODUMP INTEGER NCORE DATA NCORE/7000/ IOIN = 1 IOOUT = 2 IODUMP = 3 CALL GRG(Z,NCORE)
3

STOP END NCORE is equal to the dimension of Z and only these two numbers above (i.e., the 7000's) need be changed to run in a smaller or larger amount of main memory. The various other arrays are specifically dimensioned according to the actual problem size, i.e., actual number of variables and number of functions, for best use of available memory space. A value of is large enough to accomodate 50 variables and 51 functions on a PC. Requirements for other problem sizes are discussed in section 3. A detailed description of the various subroutines involved in the optimization process can be found in reference [2]. If the file interface is being used, GRG2 returns to the MAIN program after solving the problem(s) specified in its input data file. If the subroutine interface GRGSUB is used, all solution information is returned in GRGSUB's argument list. 2.3 Input and Output Units As shown above, the logical input and output units for GRG2 are called IOIN and IOOUT. They are assigned the values 1 and 2 in the MAIN program, and these values may be changed if desired.

3.

Memory Allocation The minimum size for the Z array (see Section 2.2 for a description of Z) depends on the following factors: IWORDR = the number of REAL*4 variables contained in one position of the Z array. IWORDI = the number of INTEGER variables contained in one position of the Z array. N = the number of variables (n in equations 1). M = the number of functions (constraint, objective and ignored), i.e., the largest subscript for gi (m in equations 1). MAXR = an upper limit on the dimensions of a triangular matrix R (see ref. [4] for description) used in the optimization process (default MAXR = N). MAXB = an upper limit on the number of constraint functions gi that can be equal to a bound at any stage of the optimization process (default MAXB = M). Usually the default values for MAXR and MAXB are adequate unless the memory available is limited compared to the problem size. In this instance good estimates of MAXR and MAXB may help. If the default value is not used, MAXR should be greater than or equal to A - B, where A is the maximum number of the variables X(1),...,X(N) which will be free (not at a bound) at any stage of the optimization process, and B is the minimum number of constraint functions which will be at a bound at any stage of the optimization process. Hence if the user expects many variables or constraints to be at bounds, MAXR can be set to a value less than N. If, in the course of optimization, the size of R exceeds MAXR, GRG2 automatically changes from its preferred optimization method (the BFGS quasi-Newton method) to a Conjugate Gradient method. MAXB represents the maximum number of constraints that can be at bounds at the same time. If this value is exceeded then the system stops with an appropriate error message. NCORE, the dimension of Z, must be greater than MAXB* max(MAXB,N) + MAXR*(MAXR+1)/2 + 12*N + 8*M + 10*MAXB + (N*M/IWORDR) + (7*N + 3*M + 4*MAXB)/IWORDI + 14 A value of 7000 will accomodate 51 variables and 51 rows on a PC.
5

4.

User-Supplied Subroutines

4.1 Required Subroutine GCOMP Structure SUBROUTINE GCOMP(G,X) DOUBLE PRECISION G(*),X(*) FORTRAN statements to compute G(1),G(2),...,G(M) given X(1),X(2),...,X(N) RETURN END Arguments G = (G(1),G(2),...,G(M)) = Vector of M constraint functions and objective function to be evaluated at the current values of X. X = (X(1),X(2),...,X(N)) = vector of N variables at which G is to be evaluated. Purpose To compute the constraint and objective functions for the given values of the variables. GCOMP can also be used to read in any data used in these computations. In this case the system provided variable INIT can be used to ensure that reading takes place only on the initial call to GCOMP. INIT is set to 1 on the first call to CGOMP at the start of each new optimization cycle and to 0 otherwise. The following statements in GCOMP provide this function: COMMON/INITBK/INIT, LASTCL IF (INIT.EQ.O) GO TO label where label is a FORTRAN statement label following the read sequence. The statements in GCOMP that evaluate G given X need not be explicit closed form formulas. GCOMP can call other subroutines, which can themselves evaluate FORTRAN expressions, read or write data, or perform numerical operations like solving algebraic or differential equations. To obtain acceptable accuracy and efficiency, all steps in evaluating G should be performed in double precision arithmetic if possible. This may not be possible when algebraic or differential equations must be solved to evaluate G. In such cases, these equations should be solved to as high accuracy as possible, especially if GRG2 is approximating first derivatives of G by finite differences. For more information on finite differencing, see section 9.3.
6

4.2 Optional Subroutine PARSH Note If this subroutine is not provided by the user, one of two system subroutines is used instead. One of these routines computes derivatives by forward differences requiring N calls to GCOMP and the other computes derivatives by central differences using 2*N GCOMP calls. Structure SUBROUTINE PARSH (G,X,MP1,N,GRAD) INTEGER MP1,N DOUBLE PRECISION G(*),X(*),GRAD (MP1,N) FORTRAN statements to compute GRAD(I,J) for I = 1,...,MP1 and J = 1,...,N for the current point X. RETURN END Arguments G = (G(1),G(2),...,G(M)) = vector of M constraint and objective functions evaluated at the current point X. X = (X(1),X(2),...,X(N)) = vector of N variables at which GRAD is to be evaluated. MP1 = largest G subscript = total number of constraint and objective functions N = number of variables GRAD = two dimensional array of M rows and N columns whose (i, j) element is the partial derivative of gi with respect to xj. Purpose To compute gradients of the constraint and objective functions given the current values of X and G. Comment and Warning Formulae for computing the various elements of GRAD usually have terms in common with formulae for computing the functions gi. The user can reduce computation time (often very significantly) by communicating such terms from GCOMP to PARSH using his own COMMON blocks or using the array G in the argument list of PARSH. Any common blocks used must have names distinct from any of the GRG2 common blocks. However, such data transfers can produce incorrect results unless certain precautions are taken. The logic of
7

GRG2 is such that, if X is currently equal to say, X1, and PARSH is called, the last call to GCOMP may have used an X other than X1, say X2. If so, the information communicated in COMMON from GCOMP to PARSH was evaluated at X2, and the computed partial derivatives will be wrong. This can cause the optimization to terminate prematurely. This problem can be solved as follows. Include the following common block in PARSH: COMMON/INITBK/INIT,LASTCL and, if any information is transferred from GCOMP to PARSH, insert the following statement in PARSH before any of this information is used: IF (LASTCL.EQ.O) Call GCOMP(G,X) The variable LASTCL is set to zero by GRG2 if the last GCOMP call did not occur at the current X; otherwise, LASTCL is one. 4.3 Optional Subroutine REPORT Note If this subroutine is not provided by the user, a dummy subroutine which performs no functions will be automatically used. Structure SUBROUTINE REPORT (G,X,MP1,N,CON,VAR,X0) INTEGER N,MP1 DOUBLE PRECISION G(MP1),X(N),X0(N) CHARACTER*8 CON(MP1),VAR(N) FORTRAN statements to produce any output report needed by the user. This subroutine is called twice each complete cycle: once when the initial data is read and once after the optimization is terminated. RETURN END Arguments G,X,MP1 and N as in section 4.3 above CON = (CON(1),CON(2),...,CON(M)) = vector of names for the M constraint and objective functions as originally provided in the input data. Each name contains 8 characters. VAR = (VAR(1),VAR(2),...,VAR(N)) = vector of names for the N variables X0 = (X0(1),X0(2),...,X0(N)) = vector of initial values for the N variables.

Purpose To provide the user with the ability to expand the output reporting. This subroutine is called each time new data is input and at the conclusion of each complete optimization cycle. Note that some information at both start and finish will be automatically output by the system provided subroutine OUTRES (see section 6). If the user does not wish REPORT to produce any output at the initial call, the following statements need to be incorporated in REPORT: COMMON/INITBK/INIT, LASTCL IF (INIT.EQ.1) RETURN At the beginning of each optimization cycle GRG2 sets INIT to 1 just before the first call to GCOMP and, after the first call to REPORT, GRG2 sets INIT to 0.

5.

Organization of the Input Data File This section is not relevant if the subroutine interface is being used. If the data file interface is used, input data is communicated to GRG2 in a sequential file consisting of fixed format 80 character records. This section describes the formats of these records. In the following record format layouts, lower case items are numbers or characters to be provided by the user. Those items read as decimal numbers (FORTRAN E format), should have a decimal point included, and must be wholly within the fields assigned to them. If no value is to be assigned, the field may be empty. Those items which are read in as characters (FORTRAN A format) may include any characters desired within the field assigned to the item. Words shown in capital letters in the record layouts are specific characters to be input by the user. In some cases short forms for these words are permitted so the letters that must be present are underlined, the remainder being optional. The symbol b stands for one blank character and b's for all blanks in a defined field. If there is nothing shown for any character position(s) then those positions are ignored completely by the program. 5.1 Problem Size The first record is always required and specifies the problem size. It has the following format: Size Record Position: Contents: Format: Here n m maxr maxb 1-5 n I5 6 - 10 m I5 11 -15 maxr I5 16 - 20 maxb I5

= = = =

number of problem variables number of functions (including objective) limit on size of Hessian with a default value of n if either a zero or a blank appears limit on number of binding constraints with default value of m-1 if either a zero or a blank appears.

5.2 Problem Name The second record, which is optional, provides problem identification used as a heading in output reports. This record consists of

10

Name Record Position: Contents: 1-5 NAME 6 - 80 Title

where the characters NAM must appear and title consists of any characters. 5.3 Problem and Optimizer Data. The next part of the data file consists of a number of sections providing information about variables, functions and program parameters. These sections can appear in any order and each, or all, may be omitted in which case default values are supplied. Each section, if present, begins with a header record containing the section name, starting in column 1, and terminates with a trailer record with the word END in columns 1 to 3. Only the first 3 letters of any section name must be present but everything in the record will be printed. The header and trailer formats are Section Header Position: Contents: 1-3 id Section Trailer Position: Contents: 1-3 END 4 - 80 b's 4 - 80 characters

id is the first 3 characters of a section identifier and characters are any characters. 5.3.1 Variables Sections a. Specification of Bounds This section identifer is BOUNDS and the format for the data records in Bounds Data Position: Contents: Format: 1 b 2 type A3 3 b 4-6 sub1 I3 7 - 10 sub2 I4 11 -30 no1 E20.4 31 - 50 no2 E20.4

this section is

If sub2 is absent or zero then this record provides bounds information for only one variable, that one whose subscript appears as sub1. If sub2 is assigned a value then sub2 must

11

be greater than sub1 and all variables having subscripts form sub1 to sub2 are assigned the same bounds. These bounds are specified by the type indicator and the two real numbers no1 and no2 as shown below: type Meaning E variable fixed and equal to no1 G variable must be greater than or equal to no1 L variable must be less than or equal to no1 N variable is unconstrained in value R variable value ranges from no1 up to no2 Default Values: All variables not specified are assumed to be unbounded (type N). b. Initial Values This section identifier is INITIAL and its header, if present, must be followed by a second record, with the same format as a section header, specifying one of the following id values: id Meaning SEPARATE TOGETHER if initial values for individual variables will be entered with the separate format (see below) if initial values for all the variables will be read in consecutive order with eight values per record, each value occupying 10 characters (see below). if this is a "REVISE" run (see section 5.4) and the previous initial values for the variables are to be used again.

X0b

The format for initial separate data is Initial Separate Data Position: Contents: Format: 1-3 b's A3 4-6 sub1 I3 7 - 10 sub2 I4 11 - 30 no1 E20.4 31 - 50 b's E20.4

If sub2 is absent or zero this record assigns the initial value no1 to the variable whose subscript is sub1. If sub2 is not zero or blank then it must be greater than sub1. In this case all variables from sub1 through sub2 are assigned the same initial value, no1. A default value of 0.0 is assigned to all variables not explicitly initialized. For initial together data, initial values for all variables in sequence from 1 to n must appear consecutively, eight values per record as shown below.

12

Initial Together Data Position Contents: Format: 1 - 10 no. 11 - 20 no. 21 - 30 no. 31 - 40 no. 8E10.4 41 - 50 no. 51- 60 no. 61 - 70 no. 71 - 80 no.

c. Variable Names The header record with section identifier VARIABLES is followed by one record for each variable to be named and then by a standard trailer record. Any variable not named has its name field filled by blanks as default value. Variable Name Data Position: Contents: Format: 1-8 name A8 2X 9 - 10 11 - 15 sub I5

The variable whose subscript is sub is assigned a name equal to name. These names are used only for output reporting. 5.3.2 Functions Sections a. Specification of Bounds on Functions This section identifier is ROWS and the format for the data records in this Rows Data Position: Contents: Format: 1 b 2 type A3 3 b 4-6 sub1 I3 7 - 10 sub2 I4 11 - 30 no1 E20.4 31 - 50 no2 E20.4

section is

If sub2 is blank or zero then this record provides bounds for only one function, that one whose subscript is given as sub1. If sub2 is specified then it must be equal to or greater than sub1 and all functions from sub1 to sub2 are assigned the same bounds. These bounds are specified by the type indicator and the two real numbers, no1 and no2, as shown: type Meaning E equality constraint equal to no1 G inequality constraint greater than or equal to no1 L inequality constraint less than or equal to no1

N O R

not constrained, function ignored except for output of function value objective function inequality constraint ranging from no1 up to no2.

Default Values: If the objective function is not specified then it is assumed to be the last function provided. All other functions not explicitly declared are treated as inequality constraints greater than or equal to zero. b. Function Names The section identifier FUNCTIONS on the header is followed by one record for each function to explicitly named and then by a standard trailer record. Unnamed functions are assigned blanks as default names. Function Name Data Position: Contents: Format: 1-8 name A8 2X 9 - 10 11 - 15 sub I5

The function whose subscript is sub is assigned a name equal to name. These names are used only for output reporting. 5.3.3 Program Parameters Sections a. Output Print Control The section id is PRINT and the data record format is Print Level Indicator Position: Contents: Format: 1-3 type A3 3X 4-6 7 - 10 no I4

The type specifications are listed below. Note that each higher level print includes all of the lower level prints plus the added items shown below. type IPRINT IPRINT no 0 1 Meaning Suppress all output printing except initial and final reports. Print one line of output for each one dimensional search. This is the default print level.

IPRINT IPRINT

2 3

Provide more detailed information on the progress of each one dimensional search (see section 6 for sample output). Expand the output to include the problem function values and variable values (G and X) at each iteration as well as the separation of constraints into binding and nonbinding and variables into basic, superbasic and nonbasic. At each iteration the reduced gradient, the search direction and the tangent vector are printed. Provides details of the basis inversion process including the initial basis and its inverse. Also display the variable values and constraint errors for each Newton interation. This is the maximum level of print available and includes all of the above along with detailed progress of the basis construction phase, including the basis inverse at each pivot. Note that print levels 3, 4, 5 and 6 are primarily intended for debugging of the program and/or the problem.

IPRINT IPRINT

4 5

IPRINT

PN4

If n is greater than zero then IPRINT will be set to 4 after n iterations. If n is less than zero the initial gradient array GRAD (see section 4.2) will be printed and then PN4 reset to zero. If n is zero then PN4 is ignored. If n is greater than zero then IPRINT will be set to 5 after n iterations. Default value is zero. If n is greater than zero then IPRINT will be set to 6 after n iterations. Default value is zero. If m is greater than zero then, for every m' th iteration, print using the current value of IPR otherwise use IPR = 1. If m is greater than zero then provide an output DUMP on output unit 7 every m iterations. Default value is zero.

PN5 PN6 PERIOD DUMP

n n m m

b. Limits on Iterations The section id is LIMITS and the data format is the same as for the preceeding PRINT section. The type specifications are listed below. type NSTOP default value 3 Meaning If the fractional change in the objective is less than EPTOP for NSTOP consecutive iterations, the program will try some alternative strategies. If these do not produce an objective function change greater than EPTOP, the program will stop.

ITLIM

10

If subroutine NEWTON takes ITLIM iterations without converging satisfactorily (in its attempt to solve the binding constraint equations for the basic variable values), the iterations are stopped and corrective action is taken. If the number of completed one dimensional searches equals SEARCH, optimization will terminate.

SEARCH

10,000

c. Tolerances This section, identified by EPSILON, provides the user significant control over the various tolerances used in determining whether various processes have converged, whether elements used as pivots are sufficiently large and how large a fraction of the true objective should be included in the sum of the infeasibilities in phase I. Epsilon Data Position: Contents: Format: default value 10-4 1-3 type A3 7X 4 - 10 11 -20 value E10.4 21 - 80 b

type EPNEWT

Meaning A constraint is assumed to be binding if it is within this epsilon of one of its bounds. If a constraint is not binding and not within its bounds then the constraint is not satisfied. If it is desired to run the problem with EPNEWT initially set fairly large and then tightened at the end of the optimization then this is accomplished by assigning EPINIT the initial tolerance and EPNEWT the final one. The EPINIT specification must follow the EPNEWT specification. If the fractional change in the objective is less than EPTOP for NSTOP consecutive iterations, the program will stop. The program will also stop if the Kuhn-Tucker optimality conditions are satisfied within EPTOP. If, in constructing the basis inverse, the absolute value of a prospective pivot element is less than EPPIV, the pivot will be rejected and another pivot element will be sought. If nonzero, the phase I objective is augmented by a multiple of the true objective. The multiple is selected so that, at the initial point, the ratio of the true objective to the sum of the infeasibilities is PH1EP.

EPINIT

EPNEWT

EPTOP

10-4

EPPIV

10-3

PH1EP

0.0

d. Methods This section, identified by METHODS, is used to select one of several methods for performing a variety of tasks. These, and the data format, are described below: Methods Data Position: 1-3 Contents: type Format: A3 Task Derivatives type FDF meaning Partial Derivatives gi/ xj are to be approximated by numerical forward differences. This is the default if not overridden. Partial derivatives are to be approximated using numerical central difference. Partial derivatives are to be computed by a user provided subroutine, PARSH. Initial estimates of basic variables for each one dimensional search are to be computed using the estimates tangent vector and linear extrapolation. This is the default. Use quadratic extrapolation for estimating initial values of basic variables. Search directions, in which to vary the superbasic variables can be generated either by a variable metric method or by one of several conjugate gradient methods. This command requests the use of the quasi-Newton method. Note that this requires that maxr be equal to or greater than the number of superbasics at any stage. When the number of free variables which are not basic (i.e., the number of superbasics) exceeds maxr then GRG2 automatically switches from the quasi-Newton to a conjugate gradient method. DFP is the default choice if maxr is large enough. See section 5.1 to see how maxr is specified. The use of a conjugate gradient algorithm can be specified with this command. The user can control which conjugate gradient method will be used (either as specifically requested by the CG command or as a fallback method if maxr is specified at a smaller value than its default value of N). CG1 specifies that the Fletcher-Reeves formula [5] is to be used. The default is CG1 if not specified. Uses the Polak-Ribiere [5] formula.

FDC ANALYTIC Basic variable estimates TANGENT

QUADRATIC Method for Generating Search Directions DFP

CG Conjugate Gradient CG1

CG2

CG3 CG4 CG5 Sense of extremization . 5.4 Commands MIN or MAX

Uses Perry's [5] formula. Uses 1 step version of DFP quasi-Newton method. Uses 1 step version of BFGS quasi-Newton method. If the objective function is to be minimized enter MIN (or nothing since MIN is also the default value). If the objective function is to be maximized, then the command MAX must be entered

The command format and meanings are Command Position: Contents Format: Command GOb Meaning When the initial data has been completely input (sections 5.1, 5.2 and 5.3) the user then initiates processing with this command. This record is required. When the system has completed optimization of a specified problem (i.e., the stop criteria are met) then control returns to the data input phase. This command then permits the user to change any data items (except problem size -section 6.1) by simply providing new input data. Again, to solve the revised problem, the GO command must be used. If the user has previously dumped a problem (see 5.3.3.a) and wishes to restart processing from that point, then this command initiates reading from the input unit specified by unit. This specification is by means of a record with the word UNIT in columns 1-4 and the unit number in columns 9-10. The restart command and unit specification can then be followed either by additional problem data sections and the GO command, or the GO command alone. This command terminates the run and should be the last record of each data file. 1-3 commad A3 77X 4 - 80

REVISE

RESTART

STOP

6.

Example Problem--Data File Interface A typical nonlinear programming problem (number 11 in the Himmelblau text [7]) and its formulation for GRG2 are presented in detail in this section. 6.1 Problem Statement This problem has 5 variables, bounded above and below, a quadratic objective function and three quadratic constraints with both upper an lower bounds. The functions and bounds are given below. Minimize 5.3578547X3 + 0.8356891X1X5 + 37.293239X1 - 40792.141 Subject to 0 < 85.334407 + 0.0056858X2X5 + 0.0006262X1X4 - 0.0022053X3X5 < 92 90 < 80.51249 + 0.0071317X2X5 + 0.0029955X1X2 + 0.0021813X3*X3 < 110 20 < 9.300961 + 0.0047026X3X5 + 0.0012547X1X3 + 0.0019085X3X4 < 25 78 < X1 < 102 33 < X2 < 45 27 < X3 < 45 27 < X4 < 45 27 < X5 < 45 This problem is to be solved starting from two different starting points, one of which is feasible and the other infeasible. Feasible start point X = (78.62,33.44,31.07,44.18,35.22) Infeasible start point X = (78,33,27,27,27) 6.2 GCOMP The required FORTRAN subroutine GCOMP appears below. SUBROUTINE GCOMP(G,X) C HIMMELBLAU PROB 11, COLVILLE QUADRATIC IMPLICIT REAL*8(A-H,0-Z),INTEGER*2(I-N) DIMENSION G(4),X(5) G(1) = 85.334407 + 0.0056858*X(2)*X(5) + 0.0006262*X(1)*X(4) G(2) = 80.51249 + 0.0071317*X(2)*X(5) + 0.0029955*X(1)*X(2) 1 + 0.0021813*X(3)**2 G(3) = 9.300961 + 0.0047026*X(3)*X(5) + 0.0012547*X(1)*X(3) 1 + 0.0019085*X(3)*X(4) G(4) = 5.3578547*X(3)**2 + 0.8356891*X(1)*X(5) + 37.293239*X(1) 1 - 40792.141 RETURN END

6.3 Input Data The problem data file for this sample problem is reproduced in Figure 6.1. Note that all GRG2 parameters have been left at their default values. 5 4 NAME COLVILLE QUADRATIC (HIMMELBLAU PROB 11) ROWS R 1 0.0 92.0 R 2 90.0 110.0 R 3 20.0 25.0 END BOUNDS R 1 78.0 102.0 R 2 33.0 45.0 R 3 5 27.0 45.0 END INITIAL TOGETHER 78.62 33.44 31.07 44.18 35.22 END PRINT IPR 1 END GO STOP Figure 6.1: Input Data 6.4 Output Data This section describes output produced by GRG2 for the problem described in sections 6.1 - 6.3. 6.4.1 Echo of Input Data Figure 6.2 is a listing of the first section of output data for the sample problem of section 6. The numbers in the right hand margin have been added for ease in referencing the specific sections. This output section is always created if the data file interface is used, and may be turned off with the logical variable INPRNT if the subroutine interface is used. Depending on the problem size, it may require several pages. Lines 1 through 23 essentially echo the input data (see section 7.3), 24 through 27 specify the values of all user controllable program parameters and 28 through 31 specify which methods to be used. In detail, this output is as follows:

Line No.'s 1 2-5 6 7-25

Function Copies NAME data record(blank if absent) Problem size data as specified by user including defaults if applicable Actual size of the Z array Echo of input data sections. May be longer or shorter depending on specific input (see 6.3 for corresponding input data file) Values of epsilons Values of limits Values of print controls Specifies methods to be used

Users Guide Section 5.2 5.1 3 5.3-5.4

26-27 28 29 30-34

5.3.3.c 5.3.3.b 5.3.3.a 5.3.3.d 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

COLVILLE QUADRATIC (HIMMELBLAU PROB 11) NUMBER OF VARIABLES IS 5 NUMBER OF FUNCTIONS IS 4 SPACE RESERVED FOR HESSIAN HAS DIMENSION 5 LIMIT ON BINDING CONSTRAINTS IS 3 ACTUAL LENGTH OF Z ARRAY IS 213 ROWS 4.0 R 1 1 0.000000E+00 9.200000E+01 R 2 2 9.000000E+01 1.100000E+02 R 3 3 2.000000E+01 2.500000E+01 END BOUNDS R 1 1 7.800000E+01 1.020000E+02 R 2 2 3.300000E+01 4.500000E+01 R 3 5 2.700000E+01 4.500000E+01 END INITIAL TOGETHER 7.8620000E+01 3.3440000E+01 3.1070000E+01 4.4180000E+01 3.5220000E+01 END PRINT IPR 1 END GO EPNEWT = 1.0000E-04 EPINIT = 1.0000E-04 EPSTOP = 1.0000E-04

EPPIV = 1.0000E-03 PH1EPS = 0.00000E+00 NSTOP = 3 ITLIM = 10 SEARCH = 9999 IPR = 1 PN4 = 0 PN5 = 0 PN6 = 0 PER = 0 USE QUADRATIC EXTRAPOLATION FOR INITIAL ESTIMATES OF BASIC VARIABLES. OBJECTIVE FUNCTION WILL BE MINIMIZED. BFGS WILL BE USED IF # SUPERBASICS < = 5 FORWARD DIFF PARSHS USED; DELTA = 1.0000E-06 Figure 6.2: Output Data: Part 1

27 28 29 30 31 32 33

6.4.2 Initial Values Figure 6.3 is a listing of the second output section. In general, depending on the number of functions and variables, this information may also take several pages. This output consists of two parts, one for the problem functions (constraints and objective) and the other for the variables. The FUNCTIONS portion lists subscript, name, status, type, initial value and lower and upper limit (if any) for each function. The status refers to the function's initial value and specifies the following: Status Meaning b within but not at a bound *** violates bound EQ satisfied equality constraint UL equal to upper limit LL equal to lower limit. Type is user specified (see section 5.3.2.a) and the output values have the following meanings: Type Meaning EQ equality constraint GE inequality constraint with lower bound LE inequality constraint with upper bound NA not applicable, function ignored except for output of function value OBJ objective function RNGE inequality "range" constraint with both upper and lower bounds. The VARIABLES portion lists subscript, name, status, initial value and lower and upper limit (if any) for each variable. The status codes and meanings are listed below. Status b Meaning variable value satisfies limit(s) but is not at a limit

FX variable is fixed in value FREE variable is unconstrained in value UL variable is at its upper limit LL variable is at its lower limit. Note that any variable assigned an initial value outside of its bounds is automatically reset to the nearest bound. If this is not desirable then the variable bound must be stated as one of the regular constraints. For example, given that X(7) should be less than or equal to 40.0 but that a value of 64.5 is known to give a significantly better starting point (for various reasons) than 40.0 then one should proceed as follows: X(7) should be entered as a free variable with initial value 64.5, and an extra upper bounded constraint G(M+1) = X(7) < 40.0 should be added to the constraint set. OUTPUT OF INITIAL VALUES COLVILLE QUADRATIC (HIMMELBLAU PROB 11) SECTION 1 -- FUNCTIONS NO. 1 2 3 4 FUNCTION NAME STATUS TYPE RNGE RNGE RNGE OBJ INITIAL VALUE 9.1792729E+01 9.8892932E+01 2.0131578E+01 -3.0373948E+04 LOWER LIMIT 0.0000000E+00 9.0000000E+01 2.0000000E+01 UPPER LIMIT 9.2000000E+01 1.1000000E+02 2.5000000E+01

SECTION 2 -- VARIABLES NO. 1 2 3 4 5 VARIABLE NAME INITIAL STATUS VALUE 7.8620000E+01 3.3440000E+01 3.1070000E+01 4.4180000E+01 3.5220000E+01 LOWER LIMIT 7.8000000E+01 3.3000000E+01 2.7000000E+01 2.7000000E+01 2.7000000E+01 UPPER LIMIT 1.0200000E+02 4.5000000E+01 4.5000000E+01 4.5000000E+01 4.5000000E+01

ITN OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN UP STEP DEGEN NO. FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO DATE SIZE STEP 0 -3.037395E+04 0 5 0 3.329E+02 1.000E+00 F 0.000E+00 1 -3.049616E+04 1 4 0 7.101E+01 1.000E+00 F 1.027E-03 2 -3.062160E+04 2 3 0 6.482E+01 1.000E+00 F 1.430E-02 3 -3.062573E+04 2 2 0 6.463E+01 1.000E+00 F 5.123E-04 4 -3.064209E+04 2 1 0 6.382E+01 1.000E+00 F 3.124E-03 5 -3.066553E+04 2 1 0 6.192E+01 1.000E+00 T 0.000E+00 T TERMINATION CRITERION MET. KUHN-TUCKER CONDITIONS SATISFIED TO WITHIN 1.00000E-04 AT CURRENT POINT 5 -3.066553E+04 2 0 0 0.000E+00 1.000E+00 T 0.000E+00 T

Figure 6.3: Output Data: Part II 6.4.3 Final Results If the print level indicator IPR is set to 0 (see section 5.3.3.a) then no output is produced during the course of the iterations, with the exception of certain warning and termination messages. In this case, the next major output section lists the final values for the functions and variables as shown in Figure 6.4. As in the case of the initial values print, this print is divided into a FUNCTIONS section (which appears first) and a VARIABLES section. For each function, the subscript, name, initial value, final value, status, distance from nearest bound and Lagrange multiplier value are listed. The status refers to the function's final value and the status possibilities and their meanings are Status Meaning FREE within but not at a bound EQUALITY satisfied equality constraint UPPERBND equal to upper bound LOWERBND equal to lower bound OBJ objective IGNORED function ignored except for output of value VIOLATED constraint violates a bound. The distance from the nearest bound is specified as a number followed by a colon followed by the letter U or L specifying upper or lower bound for inequality constraints. If the current solution is feasible, the absolute value of this distance will be less than the input parameter EPNEWT, which is the feasibility tolerance. The Lagrange multiplier values are printed for all binding constraints (zero for nonbinding constraints). They are equal to the

derivative of the optimal objective value with respect to the constraint bound. In the variables section, the subscript number, name, initial and final values, status, distance from nearest bound and reduced gradient are listed for each variable. For variables, the status refers to the variable's classification at the last iteration, as basic, nonbasic or superbasic. Distance from nearest bound is quite similar to that for functions, with the exception that variables may be exactly at a bound. In this case the word LOWERBND or UPPERBND appears. FINAL RESULTS COLVILLE QUADRATIC (HIMMELBLAU PROB 11) SECTION 1 -- FUNCTIONS DISTANCE FROM NEAREST LAGRANGE STATUS BOUND MULTIPLIER UPPERBND -1.413E-05:U -4.03267E+02 FRE 8.841E+00:L LOWERBND 1.320E-05:L 8.09424E+02 OBJ

NO. 1 2 3 4

NAME

INITIAL VALUE 9.17927E+01 9.88929E+01 2.01316E+01 -3.03739E+04

FINAL VALUE 9.20000E+01 9.88405E+01 2.00000E+01 -3.06655E+04

SECTION 2 -- VARIABLES DISTANCE FROM NEAREST STATUS BOUND NONBASIC LOWERBND NONBASIC LOWERBND BASIC NONBASIC UPPERBND BASIC

NO. 1 2 3 4 5

NAME

INITIAL VALUE 7.86200E+01 3.34400E+01 3.10700E+01 4.41800E+01 3.52200E+01

FINAL VALUE 7.80000E+01 3.30000E+01 2.99952E+01 4.50000E+01 3.67759E+01

GRADIENT 4.89275E+01 8.43234E+01 2.995E+00:L -2.66392E+01 8.224E+00:U

Figure 6.4: Final Results 6.4.4 Run Statistics At the conclusion of each optimization run, some information concerning the number of times various processes occurred is listed as shown in Figure 6.5. Most of the items are self-explanatory. The value listed after the heading "ACTUAL FUNCTION CALLS (INC FOR GRADIENT)" will differ from "Function Calls" only if one of the internal finite difference PARSH routines is used. In this case each gradient call involves n (for

forward differences) or 2n (for central differences) function calls (to GCOMP) and these are added to all other function calls to give this value. If all the constraints are linear then linear extrapolation for the basic variables will be exact (except for roundoff error) and hence one would expect the number of NEWTON ITERATIONS to be zero. For fairly large systems one may have a few such iterations to correct for accumulated roundoff. However an AVERAGE larger than 0.1 for linear constraints should be considered cause for suspicion of the GCOMP routine. RUN STATISTICS COLVILLE QUADRATIC (HIMMELBLAU PROB 11) NUMBER OF ONE-DIMENSIONAL SEARCHES = 5 NEWTON CALLS = 7 NEWTON ITERATIONS = 7 AVERAGE = 1.00 FUNCTION CALLS = 16 GRADIENT CALLS = 6 ACTUAL FUNCTION CALLS (INC. FOR GRADIENT) = 46 NUMBER OF TIMES BASIC VARIABLE VIOLATED A BOUND = 3 NUMBER OF TIMES NEWTON FAILED TO CONVERGE = 0 TIMES STEPSIZE CUT BACK DUE TO NEWTON FAILURE = 0 Figure 6.5: Run Statistics 6.4.5 Expanded Output As IPR is increased, more and more information is provided about the progress of each iteration. With IPR = 1 (the default value), one line of output is provided for each one dimensional search and for each degenerate pivot. This output, for the problem described in section 6, is shown in Figure 6.6. Most of the headings are self explanatory. The Hessian condition refers to the condition number of the approximate Hessian matrix used in the BFGS quasi-Newton method. For unconstrained problems this matrix would generally be updated after each one dimensional search. For quadratic problems, it converges to the true Hessian. The condition number of this matrix is a measure of the behavior of the function being minimized and, if this number is too large, minimization will probably not proceed well. The Hessian update column shows whether or not this matrix was updated during the last iteration. The column headed "Degenerate Step" contains a blank if the iteration was not degenerate (i.e., the values of the variables were changed) and "T" if the iteration was degenerate (all variable values were unchanged, but there was a basis change).

For IPR = 2, the output is shown in Figure 6.7. Here, the progress of each one dimensional search is detailed. For each step in this search process, the step size, objective function value and number of Newton iterations required are printed. At the conclusion of each search a message is printed specifying how the search terminated. Figure 6.8 shows a portion of the output for our sample problem when IPR = 3. At each iteration, in addition to the output information provided when IPR = 2, the function and variable values are printed, as are the index sets for nonbinding constraints, nonbasic variables, and basic variables. The printing of the index set of nonbasic variables (INBV) is followed by the printing of a status array, IUB, which consists of zeros and plus and minus ones. Each entry in IUB refers to the corresponding nonbasic variable in INBV. A zero indicates that the variable is not at a bound (i.e., is a superbasic variable and will appear at the head of the INBV list) and a plus (minus) one indicates that the corresponding variable is at its upper (lower) bound. Note that associated with constraint j is a slack variable xn+j. The status of such a slack variable in the INBV set will be the same as the status of its associated constraint. The output for higher levels of IPR (4,5,6) provides successively more and more detailed output about the progress of each iteration. This output requires a more detailed understanding of the GRG algorithm and is not described here. For further information, see the list of references at the end of this document.
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

0 -3.037395E+04 0 5 0 3.329E+0 1.000E+00 F 0.000E+00 1 -3.049616E+04 1 4 0 7.101E+01 1.000E+00 F 1.027E-03 2 -3.062160E+04 2 3 0 6.482E+01 1.000E+00 F 1.430E-02 3 -3.062573E+04 2 2 0 6.463E+01 1.000E+00 F 5.123E-04 4 -3.064209E+04 2 1 0 6.382E+01 1.000E+00 F 3.124E-03 5 -3.066553E+04 2 1 0 6.192E+01 1.000E+00 T 0.000E+00 T TERMINATION CRITERION MET. KUHN-TUCKER CONDITIONS SATISFIED TO WITHIN 1.00000E-04 AT CURRENT POINT 5 -3.066553E+04 2 0 0 0.000E+00 1.000E+00 T 0.000E+00 T

Figure 6.6: IPR = 1

ITN NO.

OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO

UP DATE

STEP SIZE

DEGEN STEP

0 -3.037395E+04 0 5 0 3.329E+02 1.000E+00 F 0.000E+00 STEP = 4.666044E-03 OBJ = -3.091907E+04 NEWTON ITERS = 0 CONSTRAINT # 3 VIOLATED BOUND STEP = 1.026962E-03 OBJ = -3.049616E+04 NEWTON ITERS = 1 CONSTRAINT # 3 NOW AT BOUND
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

1 -3.049616E+04 1 4 0 7.101E+01 1.000E+00 F 1.027E-03 STEP = 4.666044E-03 OBJ = -3.091907E+04 NEWTON ITERS = 0 STEP = 1.478559E-02 OBJ = -3.062570E+04 NEWTON ITERS = 1 CONSTRAINT # 1 VIOLATED BOUND STEP = 1.429786E-02 OBJ = -3.062160E+04 NEWTON ITERS = 1 CONSTRAINT # 1 NOW AT BOUND
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

2 -3.062160E+04 2 3 0 6.482E+01 1.000E+00 F 1.430E-02 STEP = 5.122785E-04 OBJ = -3.062573E+04 NEWTON ITERS = 0 SUPERBASIC VARIABLE # 4 HIT BOUND
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

3 -3.062573E+04 2 2 0 6.463E+01 1.000E+00 F 5.123E-04 STEP = 3.124015E-03 OBJ = -3.064209E+04 NEWTON ITERS = 1 SUPERBASIC VARIABLE # 1 HIT BOUND
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

4 -3.064209E+04 2 0 6.382E+01 1000E+00 F 3.124E-03 STEP = 2.852119E-02 OBJ = -3.075003E+04 NEWTON ITERS = 2 BASIC VARIABLE # 2 VIOLATED BOUND STEP = 5.845227E-03 OBJ = -3.066553E+04 NEWTON ITERS = 1 BASIC VARIABLE # 2 HIT BOUND
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

5 -3.066553E+04 2 1 0 6.192E+01 1.000E+00 T 0.000E+00 T TERMINATION CRITERION MET. KUHN-TUCKER CONDITIONS SATISFIED TO WITHIN 1.00000E-04 AT CURRENT

POINT
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

5 -3.066553E+04 0.000E+00 T

0.000E+00 1.000E+00

Figure 6.7: IPR = 2

NONBINDING CONSTRAINTS ARE NUMBER OF SUPERBASICS = 5 INBV IS 1 2 3 4 5 IUB IS 0 0 0 0 0


ITN NO.

1 2 3

OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO

UP DATE

STEP SIZE

DEGEN STEP

0 -3.037395E+04 0 5 0 3.329E+02 1.000E+00 0.000E+00 G IS 1 9.1792729E+01 2 9.8892932E+01 3 2.0131578E+01 3.0373948E+04 X IS 1 7.8620000E+01 2 3.3440000E+01 3 3.1070000E+01 4.4180000E+01 5 3.5220000E+01 STEP = 4.666044E-03 OBJ = -3.091907E+04 NEWTON ITERS = 0 CONSTRAINT # 3 VIOLATED BOUND STEP = 1.026962E-03 OBJ = -3.049616E+04 NEWTON ITERS = 1 CONSTRAINT # 3 NOW AT BOUND BINDING CONSTRAINTS ARE 3 NONBINDING CONSTRAINTS ARE 1 2 NUMBER OF SUPERBASICS = 4 INBV IS 1 2 4 5 8 IUB IS 0 0 0 0 -1 IBV IS 3
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE

1 -3.049616E+04 1 4 0 7.101E+01 1.000E+00 1.027E-03 G IS 1 9.1809134E+01 2 9.8823887E+01 3 1.9999999E+01 -3.0496159E+04 X IS 1 7.8551475E+01 2 3.3440000E+01 3 3.0728086E+01 4.4180000E+01 5 3.5152527E+01 STEP = 1.478559E-02 OBJ = -3.062570E+04 NEWTON ITERS = 1 CONSTRAINT # 1 VIOLATED BOUND STEP = 1.429786E-02 OBJ = -3.062160E+04 NEWTON ITERS = 1 CONSTRAINT # 1 NOW AT BOUND

DEGEN STEP

BINDING CONSTRAINTS ARE 1 3 NONBINDING CONSTRAINTS ARE 2 NUMBER OF SUPERBASICS = 3 INBV IS 1 4 5 8 6 IUB IS 0 0 0 -1 1 IBV IS 2 3
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE DEGEN STEP

2 -3.062160E+04 2 3 0 6.482E+01 1.000E+00 1.430E-02 G IS 1 9.2000001E+01 2 9.8956417E+01 3 1.9999998E+01 3.0621602E+04 X IS 1 7.8119546E+01 2 3.3440000E+01 3 3.0229230E+01 4.4972951E+01 5 3.6167803E+01 STEP = 5.122785E-04 OBJ = -3.062573E+04 NEWTON ITERS = 0 SUPERBASIC VARIABLE # 4 HIT BOUND BINDING CONSTRAINTS ARE 1 3 NONBINDING CONSTRAINTS ARE 2 NUMBER OF SUPERBASICS = 2 NBV IS 1 5 4 8 6 IUB IS 0 0 1 -1 1 IBV IS 2 3
ITN NO. OBJECTIVE BINDING SUPER INFEAS NORM RED HESSIAN FUNCTION CONSTR BASIC CONSTR GRADIENT COND NO UP DATE STEP SIZE

DEGEN STEP

-3.062573E+04 5.123E-04 G IS 1 9.1999996E+01 2 3.0625733E+04 X IS 1 7.8102741E+01 2 4.5000000E+01 5

6.463E+01 1.000E+00 F

9.8945661E+01 3 1.9999995E+01

3.3409745E+01 3 3.0213284E+01 3.6201010E+01

STEP = 3.124015E-03 OBJ = -3.064209E+04 NEWTON ITERS = 1 SUPERBASIC VARIABLE # 1 HIT BOUND

BINDING CONSTRAINTS ARE 1 3 NONBINDING CONSTRAINTS ARE 2 NUMBER OF SUPERBASICS = 1 INBV IS 5 4 1 8 6 IUB IS 0 1 -1 -1 1 IBV IS 2 3 Figure 6.8: IPR = 3

7.

GRG2 Termination Messages Just prior to printing the final solution, GRG2 will print a message explaining why it stopped. The messages are 1. Termination Criterion Met. Kuhn-Tucker Conditions Satisfied To Within [EPTOP] At Current Point. 2. Fractional Change In Objective Less than [EPTOP] for [NSTOP] Consecutive Iterations. 3. All Remedies Have Failed to Find a Better Point. Program Terminated. 4. Number of Completed One-Dimensional Searches = Limser = [SEARCH]. Optimization Terminated. 5. Solution Unbounded. Function Improving After Doubling Step 30 times. 6. Feasible Point Not Found. Value of True Objective at Termination = [Objective Value]. In the above, the quantities in brackets (e.g., [EPTOP]) will be printed as numerical values. The parameters EPTOP, NSTOP, SEARCH have default values, but may be modified by the user (see sections 5.3 and 10). Messages 1-3 are by far the most common. Message 1 implies the highest level of confidence that at least a local optimum has been found, message 2 less confidence, message 3 even less. In message 1, the Kuhn-Tucker conditions are first-order necessary conditions that hold if the current point is at least a local optimum and all functions have continuous first partial derivatives. For further explanation, see references 1, 2, and 7. In message 3, the following sequence of events has occurred: (1) No improved point was located along the last search direction (2) a change of basis was attempted (if one had not already been done) (3) if the search direction was not the negative reduced gradient, this direction is tried (4) if any variables with values at a bound have reduced gradient components indicating that releasing them from that bound could improve the objective, one such variable is allowed to leave its bound. In other words, GRG2 tried everything we could think of and nothing worked, so it gave up. Regardless of which of termination messages 1-3 is printed, the current point may be (nearly) optimal. Message 1 may fail to appear because the variables or constraints of the problem are poorly scaled (see section 9.4). Message 6 is printed when phase I (see section 1 for explanation) terminates and the final point is not feasible. In this case, there may be no point satisfying all problem constraints. For things to try if you are unsatisfied with the solution found by GRG2, see section 9. 8. GRG2 Options and Tolerances

8.1 Tolerances All GRG2 tolerances have default values, and need not be set by the user. However, manipulation of these tolerances can sometimes improve GRG2 performance. Section 5.3.3.c describes these tolerances. The most critical tolerance is EPNEWT. Increasing it can sometimes speed convergence (by requiring fewer Netwon iterations) while decreasing it occasionally yields a more accurate solution, or gets the iterations moving if the algorithm gets "stuck." Values larger than 1.0D-2 should be treated cautiously, as should values smaller than 1.0D-6. Choosing a value for EPINIT different from EPNEWT has helped solve a few problems that were not solved otherwise. We have used EPINIT = 1.0D-4, EPNEWT = 1.0D-6. Choosing a smaller value for EPTOP (or a larger value for NSTOP, see section 5.3.3.b) usually improves the accuracy of the final solution. If the problem is degenerate and this is slowing computations, choosing a larger value for EPPIV may help by allowing pivots on elements which were previously rejected. If convergence of the Newton iterations is a problem, reducing EPPIV and/or increasing EPNEWT may help. A nonzero value of PH1EP will cause phase I to consider the true objective along with the sum of infeasibilities and may yield a better point at the end of phase I. 8.2 Algorithmic Options Options within the GRG2 algorithm are chosen in the METHODS section of the data file, and are defined in section 5.3.3.d. Here we briefly describe the effects of different choices. The FDC option (central differences) is more accurate than FDF (forward differences). FDC is exact for quadratic functions, while FDF is exact only for linear functions. However, FDC requires two function evaluations per derivative, while FDF requires only one. For further discussion, see section 9.3. The QUAD option can often speed computations by providing better initial values for the Newton iterations. It should not be used if all constraints are linear. The CG option is useful in problems with many variables, or if computer memory is limited. Using CG reduces storage requirements by about MAXR(MAXR + 1)/2, (see section 3 for definition of MAXR). However, it generally requires more iterations and more computer time than the default DFP option. We recommend options CG2 or CG5, although the performance of the CG options is strongly problem-dependent. 8.3 Revise Option

The REVISE option, described in section 5.4, permits rapid solution of a sequence of similar problems when using the file interface. Solution of the next problem starts from the optimal solution of the previous one. This option is useful in doing case studies in which one or more parameters of a problems are varied. This is also easily done using the subroutine interface (see section 10).

9.

Things to Try If GRG2 Isn't Working It is possible for GRG2 to terminate at a point which is not optimal. If x is the x-vector when GRG2 terminates, then one of the following conditions must hold: 1. x closely approximates a global optimum 2. x closely approximates a local optimum, but not a global optimum 3. x does not closely approximate even a local optimum. These statements apply in both phases I and II (see section 1 for explanation). This section deals with how to tell which of the above conditions holds, and what to do if x is not a global optimum. 9.1 Errors in the Input Data or in GCOMP To aid in spotting errors in the input data, all data values are written to the output file at the start of a run. If a problem is being solved for the first time, it may be useful to make a run which outputs the input data and then stops. To do this, set SEARCH to zero in the data file (see section 5.3.3.b) or set LLMSER to zero in the GRGSUB argument list. To see if the functions in GCOMP are coded correctly, or if any data to be read in GCOMP has been read correctly, set IPR (see section 5.3.3.a) to three or larger and search to zero. This will cause GCOMP to be called once, the G values computed by it will be output, and the program will stop. Data read in GCOMP can be printed by inserting appropriate write statements in GCOMP. 9.2 Incorrect User-Supplied Derivatives If derivatives are computed by user-supplied subroutine PARSH (see section 5.2) it may be that PARSH contains errors. If PN4 (see section 5.3.3.a) is set to a negative integer in the data file, the GRAD array computed by PARSH, evaluated at the initial point, will be printed. Optimization will then commence, unless SEARCH is set to zero. This facility can be used to check PARSH by running twice--once with no PARSH (hence using finite difference approximations to derivatives) and second with PARSH. The two GRAD arrays should agree to at least 4 or 5 digits--large differences in corresponding GRAD elements indicate errors in PARSH. 9.3 Inaccurate Numerical Derivatives Many GRG2 users use finite difference approximations to derivatives of the problem functions gi (x). These are computed by GRG2 routines PARSHF (Forward differencing) or PARSHC (Central differencing). Use of PARSHF is the default option, while PARSHC is invoked by an entry in the methods section of the GRG2 data file--see section 5.3.3.d.

Finite difference derivatives have roughly half the precision of the functions G(I) computed in GCOMP. Hence, if each G(I) has accuracy of from 13 to 16 significant digits, then the derivatives have about 7 or 8 significant digits, which is adequate in most instances. However, if each G(I) has 8 or fewer significant digits, then the derivatives have 4 or less, which may seriously hinder the optimizer. Low precision in GCOMP often occurs when GCOMP uses numerical routines to evaluate one or more of the functions G(I). this can occur (a) in chemical process models, where recycle loops require iterative solution of a system of implicit nonlinear equations, or (b) when differential equations are solved numerically within GCOMP. Then, the accuracy of these numerical calculations determines the accuracy of the functions G(I). Inaccurate derivatives can cause GRG2 to terminate at a nonoptimal point, often with the message "All Remedies Have Failed to Find a Better Point--Optimization Terminated" (see section 7 for an explanation). Possible remedies include (a) increasing the accuracy of the functions computed in GCOMP (b) using analytic derivatives computed in PARSH (c) trying central differencing or (d) trying different perturbation sizes in PARSHF or PARSHC. Any of these options should be tested first by printing out the derivatives of all problem functions evaluated at the initial point (see section 9.2 for how to do this), and observing if they change significantly under the option. Changes in the first 3 or 4 digits indicate significant inaccuracies. 9.4 Scaling Proper scaling of both variables and problem functions is very important for successful operation of GRG2. It is recommended that all problem functions be scaled to have absolute values less than 100. In addition, their values should be large enough so that a 10-4 error in computing them is not significant (10-4 is the default value of EPNEWT--see section 5.3.3.c). Variables should be scaled so that a unit change represents a small but significant change in that variable. In addition, it is advisable to avoid having the constraint or objective functions much more sensitive to some variables than others. A symptom of bad scaling is the presence of very large derivative values in the GRAD array. The easiest way to scale most problems is to write GCOMP first as though there were no scaling. Then at the end, set each G to itself times whatever power of 10 will bring it into the desired range. At the beginning, change the arguments from SUBROUTINE GCOMP (G,X) to GCOMP (G,XX) and multiply each XX by the amount necessary to "unscale" the variable from the adjusted range used throughout the rest of the program, to get X. Adjusted values need to be used for the INITIAL and BOUNDS section of the data.

9.5 Bounds Which Must Not be Violated It is possible for GCOMP to be called with the X's outside of their bounds. If this is likely to cause underflow or overflow or an error termination (such as attempting to take the square root or log of a negative number), preventive action can be taken in GCOMP. If, for example, the X's all have positive lower bounds and there is a division by some of the X's, a loop should be set up at the start of GCOMP comparing the X's with a small positive number less than the lower bounds. If any X is less than this value, set all the G's to an arbitrarily large number such as 10**30 and return. This will cause GRG2s Newtons method iterations to terminate and the stepsize will be cut back. (The check on bounds is not made in the Newton subroutine because it usually does not hurt to call GCOMP with X's beyond them and it gives information that speeds final convergence). An alternative procedure when some X variable violates a "forbidden" bound is to reset it to that bound within GCOMP. Although GCOMP is normally not supposed to change the X vector, this has sometimes worked in practice. 9.6 Local and Global Optima Neither GRG2 nor any other nonlinear optimization code can guarantee finding a global optimum in cases where there are distinct local optima. If you know that your problem is convex (minimizing a convex objective over a convex feasible region), then any local optimum is global, so this problem cannot occur. Otherwise, one must use a combination of (a) knowledge about the problem and (b) a variety of starting points to help decide the localglobal issue. If all starting points yield approximately the same final point, and that point is satisfactory to persons knowledgable about the problem, one has a high level of confidence that the point found is (globally) optimal. 9.7 Solution Not Accurate Enough

There are several ways to assess the accuracy of a solution. 1. 2. 3. 4. Use knowledge of the problem. Vary one or more variables and observe the behavior of the objective and constraint functions. Try different starting points. Observe initial and final magnitudes of the reduced gradients of the superbasic and nonbasic variables.

In (2) above, the user can fix some of the nonbasic variables at their current values (see

section 5.3.1.a for how to do this) and use GRG2 to vary the others, or he can perform the variations himself outside of GRG2. If no variation produces a significantly improved feasible point, confidence in the current solution is increased. Confidence is also increased if different starting points lead to nearly the same final point. In (4), the best indication of accuracy occurs if the Kuhn Tucker conditions are satisfied. However, even if they are not, but the reduced gradient components of superbasic variables have been reduced from their initial values by, say, 3 orders of magnitude or more, while reduced gradients of nonbasic variables at bound have the correct sign, this is symptomatic of reasonably high accuracy. If perceived accuracy is not sufficient, reducing EPTOP and/or increasing NSTOP (see section 5.3.3.c) often helps. It is often helpful to reduce EPNEWT if EPTOP is reduced, since this increases the accuracy of the reduced gradient computation. Other parameter changes and/or option choices may also be helpful--see section 8. 9.8 Changing GRG2 Tolerances or Options GRG2 contains several parameters and options which can affect its performance. All of these are set at default values, but can be changed by the user. Sometimes a proper choice can cause GRG2 to solve a problem that it could not solve previously, or can speed up a successful run. For a discussion of these issues, see sections 8 and 5.3.3.

10.

Using GRG2 as Part of a Larger System This section describes how to use the GRG2 FORTRAN subroutine interface using subroutine GRGSUB. GRGSUB is a complete interface to all features of GRG2. The user must provide subroutine GCOMP for evaluating the problem functions and subroutines PARSH and REPORT are optional. See section 1. Introduction. 10.1 GRG2 Subroutine Interface, GRGSUB This section provides a list of GRGSUB arguments along with their data types for the double precision version of GRG2. This information is needed when declaring each argument's type in the program that calls GRGSUB. Any quantity not explicitly listed as an array is a scalar. Argument names and data types follow the Fortran default convention; a variable whose name begins with one of the letters I through N is of type INTEGER. Variable names that begin with other letters are type DOUBLE PRECISION. Call GRGSUB (INPRNT, OTPRNT, NCORE,NCCORE, NNVARS, NFUN, MAXBAS,
1 2 3 4 5 MAXHES, NNOBJ, TTITLE, BLVAR, BUVAR, BLCON, BUCON, DEFAUL, FPNEWT, FPINIT, FPSTOP, FPSPIV, PPH1EP, NNSTOP, IITLIM, LLMSER, IIPR, IIPN4, IIPN5, IIPN6, IIPER, PPSTEP, IIQUAD, LDERIV, MMODCG, RAMCON, RAMVAR, XX, FCNS, INBIND, RMULTS, NONBAS, REDGR, NBIND, NNONB, INFORM, Z, CZ, IZ)

THIS IS THE SUBROUTINE INTERFACE FOR GRG2. DESPITE THE LONG ARGUMENT LIST, IT IS ACTUALLY EASY TO USE. MANY OF THE INPUT ARGUMENTSHAVE DEFAULTS AND NEED NOT BE SPECIFIED. THE ARGUMENTS ARE DIVIDED INTO 6 SECTIONS: 1. 2. ARGUMENTS {INPRNT} THROUGH {DEFAUL} VALUES FOR THESE MUST BE PROVIDED. ARGUMENTS {FPNEWT} THROUGH {RAMVAR} THESE ARE ALSO INPUT ARGUMENTS. VALUES FOR THESE ARE OPTIONAL. THE ARRAY {DEFAUL} TELLS GRGSUB WHICH ONES YOU WANT TO USE THE GRG2 DEFAULT VALUES FOR, AS IS EXPLAINED BELOW. ARGUMENT XX THIS IS BOTH AN INPUT AND OUTPUT ARGUMENT. VALUES MUST BE PROVIDED PRIOR TO CALLING GRGSUB. ANY SUCH VALUES WHICH DO NOT SATISFY THE BOUNDS ON THE VARIABLE WILL BE CHANGED TO THE BOUND NEAREST THE VALUE. ON TERMINATION XX GIVES GRGSUB-S ESTIMATE OF THE OPTIMUM. ARGUMENTS {FCNS} THROUGH {INFORM} THESE ARE OUTPUT ARGUMENTS. SEE BELOW FOR DESCRIPTIONS. Z THIS IS AN INPUT ARGUMENT, THE WORK ARRAY USED BY GRG2. IT MUST BE DIMENSIONED IN USER'S CALLING PROGRAM, AND {NCORE} MUST BE SET TO ITS DIMENSION THERE. IF THE DIMENSION IS NOT LARGE ENOUGH, AN ERROR MESSAGE WILL BE PRINTED, TELLING YOU HOW MUCH CORE IS NEEDED. CZ AND IZ THESE ARE ARRAYS USED TO STORE CHARACTER AND INTEGER VARIABLES. CZ MUST BE DECLARED CHARACTER AND DIMENSIONED TO A SIZE OF 2*(NNVARS+NFUN) IN

3.

4.

5.

6.

THE USERS CALLING PROGRAM. IZ IS DECLARED INTEGER IN THE CALLING PROGRAM, DIMENSIONED TO A SIZE OF 2*NCORE, AND EQUIVALENCED TO Z. SEE THE SAMPLE CALLING PROGRAM FOR AN EXAMPLE. INPUT VARIABLES AND PARAMETERS: DEFAUL(1<=I<=19) NE. 1.0 - USE PARAMETER VALUES ASSIGNED BY USER EQ. 1.0 - USE DEFAULT PARAMETERS VALUES INPUT PROGRAM PARAMETERS TO BE PROVIDED IF DEFAUL(I) .NE. 1.0 (I)-(INPUT VARIABLE)-(INTERNAL GRG2 VARIABLE)--(DEFAULT VALUE)--(MEANING) 1 FPNEWT--EPNEWT---1.0E-04 A CONSTRAINT IS ASSUMED TO BE BINDING IF IT IS WITHIN THIS EPSILON OF ONE OF ITS BOUNDS. FPINIT--EPINIT---1.0E-04 IF IT IS DESIRED TO RUN THE PROBLEM WITH {EPNEWT} INITIALLY SET FAIRLY LARGE AND THEN TIGHTENED AT THE END OF THE OPTIMIZATION THEN THIS IS ACCOMPLISHED BY ASSIGNING {EPINIT} THE INITIAL TOLERANCE AND {EPNEWT} THE FINAL ONE. FPSTOP--EPSTOP---1.0E-04 IF THE FRACTIONAL CHANGE IN THE OBJECTIVE IS LESS THAN {EPSTOP} FOR {NSTOP} CONSECUTIVE ITERATIONS, THE PROGRAM WILL STOP. THE PROGRAM WILL ALSO STOP IF KUHNTUCKER OPTIMALITY CONDITIONS ARE SATISFIED TO WITHIN{EPSTOP}. FPSPIV--EPSPIV---10.0E-3 IF, IN CONSTRUCTING THE BASIS INVERSE, THE ABSOLUTE VALUE OF A PROSPECTIVE PIVOT ELEMENT IS LESS THAN {EPSPIV}, THE PIVOT WILL BE REJECTED AND ANOTHER PIVOT ELEMENT WILL BE SOUGHT. PPH1EP--PH1EPS--- 0.0 IF NONZERO, THE PHASE 1 OBJECTIVE IS AUGMENTED BY A MULTIPLE OF THE TRUE OBJECTIVE. THE MULTIPLE IS SELECTED SO THAT, AT THE INITIAL POINT, THE RATIO OF THE TRUE OBJECTIVE AND SUM OF THE INFEASIBILITIES IS{PH1EPS}. NNSTOP--NSTOP --- 3 IF THE FRACTIONAL CHANGE IN THE OBJECTIVE IS LESS THAN {EPSTOP} FOR {NSTOP} CONSECUTIVE ITERATIONS, THE PROGRAM WILL STOP. IITLIM- -ITLIM --- 10 IF SUBROUTINE NEWTON TAKES {ITLIM} ITERATIONS WITHOUT CONVERGING SATISFACTORILY, THE ITERATIONS ARE STOPPED AND CORRECTIVE ACTION IS TAKEN. LLMSER--LIMSER- --10,000 IF THE NUMBER OF COMPLETED ONE DIMENSIONAL SEARCHES EQUALS {LIMSER}, OPTIMIZATION WILL TERMINATE. IIPR --IPR 0 SUPPRESS ALL OUTPUT PRINTING EXCEPT INITIAL AND FINAL REPORTS. 1 PRINT ONE LINE OF OUTPUT FOR EACH ONE DIMENSIONAL SEARCH. 2 PROVIDE MORE DETAILED INFORMATION ON THE PROGRESS OF EACH ONE DIMENSIONAL SEARCH. 3 EXPAND THE OUTPUT TO INCLUDE THE PROBLEM FUNCTION VALUES AND VARIABLE VALUES AT EACH ITERATION AS WELL AS THE SEPARATION OF CONSTRAINTS INTO NONBINDING AND BINDING AND VARIABLES INTO BASIC, SUPERBASIC AND NONBASIC. 4 AT EACH ITERATION THE REDUCED GRADIENT, THE SEARCH DIRECTION AND THE TANGENT VECTOR ARE PRINTED. 5 PROVIDES DETAILS OF THE BASIS INVERSION PROCESS INCLUDING THE INITIAL BASIS AND ITS INVERSE. ALSO DISPLAYS THE VARIABLE ALUES AND CONSTRAINT ERRORS FOR EACH NEWTON ITERATION.

THIS IS THE MAXIMUM LEVEL OF PRINT AVAILABLE AND INCLUDES ALL OF THE ABOVE ALONG WITH DETAILED PROGRESS OF THE BASIS CONSTRUCTION PHASE, INCLUDING THE BASIS INVERSE AT EACH PIVOT.

10-12 IIPN# --IPN# --- 0 (# = 4, 5, 6) IF IIPN# IS GREATER THAN ZERO THEN IPR WILL BE SET TO # AFTER IIPN# ITERATIONS. 13 IIPER --IPER --- 0 IF IIPER IS GREATER THAN ZERO THEN FOR EVERY IIPER-TH ITERATION, PRINT USING THE CURRENT VALUE OF {IPR} OTHERWISE USE IPR=1 . PPSTEP--PSTEP --- 1.0E-8 THIS IS THE STEP SIZE USED IN PARSH AND PARSHC FOR ESTIMATING PARTIAL DERIVATIVES OF THE FUNCTIONS WITH RESPECT TO THE VARIABLES. IIQUAD--IQUAD 0 METHOD FOR INITIAL ESTIMATES OF BASIC VARIABLES FOR EACH ONE DIMENSIONAL SEARCH 0 TANGENT VECTOR AND LINEAR EXTRAPOLATION WILL BE USED. 1 QUADRATIC EXTRAPOLATION WILL BE USED. LDERIV--KDERIV 0 METHOD FOR OBTAINING PARTIAL DERIVATIVE 0 1 2 17 FORWARD DIFFERENCE APPROXIMATION CENTRAL DIFFERENCE APPROXIMATION USER SUPPLIED SUBROUTINE {PARSH} IS USED

14

15

16

MMODCG- -MODCG 0 {MODCG} AND {MAXHES} (SEE BELOW) CONTROL USE OF A CONJUGATE GRADIENT ( CG ) METHOD. IF THE NUMBER OF SUPERBASICVARIABLES EXCEEDS {MAXHES}, THE CGMETHOD INDICATED BY {MODCG} IS USED. DEFAULT VALUE OF MODCG=1 . TO USE A CG METHOD AT EACH ITERATION, SET MAXHES=0 . 1 USES FLETCHER- REEVES FORMULA. 2 USES POLAK-RIBIERE FORMULA. 3 USES PERRY'S FORMULA. 4 USES 1 STEP VERSION OF DFP. 5 USES 1 STEP VERSION OF BFS. RAMCON AND RAMVAR--NAMCON AND NAMVAR--BLANKS. CHARACTER ARRAYS OF DIMENSION NFUN AND NNVARS RESPECTIVELY FOR ENTERING NAMES OF FUNCTIONS AND VARIABLES. OBJECTIVE AND CONSTRAINT FUNCTION NAMES GO IN {RAMCON}, VARIABLE NAMES GO IN {RAMVAR}. {NO GRGSUB VARIABLE}--MAXIM- -FALSE. IF DEFAUL(19)=1.0, OBJECTIVE WILL BE MINIMIZE. IF NOT EQUAL 1.0, OBJECTIVE WILL BE MAXIMIZED

18

19

OTHER INPUT VARIABLES: THESE HAVE NO DEFAULT VALUES, SO VALUES MUST BE PROVIDED BY THE USER

LOGICALS INPRNT: FALSE: DO NOT PRINT ANY ECHO BACK OF INPUT DATA TRUE: PRINT INPUT DATA

OTPRNT: FALSE: DO NOT PRINT ANY FINAL RESULTS TRUE: PRINT FINAL RESULTS SCALARS (INPUT VARIABLE)--(GRG2 INTERNAL VARIABLE)--(MEANING) NCORE --NCORE -- DIMENSION OF THE {Z} ARRAY NCCORE -NCCORE - DIMENSION OF THE {CZ} ARRAY NNVARS--NVARS -- NUMBER OF VARIABLES NFUN --NROWS -- NUMBER OF FUNCTIONS INCLUDING OBJECTIVE MAXBAS--MAXB -- UPPER LIMIT ON NUMBER OF BINDING CONSTRAINTS - USE {NFUN} IF UNSURE OF SMALLER LIMIT MAXHES--MAXR -- MAXIMUM ALLOWABLE SIZE OF APPROXIMATE HESSIAN - USE {NVARS} IF YOU WANT A QUASI-NEWTON METHOD TO BE USED AT EVERY ITERATION (FASTEST METHOD IF NOT TOO MANY VARIABLES) NNOBJ --NOBJ -- INDEX OF COMPONENT OF VECTOR {G} IN SUBROUTINE GCOMP CORRESPONDING TO OBJECTIVE FUNCTION ARRAYS BLVAR --ALB -- REAL ARRAY CONTAINING LOWER BOUNDS OF VARIABLES. MUST HAVE DIMENSION EQUAL TO {NNVARS}. IF A VARIABLE XX(I) HAS NO LOWER BOUND, SET BLVAR(I) TO -1.0D30 BUVAR --UB -- REAL ARRAY CONTAINING UPPER BOUNDS OF VARIABLES. MUST HAVE DIMENSION EQUAL TO VALUE OF {NNVARS}. IF XX(I) HAS NO UPPER BOUND, SET BUVAR(I) TO 1.0D30 BLCON --ALB -- REAL ARRAY CONTAINING LOWER BOUNDS OF ALL FUNCTIONS DEFINED IN {GCOMP}. MUST HAVE DIMENSION EQUAL TO VALUE OF {NFUN}. IF A FUNCTION G(I) HAS NO LOWER BOUND, SET BLCON(I) TO -1.0D30 BUCON --UB -- REAL ARRAY CONTAINING UPPER BOUNDS OF ALL FUNCTIONS DEFINED IN {GCOMP}. MUST HAVE DIMENSION EQUAL TO VALUE OF {NFUN}. IF A FUNCTION G(I) HAS NO UPPER BOUND, SET BUCON(I) TO 1.0D30 NOTE 1: IT DOES NOT MATTER WHAT YOU USE FOR THE BOUNDS OF THE OBJECTIVE FUNCTION IN {BUCON} AND {BLCON}, BUT SOMETHING MUST BE THERE NOTE 2: IF YOU WISH TO FIX A VARIABLE AT A CERTAIN VALUE AND HAVE GRGSUB LEAVE IT UNCHANGED, SET ITS ENTRIES IN BLVAR AND BUVAR TO THAT VALUE NOTE 3: IF G(I) IS AN EQUALITY CONSTRAINT, EQUAL TO, SAY, B, SET BLCON(I)=BUCON(I)=B NOTE 4: IF A CONSTRAINT G(I) IS TO BE IGNORED IN THE CURRENT CALL TO GRGSUB, SET BLCON(I) TO -1.0D30 AND BUCON(I) TO 1.0D30 XX --X -- ARRAY CONTAINING INITIAL VALUES OF VARIABLES. MUST HAVE DIMENSION EQUAL TO VALUE OF {NNVARS}.

OUTPUT VARIABLES AND PARAMETERS: XX -- REAL ARRAY OF DIMENSION EQUAL TO VALUE OF {NNVARS}. XX(I) CONTAINS FINAL VALUE OF X(I), WHERE X IS ARRAY OF VARIABLES IN GCOMP.

FCNS -- REAL ARRAY OF DIMENSION EQUAL TO VALUE OF {NFUN}. FCNS(I) CONTAINS FINAL VALUE OF G(I) WHERE G IS ARRAY OF FUNCTIONS IN GCOMP. INBIND -- INTEGER ARRAY OF DIMENSION EQUAL TO VALUE OF NFUN. THE FIRST NBIND POSITIONS OF INBIND CONTAIN THE INDICES OF THOSE CONSTRAINTS (COMPONENTS OF THE G VECTOR) WHICH EQUAL EITHER THEIR LOWER OR UPPER BOUNDS AT TERMINATION. RMULTS -- REAL ARRAY OF DIMENSION NFUN. THE FIRST NBIND POSITIONS OF RMULTS CONTAIN THE LAGRANGE MULTIPLIERS OF THE BINDING CONSTRAINTS, IN THE SAME ORDER AS THE INDICES IN INBIND. NONBAS -- INTEGER ARRAY OF DIMENSION EQUAL TO VALUE OF {NNVARS}. ITS FIRST {NNONB} POSITIONS CONTAIN THE INDICES OF THOSE COMPONENTS OF XX WHICH ARE NOT BASIC (I.E. EITHER SUPERBASIC OR NONBASIC) AT TERMINATION. THE REMAINING POSITIONS CONTAIN NO USEFUL INFORMATION. REDGR -- REAL ARRAY OF SAME DIMENSION AS NONBAS. ITS FIRST {NNONB} POSITIONS CONTAIN REDUCED GRADIENTS OF THE VARIABLES WHOSE INDICES ARE IN NONBAS, ORDERED IN THE SAME WAY AS NONBAS. NBIND -- INTEGER SCALAR. NUMBER OF BINDING CONSTRAINTS. SEE DESCRIPTION OF INBIND AND RMULTS ABOVE. NNONB -- INTEGER SCALAR. SEE NONBAS AND REDGR EXPLNANATION ABOVE TERMINATION MESSAGES INFORM 0 1 2 3 4 5 KUHN- TUCKER CONDITIONS SATISFIED FRACTIONAL CHANGE IN OBJECTIVE LESS THAN {EPSTOP} FOR {NSTOP} CONSECUTIVE ITERATION ALL REMEDIES HAVE FAILED TO FIND A BETTER POINT NUMBER OF COMPLETED ONE DIMENSIONAL SEARCHES EQUAL TO {LIMSER} SOLUTION UNBOUNDED FEASIBLE POINT NOT FOUND

10.2 Example Problem Using GRGSUB A typical nonlinear programming problem (number 3 in the Colville [6] study and number 11 in the Himmelblau text [7]) and its formulation for GRG2 are presented in detail in this section. 10.2.1 Problem Statement This problem has 5 variables, bounded above and below, a quadratic objective function, and three quadratic constraints with both upper an lower bounds. The functions and bounds are given below.
Minimize Subject to: 0 < 85.334407 + 0.0056858X2X5 + 0.0006262X1X4 - 0.0022053X3X5 90 < 80.51249 < 92 + 0.0071317X2X5 + 0.0029955X1X2 + 0.0021813X3**2 < 110 5.3578547X3**2 + 0.8356891X1X5 + 37.293239X1 - 40792.141

20 < 9.300961 and,

+ 0.0047026X3X5 + 0.0012547X1X3 + 0.0019085X3X4

< 25

78 < X1 < 102 33 < X2 < 45 27 < X3 < 45 27 < X4 < 45 27 < X5 < 45

This problem is to be solved starting from two different starting points, one of which is feasible and the other infeasible.
Feasible start point Infeasible start point X = (78.62,33.44,31.07,44.18,35.22) X = (78,33,27,27,27)

10.2.2 GCOMP for GRGSUB Example Problem The required FORTRAN subroutine GCOMP appears below.
SUBROUTINE GCOMP (G, X) C C C C DIMENSION G(4), X(5) C G(1) = 85.334407 + 0.0056858*X(2)*X(5) + 0.0006262*X(1)*X(4) -0.0022053*X(3)*X(5) G(2) = 80.51249 + 0.0071317*X(2)*X(5) + 0.0029955*X(1)*X(2) & + 0.0021813*X(3)**2 G(3) = 9.300961 + 0.0047026*X(3)*X(5) + 0.0012547*X(1)*X(3) & + 0.0019085*X(3)*X(4) G(4) = 5.3578547*X(3)**2 + 0.8356891*X(1)*X(5) + 37.293239*X(1) & - 40792.141 & C RETURN END HIMMELBLAU PROB 11, COLVILLE QUADRATIC IMPLICIT DOUBLE PRECISION (A-H,O-Z),INTEGER(I-N)

10.2.3 Program for GRGSUB Example Problem The program that calls GRG2 subroutine GRGSUB appears below.
PROGRAM GRG2CALL IMPLICIT NONE INTEGER NCORE,NCCORE,NNVARS,NFUN,MAXBAS,MAXHES C ******************************************************************* C * NNVARS -- NUMBER OF VARIABLES * PARAMETER (NNVARS = 5) C ******************************************************************* C * NFUN -- NUMBER OF FUNCTIONS INCLUDING THE OBJECTIVE * PARAMETER (NFUN = 4) C ******************************************************************* C * NCORE -- SIZE OF WORK ARRAY "Z(NCORE)" C * NCCORE - SIZE OF CHARACTER ARRAY "CZ(NCCORE)" * C NOTE - YOU MUST SET UP Z,CZ,IZ AS SHOWN. THE SPECIFIC VALUE C FOR NCORE MAY BE CHANGED BUT NCCORE SHOULD BE AS SHOWN PARAMETER (NCORE = 15000) PARAMETER (NCCORE = 2*(NNVARS + NFUN) ) DOUBLE PRECISION Z(NCORE) CHARACTER*8 CZ(NCORE) INTEGER IZ(2*NCORE) EQUIVALENCE (Z,IZ) C C ******************************************************************* C * MAXHES -- MAXIMUM ALLOWABLE SIZE OF APPROXIMATE * C* HESSIAN - USE "NNVARS" IF YOU WANT A QUASI-NEWTON * C* METHOD TO BE USED AT EVERY ITERATION (FASTEST * C* METHOD IF NOT TOO MANY VARIABLES) * PARAMETER (MAXHES = NNVARS) C******************************************************************** C * MAXBAS -- UPPER LIMIT ON NUMBER OF BINDING CONSTRAINTS. * C* USE "NFUN" IF UNSURE OF A SMALLER LIMIT * PARAMETER (MAXBAS = NFUN) C******************************************************************** CHARACTER*8 FUNCTION_NAMES(NFUN), VARIABLE_NAMES(NNVARS) LOGICAL INPRINT,OUTPRINT DOUBLE PRECISION BLVAR(NNVARS),BUVAR(NNVARS), & BLCON(NFUN),BUCON(NFUN) DOUBLE PRECISION XX(NNVARS),FCNS(NFUN),RMULTS(NFUN), & REDGR(NNVARS),DEFAUL(20) INTEGER NBIND,NNONB,NNOBJ INTEGER INBIND(NFUN) INTEGER NONBAS(NNVARS) CHARACTER*76 TITLE INTEGER NNSTOP,IITLIM,LLMSER,IIPR,IIPN4,IIPN5, & IIPN6,IIPER,IIQUAD,LDERIV,MMODCG, & IISCAL,INFORM INTEGER I C DOUBLE PRECISION FPNEWT,FPINIT,FPSTOP,FPSPIV,PPH1EP,PPSTEP C INTEGER IOIN,IOOUT,IODUMP,IOTERM COMMON /IOUNIT/ IOIN,IOOUT,IODUMP,IOTERM

C DATA FUNCTION_NAMES / NFUN * ' DATA VARIABLE_NAMES / NNVARS * ' C C C C C C C C C C * * * '/ '/

Prototype main program for GRG2 using subroutine interface. * Statements to calculate processor time for complete run * are present but commented out. You can modify these easily. * THE NEXT STATEMENTS ARE CONVENIENT FOR PC'S. YOU MAY WISH TO DELETE THEM FOR MAINFRAMES,AND LINK LOGICAL AND ACTUAL FILENAMES OUTSIDE THE GRG2 SYSTEM.

IOOUT = 6 OPEN(UNIT = IOOUT,FILE = 'GRG2.OUT') ioterm = 9 open(unit=ioterm,file='con:') C C C C C C C C C C C C C C C ******************************************************************* * NNOBJ -- INDEX OF THE OBJECTIVE FUNCTION IN THE "FCNS()" * * -- ARRAY HERE = THE "G()" ARRAY IN SUBROUTINE GCOMP. * * -- 1 <= NNOBJ <= NFUN * NNOBJ = 4 ******************************************************************* * TITLE -- CHARACTER STRING OF AT MOST 76 CHARACTERS USED TO * * IDENTIFY THE PROBLEM IN ANY PRINTED REPORTS. * TITLE = 'HIMMELBLAU #11 -- SUBROUTINE INTERFACE' ******************************************************************* * SET VARIABLE LOWER AND UPPER BOUNDS AND NAMES FOR VARIABLES * * BLVAR -- Bound Lower VARiables * * BUVAR -- Bound Upper VARiables * * VARIABLE_NAMES - UP TO EIGHT CHARACTERS * * BLVAR(1) = 78.0 BUVAR(1) = 102.0 VARIABLE_NAMES(1) = 'VAR 1 ' BLVAR(2) = 33.0 BUVAR(2) = 45.0 VARIABLE_NAMES(2) = 'VAR 2 ' C BLVAR(3) = 27.0 BUVAR(3) = 45.0 VARIABLE_NAMES(3) = 'VAR 3 ' C BLVAR(4) = 27.0 BUVAR(4) = 45.0 VARIABLE_NAMES(4) = 'VAR 4 ' C BLVAR(5) = 27.0 BUVAR(5) = 45.0 VARIABLE_NAMES(5) = 'VAR 5 ' C ******************************************************************* C * SET FUNCTION LOWER AND UPPER BOUNDS AND NAMES FOR FUNCTIONS *

C C C C

* BLCON -- Bound Lower CONstraints * BUCON -- Bound Upper CONstraints * FUNCTION_NAMES - UP TO EIGHT CHARACTERS * BLCON(1) = 0.0 BUCON(1) = 92.0 FUNCTION_NAMES(1) = 'CONST 1 ' BLCON(2) = 90.0 BUCON(2) = 110.0 FUNCTION_NAMES(2) = 'CONST 2 '

* * *

C BLCON(3) = 20.0 BUCON(3) = 25.0 FUNCTION_NAMES(3) = 'CONST 3 ' C FUNCTION_NAMES(4) = 'OBJECT ' C ******************************************************************* C * SET INITIAL VALUES FOR THE VARIABLES * C* XX(1) = 78.62 XX(2) = 33.44 XX(3) = 31.07 XX(4) = 44.18 XX(5) = 35.22 C* C ******************************************************************* * C * INPRINT -- CONTROL OF INPUT ECHO AND INITIAL VALUE TABLE PRINT * C * OUTPRINT -- CONTROL PRINTING OF FINAL VALUE TABLE AND STATISTICS * INPRINT = .TRUE. OUTPRINT = .TRUE. C ******************************************************************* * C * THE DEFAUL(20) ARRAY DETERMINES IF DEFAULT VALUES ARE TO BE * C * USED FOR SPECIFIC PARAMETERS OR IF USER SUPPLIED VALUES ARE * C * TO BE USED. IF DEFAUL(I) = 1.0 THEN THE DEFAULT FOR THE I'TH * C * PARAMETER IS USED. BEGIN BY INITIALIZING ALL VALUES TO 1.0 * DO 10 I=1,20 10 DEFAUL(I) = 1.0D0 DEFAUL(9) = 0.0D0 IIPR = 1 C * 18 {NO GRGSUB VARIABLE} C* IF DEFAUL(18) = 1.0 THEN BLANKS ARE USED FOR C* THE VARIABLE AND FUNCTION NAMES IN ARRAYS C* VARIABLE_NAMES AND FUNCTION_NAMES C* OTHERWISE THE USER PROVIDED NAMES ARE USED DEFAUL(18) = 0.0D0 C * 20 IISCAL - 0 - CONTROLS FUNCTION AND VARIABLE SCALING. C* DEFAULT IS NO SCALING C* - 1- SCALING IS USED DEFAUL(20) = 0.0D0 IISCAL = 0 WRITE(6,*) 'CALLING GRGSUB' CALL GRGSUB(INPRINT,OUTPRINT,NCORE,NCCORE,NNVARS,NFUN,MAXBAS, 1 MAXHES,NNOBJ,TITLE,BLVAR,BUVAR,BLCON,BUCON,DEFAUL,FPNEWT,FPINIT, 2 FPSTOP,FPSPIV,PPH1EP,NNSTOP,IITLIM,LLMSER,IIPR,IIPN4,IIPN5,

3 IIPN6,IIPER,PPSTEP,IIQUAD,LDERIV,MMODCG, 4 FUNCTION_NAMES,VARIABLE_NAMES,XX,FCNS,INBIND,RMULTS,NONBAS, 5 REDGR,NBIND,NNONB,INFORM,Z,CZ,IZ) WRITE(6,*) 'EXITING GRGSUB' STOP END SUBROUTINE GCOMP(G,X) C HIMMELBLAU PROB 11, COLVILLE QUADRATIC DOUBLE PRECISION G(4),X(5) G(1) = 85.334407 + 0.0056858*X(2)*X(5) + 0.0006262*X(1)*X(4) 1 -0.0022053*X(3)*X(5) G(2) = 80.51249 + 0.0071317*X(2)*X(5) + 0.0029955*X(1)*X(2) 1 + 0.0021813*X(3)**2 G(3) = 9.300961 + 0.0047026*X(3)*X(5) + 0.0012547*X(1)*X(3) 1 + 0.0019085*X(3)*X(4) G(4) = 5.3578547*X(3)**2 + 0.8356891*X(1)*X(5) + 37.293239*X(1) 1 - 40792.141 RETURN END

10.2.4 Output for GRGSUB Example Problem This section describes output produced by GRG2 through subroutine GRGSUB for the example problem. Only output for the run starting from the feasible starting point is shown.
NUMBER OF VARIABLES IS 5 NUMBER OF FUNCTIONS IS 4 SPACE RESERVED FOR HESSIAN HAS DIMENSION 5 LIMIT ON BINDING CONSTRAINTS IS 3 ACTUAL LENGTH OF Z ARRAY IS 204 FPNEWT = .1000E-03 FPINIT = .1000E-03 FPSTOP = .1000E-03 FPPIV = .1000E-02 PPH1EPS = .00000E+00 NNSTOP = 3 IITLIM = 10 LLMSER = 10000 IIPR = 0 IIPN4 = 0 IIPN5 = 0 IIPN6 = 0 IIPER = 0 IIDUMP = 0 TANGENT VECTORS WILL BE USED FOR INITIAL ESTIMATES OF BASIC VARIABLES THE FINITE DIFFERENCE PARSH USING FORWARD DIFFERENCES WILL BE USED OBJECTIVE FUNCTION WILL BE MINIMIZED. LIMIT ON HESSIAN IS 5 INITIAL VALUES GRG2 Example: Himmelblau Problem 11 INITIAL TYPE VALUE RNGE 9.1792729E+01 RNGE 9.8892932E+01 RNGE 2.0131578E+01 OBJ -3.0373948E+04 INITIAL VALUE LOWER LIMIT 0.0000000E+00 9.0000000E+01 2.0000000E+01 UPPER LIMIT 9.2000000E+01 1.1000000E+02 2.5000000E+01

SECTION 1 -- FUNCTIONS FUNCTION NO. NAME STATUS 1 G 2 G 3 G 4 G SECTION 2 -- VARIABLES VARIABLE NO. NAME STATUS

LOWER LIMIT

UPPER LIMIT

1 2 3 4 5

X X X X X

7.8620003E+01 3.3439999E+01 3.1070000E+01 4.4180000E+01 3.5220001E+01

7.8000000E+01 3.3000000E+01 2.7000000E+01 2.7000000E+01 2.7000000E+01

1.0200000E+02 4.5000000E+01 4.5000000E+01 4.5000000E+01 4.5000000E+01

TERMINATION CRITERION MET. KUHN-TUCKER CONDITIONS SATISFIED TO WITHIN 1.00000E-04 AT CURRENT POINT FINAL RESULTS GRG2 Example: Himmelblau Problem 11 SECTION 1 -- FUNCTIONS NO. 1 2 3 4 NAME G G G G INITIAL VALUE FINAL VALUE DISTANCE FROM LAGRANGE STATUS NEAREST MULTIPLIER BOUND UPPERBND 2.401E-05:U-4.03314E+02 FREE 8.840E+00:L LOWERBND-1.398E-05:L 8.09463E+02 OBJ

9.17927E+01 9.20000E+01 9.88929E+01 9.88405E+01 2.01316E+01 2.00000E+01 -3.03739E+04-3.06655E+04

SECTION 2 -- VARIABLES DISTANCE FROM REDUCED STATUS NEAREST GRADIENT BOUND 7.86200E+01 7.80000E+01 NONBASIC LOWERBND 4.89270E+01 3.34400E+01 3.30000E+01 NONBASIC LOWERBND 8.43325E+01 3.10700E+01 2.99953E+01 BASIC 2.995E+00:L 4.41800E+01 4.50000E+01 NONBASIC UPPERBND -2.66392E+01 3.52200E+01 3.67757E+01 BASIC 8.224E+00:U INITIAL VALUE FINAL VALUE

NO. 1 2 3 4 5

NAME X X X X X

RUN STATISTICS GRG2 Example: Himmelblau Problem 11 NUMBER OF ONE-DIMENSIONAL SEARCHES = 5 NEWTON CALLS = 6 NEWTON ITERATIONS = 6 AVERAGE = 1.00 FUNCTION CALLS = 14 GRADIENT CALLS = 6 ACTUAL FUNCTION CALLS (INC. FOR GRADIENT) = 44 NUMBER OF TIMES BASIC VARIABLE VIOLATED A BOUND = 2 NUMBER OF TIMES NEWTON FAILED TO CONVERGE = 0 TIMES STEPSIZE CUT BACK DUE TO NEWTON FAILURE = 0

11.

Unconstrained Minimization and Optimal Control GRG2 can be used to do unconstrained minimization, or minimization subject only to upper and lower bounds. Simply compute the objective function in GCOMP. The code will then minimize the objective using the Broyden-Fletcher-Goldfarb-Shanno (BFGS) variable metric method [8] modified to deal with upper and lower bounds on the variables, unless conjugate gradient method has been specified instead. GRG2 can also solve discrete-time optimal control problems. To do this, let n (see

section 5.1) be the total number of control variables (over all time periods) and let m be the total number of problem constraints other than bounds on the control, e.g., state variable inequality or terminal constraints. If there are none of these use m = 1. Subroutine GCOMP must be written so as to accept the control vector X, solve the system equations for the state variables, and evaluate the objective and constraint functions. If finite difference derivatives are to be used, the state variables need not appear anywhere except in GCOMP; GRG2 itself will be unaware that they exist. If analytic partial derivatives are used, then the state variables will be required by PARSH.

References 1. Lasdon, L.S., Waren, A.D., Jain, A., and Ratner, M., "Design and Testing of a Generalized Reduced Gradient Code for Nonlinear Programming," ACM Transactions on Mathematical Software, Vol. 4, No. 1, March 1978, pp. 34-50. Lasdon, L.S. and Waren, A.D., "Generalized Reduced Gradient Software for Linearly and Nonlinearly Constrained Problem," in Design and Implementation of Optimization Software, H. Greenberg, ed., Sijthoff and Noordhoff, pubs, 1979. Abadie, J. and Carpentier, J. "Generalization of the Wolfe Reduced Gradient Method to the Case of Nonlinear Constraints," in Optimization, R. Fletcher (ed.), Academic Press, London; 1969, pp. 37-47. Murtagh, B.A. and Saunders, M.A. "Large-scale Linearly Constrained Optimization," Mathematical Programming, Vol. 14, No. 1, January 1978, pp. 41-72. Powell, M.J.D., "Restart Procedures for the Conjugate Gradient Method," Mathematical Programming, Vol. 12, No. 2, April 1977, pp. 241-255. Colville, A.R., "A Comparative Study of Nonlinear Programming Codes," I.B.M. T.R. no. 320-2949 (1968). Himmelblau, D.M., Applied Nonlinear Programming, McGraw-Hill Book Co., New York, 1972. Fletcher, R., "A New Approach to Variable Metric Algorithms," Computer Journal, Vol. 13, 1970, pp. 317-322.

2.

3.

4. 5. 6. 7. 8.