- Generated by
1.13.2
|
CONOPT
|
General messaging callback and optional error reporting callback.
The Message and ErrMsg callback routines defined in this section must both be provided by the modeler. They use a vector of CHARACTER*132 variables (MSGV) or a CHARACTER*80 variable (MSG) as well as a message length information (LEN and MSGLEN) plus various control information.
If you implement your routines in another language than Fortran then you should be aware that there is no standard way of communicating character variables. Check your systems documentation, and make sure you re-check it if you move to another compiler or computer. We have included the C translation in the header file coiheader.h and in the following text.
USRMEM are defined by CONOPT and they must not be changed.The Progress and TriOrd callback routines described at the end of this section are both optional.
General messages can be information for the iteration log, error messages, termination messages, and other generally useful information. The messages can be more than one line long and each line can be up to 132 characters long. There may be blank lines identified by LLEN(I) = 1 and MSGV(I)(1:1) = " " used to space the messages nicely, and some of the lines may be indented with leading blanks.
Messages are sent to three simultaneous streams or files and parts of the messages can be intended for one or more streams. These streams/files are:
SMSG lines are intended for this file.NMSG lines are intended for this file.DMSG lines are intended for this file.The modeler may implement all three streams or a subset of them. Note that SMSG, NMSG, or DMSG can be zero indicating that there are only messages for a subset for the files. Also note that the status file always will be a subset of the documentation file, i.e. NMSG will be less than or equal to DMSG. All messages start with the first line in MSGV.
where:
SMSG: The number of lines in the message that should go to the Screen file. Between 0 and 30.NMSG: The number of lines in the message that should go to the Status file. Between 0 and 30.DMSG: The number of lines in the message that should go to the Documentation file. Between 0 and 30.LLEN: Vector with the length of the individual message lines. The lengths are all between 1 and 132.USRMEM: User memory as defined in coidef_usrmem() (Only for Fortran and C API).MSGV: Vector with the actual message lines. Only the first LLEN(i) characters should be used in line number i.
Messages about particular parts of a model are all one line long. The messages can be related to an error or it can be a general informative message related to a row or column or Jacobian element. The modeler is responsible for combining the row and column identification and the message text and for displaying the overall message.
ErrMsg are intended both for the Status file and the Documentation file.The Fortran definition of ErrMsg is:
where:
ROWNO: The number of a row in the matrix.COLNO: The number of a column in the matrix.POSNO: The number of a Jacobian element in the matrix.MSGLEN: The length of the message, between 1 and 80.MSG: The actual message. Only the first MSGLEN characters should be used.USRMEM: User memory as defined in coidef_usrmem() (Only for Fortran and C API).There are some special cases for the three first arguments and the message should be interpreted accordingly. The special values depend on the Base. For Base = 1, i.e. Fortran conventions, the special cases are:
ROWNO will be between 1 and NumCon.COLNO will be between 1 and NumVar.POSNO is nonzero and about a (row,column)-pair if POSNO is zero.For Base = 0, i.e. C conventions, the special cases are:
ROWNO will be between 0 and NumCon-1.COLNO will be between 0 and NumVar-1.POSNO is non-negative and about a (row,column)-pair if POSNO is -1.Examples of message texts are "Inconsistent lower and upper bounds." and "The variable has reached 'infinity.'" for a column, "The slack has reached 'infinity.'" for a row and "Initial Jacobian element was not defined." for a Jacobian element.
If the optional Progress routine has been registered, CONOPT will call it at the end of each iteration. The modeler may use the information in the arguments for displaying progress information or for monitoring individual variables.
The Fortran definition of Progress is:
where:
LEN_INT: Number of elements in the following vector INT. The current value is 5 but it may grow in later versions.INT: Vector with LEN_INT integers reporting on the algorithmic progress. The elements in INT are, shown in order from 1 to LEN_INT (Fortran) or 0 to LEN_INT-1 (C):ITER: Number of the iteration.PHASE: The phase of the optimization. This argument is defined as follows:NUMINF = INT(3) "difficult" constraints. NUMINF may grow during phase 0 as difficult constraints are identified and excluded from the Newton process, but SUMINF = RL(1) will always decrease monotonically. Once the "easy" constraints are satisfied CONOPT will switch to phase 1 if NUMINF is positive and to 3 if NUMINF is zero.NUMINF constraints that still are infeasible, and a standard GRG algorithm is applied to minimize the sum of these artificial variables. Except for cases with numerical problems where we may return to phase 0, NUMINF and SUMINF will decrease monotonically during phase 1 and 2. The model is approximated with a linear model during phase 1, and computed or approximated second order terms are included during phase 2.NUMINF = SUMINF = 0, and the standard GRG algorithm is used to optimize the true objective function. The value of the true objective function, OBJVAL = RL(2), will in general change monotonically. However, if it is necessary to decrease feasibility tolerances in cases with numerical problems, CONOPT may switch back to phase 0 or 1, and the objective may temporarily move in the wrong direction. The model is approximated with a linear model during phase 3, and computed or approximated second order terms are included during phase 4.ITER, that counts the number of optimization iterations, can be the same during several calls. The only purpose of the call is to allow the modeler to stop the optimization by returning a nonzero value.NUMINF: Number of infeasible constraints. In phase 0, this number will only count the number of "difficult" constraints.NUMNOP: Number of non-optimal variables. NUMNOP will be 0 meaning undefined during phase 0.NSUPER: Number of super-basic variables. NSUPER will be zero during phase 0 .LEN_RL: Number of elements in the following vector RL. The current value is 4 but it may grow in later versions.RL: Vector with LEN_RL elements reporting on the algorithmic progress. The elements in RL are, in order:SUMINF: Sum of the infeasibilities. In phase 0 it will include the infeasibilities in both easy and difficult constraint. During phase 3 and 4 SUMINF will be 0.OBJVAL: The value of the true objective function. OBJVAL is zero meaning undefined during phase 0, 1 and 2.RGMAX: The numerically largest reduced gradient. RGMAX will be zero during phase 0.STEP: The optimal steplength.X: The current point. The values may be read freely, but may not be changed.USRMEM: User memory as defined in coidef_usrmem() (Only for Fortran and C API).The user may tell CONOPT that the optimization should be stopped as soon as possible by letting Progress return a nonzero value. CONOPT will in this case call Status with SOLSTA = 8, user interrupt, and it will call Solution before returning. In an attempt to create a complete solution CONOPT may call FDEval for some post-triangular equations after Progress has returned a nonzero value. A zero return value means that CONOPT should continue the optimization.
When CONOPT solves a model, it tries to detect any part of the model that can be solved and removed before the optimization is started such as fixed variables and recursive or triangular equations. The variables and equations identified in this way can be solved independent of the optimization, and they can therefore be removed from the iterative optimization process.
If the optional callback routine TriOrd has been registered CONOPT will call TriOrd to report on the fixed variables and recursive equations. There are two types of calls distinguished with a MODE parameter. MODE = 1 (detection mode) is used during the actual solution process and it reports on all fixed variables, recursive equations and variables, implied bounds, etc as they are identified and solved. If the triangular solution process determines that the model is infeasible then CONOPT identifies the minimum set of equations and variables that cause this infeasibility, the so called critical equations and variables, and TriOrd is called again with MODE = 2 (critical reporting mode) for this subset of equations and variables in solution order. The first call in each sequence is called with negative MODE value (-1 and -2, respectively). This sign-feature can be used to write headers to the solution information.
If you are not interested in this information, do not register TriOrd. Otherwise, you may implement and register a routine that prints an appropriate message, possibly controlled by the value of MODE. Note that the number of times the routine will be called cannot be determined a priori; the calls will just stop when there are no recursive equations left or when the model is determined to be infeasible.
The Fortran definition of TriOrd is:
where:
MODE: Defines the two types of calls described above with 1=detection mode and 2=critical reporting mode. The first detection call uses MODE=-1 and the first critical reporting call uses MODE=-2.TYPE: Defines the type of model reduction according to the following list:COLNO is the only variable appearing in equation ROWNO and the equation is solved with respect to the variable. Both variable and equation are removed from the model.COLNO are the same (or within a distance of Rtbndt*Max(1,abs(VALUE))) and the variable is therefore fixed. The variable is removed from the model.ROWNO is redundant. An equality constraint is redundant when all variables appearing in the equation have been removed from the model and it is still feasible. An inequality is redundant when the bounds on all variables that have not been removed imply that the inequality cannot be violated (e.g. x1 + x2 < 3 with x1 = 1 and 0 < x2 < 1). The equation is removed from the model.COLNO is the only variable appearing in inequality ROWNO. The inequality is converted into a lower bound on the variable and the new bound is tighter than previous lower bounds. The equation is removed from the model.COLNO is the only variable appearing in inequality ROWNO. The inequality is converted into an upper bound on the variable and the new bound is tighter than previous upper bounds. The equation is removed from the model.ROWNO when combined with the bounds on the variables forces all variables to be fixed at their lower or upper bound. For example, the equation x1 - x2 = 1 combined with the bounds 0 < x1 < 10 and -2 < x2 < -1 forces x1 = 0 (fixed at the lower bound) and x2 = -1 (fixed at the upper bound). COLNO is used to report the number of variables that are fixed by forcing and the actual variables are then reported with COLNO calls in which TYPE is ForcedLower or ForcedUpper (defined below). The equation is removed from the model.COLNO is forced to be fixed at its lower bound by the previously reported Forcing Row. The variable is removed from the model.COLNO is forced to be fixed at its upper bound by the previously reported Forcing Row. The variable is removed from the model.STATUS: Defines the status of the model reduction according to the following list:TYPE values as follows:COLNO is the only variable appearing in equation ROWNO and the equation cannot be solved with respect to the variable, either because the variable is at a bound or because the derivative is zero.COLNO is the only variable appearing in inequality ROWNO and the implied bound is inconsistent with previous bounds, either defined by the modeler or implied by the pre-processor.ROWNO is infeasible because the range of the left-hand-side is inconsistent with the interval for the right-hand-side.ROWNO: The number of the equation (if relevant for TYPE).COLNO: The number of the variable (if relevant for TYPE).INF: Indicator for Infinity in the following VALUE argument. If INF = 0 then VALUE should be used as is. If INF = -1 or +1 then the VALUE argument represent –Infinity or +Infinity, respectively, indicating that the variable has reached the numerically largest value that CONOPT will accept.VALUE: The value of the variable to be removed (for TYPE = PreTriangular, FixedColumn, ForcedLower, or ForcedUpper) or the value of the new and tighter bound (for TYPE = ImpliedLower or ImpliedUpper). VALUE is not defined for TYPE = RedundantRow or ForcingRow.RESID: The value of the residual in equation ROWNO after the equations has been solved. RESID is zero unless STATUS defines the model to be infeasible.USRMEM: User memory as defined in coidef_usrmem() (Only for Fortran and C API).Comments: The terminology “Variable COLNO is the only variable appearing in equation or inequality ROWNO” means that the variable is the only variable left after previously reported variables have been removed.
The ROWNO argument identifies the number of the equation that is being solved. ROWNO equal to Base-1 (0 for Fortran and -1 for C) means that there is no equation which means that the variable COLNO is fixed through identical lower and upper bounds. Otherwise ROWNO is between 1 and NumCon for Fortran and between 0 and NumCon-1 for C calls. COLNO is usually the number of the variable that is being solved for and it has a value between 1 and NumVar for Fortran and between 0 and NumCon-1 for C. If the equation is solved for the slack variable, for example in case of inequalities, then COLNO will be Base-1 (0 for Fortran and -1 for C). VALUE is the final value of the variable or the slack and for structural variables it will always be between the bounds. RESID will usually be zero indicating that the equation was solved. In some special cases, COLNO, VALUE, and RESID may have to be interpreted differently:
COLNO will in this case be equal to Base-1 (0 for Fortran and -1 for C), and VALUE will be the value of the slack (MODE = 1 only).COLNO will be Base-1 (0 for Fortran and -1 for C) and VALUE and RESID will be zero (MODE = 1 only).COLNO equal to Base-1, VALUE zero, and RESID will be the (signed) infeasibility in the equation.COLNO = the critical variable, VALUE = its current value, and RESID contains the (signed) infeasibility in the equation.COLNO = the critical variable (that could be a slack variable flagged with Base-1), VALUE = current value of the variable, and RESID contains the (signed) infeasibility in the equation.CONOPT will stop searching for triangular equations when the model has been determined to be infeasible. If MODE = 1, CONOPT will start with a sequence of TriOrd calls with MODE = 2 for the critical subsequence of equations and variables, and if MODE = 2 then this will be the last call. CONOPT will also call the Message callback routine explaining the reason it stops just after the last call of TriOrd.
1.13.2