EXIT conditions

When the solution procedure terminates, an EXIT -- message is printed to summarize the final result.  Here we describe each message and suggest possible courses of action.

The number associated with each EXIT is the output value of the integer variable inform.

This is the message we all hope to see!  It is certainly preferable to every other message, and we naturally want to believe what it says, because this is surely one situation where the computer knows best.  There may be cause for celebration if the objective function has reached an astonishingly new high (or low.  Or perhaps it will signal the end of a strenuous series of runs that have iterated far into the night, depleting one's patience and computing funds to an equally alarming degree.  (We hope not!)

In all cases, a distinct level of caution is in order, even if it can wait until next morning.  For example, if the objective value is much better than expected, we may have obtained an optimal solution to the wrong problem!  Almost any item of data could have that effect if it has the wrong value.   Verifying that the problem has been defined correctly is one of the more difficult tasks for a model builder.  It is good practice in the function subroutines to print any data that is input during the first entry.

If nonlinearities exist, one must always ask the question: could there be more than one local optimum?  When the constraints are linear and the objective is known to be convex (e.g., a sum of squares) then all will be well if we are minimizing the objective: a local minimum is a global minimum in the sense that no other point has a lower function value.  (However, many points could have the same objective value, particularly if the objective is largely linear.)  Conversely, if we are maximizing a convex function, a local maximum cannot be expected to be global, unless there are sufficient constraints to confine the feasible region.

Similar statements could be made about nonlinear constraints defining convex or concave regions.  However, the functions of a problem are more likely to be neither convex nor concave.  Our advice is always to specify a starting point that is as good an estimate as possible, and to include reasonable upper and lower bounds on all variables, in order to confine the solution to the specific region of interest.  We expect modelers to know something about their problem , and to make use of that knowledge as they themselves know best.

One other caution about "Optimal solution''s.  Some of the variables or slacks may lie outside their bounds more than desired, especially if scaling was requested. Max Primal infeas refers to the largest bound infeasibility and which variable is involved.  If it is too large, consider restarting with a smaller Minor feasibility tolerance (say 10 times smaller) and perhaps Scale option 0.

Similarly, Max Dual infeas indicates which variable is most likely to be at a non-optimal value.  Broadly speaking, if

Max Dual infeas/Norm of pi = 10-d,

then the objective function would probably change in the dth significant digit if optimization could be continued.  If d seems too large, consider restarting with smaller Major and Minor optimality tolerances.

Finally, Nonlinear constraint violn shows the maximum infeasibility for nonlinear rows.  If it seems too large, consider restarting with a smaller Major feasibility tolerance.

When the constraints are linear, this message can probably be trusted.  Feasibility is measured with respect to the upper and lower bounds on the variables and slacks.  Among all the points satisfying the general constraints Ax - s = 0 , there is apparently no point that satisfies the bounds on x and s.  Violations as small as the Minor feasibility tolerance are ignored, but at least one component of x or s violates a bound by more than the tolerance.

When nonlinear constraints are present, infeasibility is much harder to recognize correctly.  Even if a feasible solution exists, the current linearization of the constraints may not contain a feasible point.  In an attempt to deal with this situation, when solving each QP subproblem, SNOPT is prepared to relax the bounds on the slacks associated with nonlinear rows.

If a QP subproblem proves to be infeasible or unbounded (or if the Lagrange multiplier estimates for the nonlinear constraints become large), SNOPT enters so-called "nonlinear elastic'' mode.  The subproblem includes the original QP objective and the sum of the infeasibilities—suitably weighted using the Elastic weight parameter.  In elastic mode, some of the bounds on the nonlinear rows "elastic"—i.e., they are allowed to violate their specified bounds.  Variables subject to elastic bounds are known as elastic variables. An elastic variable is free to violate one or both of its original upper or lower bounds.  If the original problem has a feasible solution and the elastic weight is sufficiently large, a feasible point eventually will be obtained for the perturbed constraints, and optimization can continue on the subproblem.  If the nonlinear problem has no feasible solution, SNOPT will tend to determine a "good'' infeasible point if the elastic weight is sufficiently large.  (If the elastic weight were infinite, SNOPT would locally minimize the nonlinear constraint violations subject to the linear constraints and bounds.)

Unfortunately, even though SNOPT locally minimizes the nonlinear constraint violations, there may still exist other regions in which the nonlinear constraints are satisfied.  Wherever possible, nonlinear constraints should be defined in such a way that feasible points are known to exist when the constraints are linearized.

For linear problems, unboundedness is detected by the simplex method when a nonbasic variable can apparently be increased or decreased by an arbitrary amount without causing a basic variable to violate a bound.  A message prior to the EXIT message will give the index of the nonbasic variable.  Consider adding an upper or lower bound to the variable.  Also, examine the constraints that have nonzeros in the associated column, to see if they have been formulated as intended.

Very rarely, the scaling of the problem could be so poor that numerical error will give an erroneous indication of unboundedness.  Consider using the Scale option.

For nonlinear problems, SNOPT monitors both the size of the current objective function and the size of the change in the variables at each step.  If either of these is very large (as judged by the Unbounded parameters—see Description of optional parameters), the problem is terminated and declared UNBOUNDED.  To avoid large function values, it may be necessary to impose bounds on some of the variables in order to keep them away from singularities in the nonlinear functions.

The second message indicates an abnormal termination while enforcing the limit on the constraint violations.  This exit implies that the objective is not bounded below in the feasible region defined by expanding the bounds by the value of the Violation limit.

Either the Iterations limit or the Major iterations limit was exceeded before the required solution could be found.  Check the iteration log to be sure that progress was being made.  If so, restart the run using a basis file that was saved (or should have been saved!) at the end of the run.

A feasible solution has been found, but the requested accuracy in the dual infeasibilities could not be achieved.  An abnormal termination has occurred, but SNOPT is within 10-2 of satisfying the Major optimality tolerance.  Check that the Major optimality tolerance is not too small.

The problem appears to be more nonlinear than anticipated.  The current set of basic and superbasic variables have been optimized as much as possible and a PRICE operation is necessary to continue, but there are already nnn superbasics (and no room for any more).

In general, raise the Superbasics limit s by a reasonable amount, bearing in mind the storage needed for the reduced Hessian (about 1/2 s2 double words).

This exit occurs if a value mode<= -1 is set during some call to funobj or funcon.  SNOPT assumes that you want the problem to be abandoned forthwith.

In some environments, this exit means that your subroutines were not successfully linked to SNOPT.  If the default versions of funobj and funcon are ever called, they issue a warning message and then set mode to terminate the run.

A check has been made on some individual elements of the objective gradient array at the first point that satisfies the linear constraints.  At least one component gObj(j) is being set to a value that disagrees markedly with a forward-difference estimate of Df/Dx_i.  (The relative difference between the computed and estimated values is 1.0 or more.)  This exit is a safeguard, since SNOPT will usually fail to make progress when the computed gradients are seriously inaccurate.  In the process it may expend considerable effort before terminating with EXIT 9 below.

Check the function and gradient computation very carefully in funobj.  A simple omission (such as forgetting to divide fObj by 2) could explain everything.  If fObj or gObj(j) is very large, then give serious thought to scaling the function or the nonlinear variables.

If you feel certain that the computed gObj(j) is correct (and that the forward-difference estimate is therefore wrong), you can specify Verify level 0 to prevent individual elements from being checked.

However, the optimization procedure may have difficulty.

This is analogous to the preceding exit.  At least one of the computed Jacobian elements is significantly different from an estimate obtained by forward-differencing the constraint vector F(x).  Follow the advice given above, trying to ensure that the arrays fCon and gCon are being set correctly in funcon.

Several circumstances could lead to this exit.

An LU factorization of the basis has just been obtained and used to recompute the basic variables x_B, given the present values of the superbasic and nonbasic variables.  A step of "iterative refinement'' has also been applied to increase the accuracy of x_B.  However, a row check has revealed that the resulting solution does not satisfy the current constraints Ax - s = 0 sufficiently well.

This probably means that the current basis is very ill-conditioned.  Try Scale option 1 if scaling has not yet been used and there are some linear constraints and variables.

For certain highly structured basis matrices (notably those with band structure), a systematic growth may occur in the factor U.  Consult the description of Umax, Umin and Growth in Basis factorization statistics, and set the LU factor tolerance to 2.0 (or possibly even smaller, but not less than 1.0).

The user has set the value iAbort = 1 in subroutine s1User.  SNOPT assumes that you want the problem to be abandoned forthwith.

The main integer or real storage array iw(*) or rw(*) is apparently not large enough for this problem.  The routine declaring iw and rw should be recompiled with a larger dimensions for those arrays.  The new values should also be assigned to leniw and lenrw.

An estimate of the additional storage required is given in messages preceding the exit.

A preceding message will describe the error in more detail.  One such message says that the current basis has more than one element in row i and column j.  This could be caused by a corresponding error in the input parameters a(*), ha(*), and ka(*).

This exit is highly unlikely to occur.  The first factorization attempt will have found the basis to be structurally or numerically singular.  (Some diagonals of the triangular matrix U  were respectively zero or smaller than a certain tolerance.)  The associated variables are replaced by slacks and the modified basis is refactorized, but singularity persists.  This must mean that the problem is badly scaled, or the LU factor tolerance is too much larger than 1.0.

On the first line of the OLDBASIS file, the dimensions labeled m and n are different from those associated with the problem that has just been defined.  You have probably loaded a file that belongs to another problem.

Remember, if you have added rows or columns to a(*), ha(*) and ka(*), you will have to alter m and n and   the map beginning on the third line (a hazardous operation).  It may be easier to restart with a PUNCH or DUMP file from an earlier version of the problem.

For some reason, the OLDBASIS file is incompatible with the present problem, or is not consistent within itself.  The number of basic entries in the state vector (i.e., the number of 3's in the map) is not the same as m on the first line, or some of the 2's in the map did not have a corresponding "j  x_j'' entry following the map.

This exit should never happen.  It may indicate that the wrong SNOPT source files have been compiled, or incorrect parameters have been used in the call to subroutine snopt.

Check that all integer variables and arrays are declared integer in your calling program (including those beginning with h!), and that all "real'' variables and arrays are declared consistently.  (They should be double precision on most machines.)

The main integer storage array iw(*) is not large enough to provide workspace for the optimization procedure.  See the advice given for Exit 20.

The main storage array rw(*) is not large enough to provide workspace for the optimization procedure.  Be sure that the Superbasics limit is not unreasonably large.  Otherwise, see the advice for Exit 20.