This page will describe some common SNOPT behaviour, exit codes, and things to watch out for.

Below is an example of an optimize.his file for a case that is doing well. After a few major iterations, the step length becomes 1.0. It is common for the first few iterations to take smaller steps while SNOPT is building up Hessian information and "getting familiar" with the optimization problem. While not shown in this example, there will often be a few "D" flags in the last column, indicating failed function evaluations (the mesh movement or flowsolve did not converge). This is typical as the first few shape changes are often quite extreme; more so than the solver can handle. 

This sample problem quickly becomes feasible (feasibility drops below the feasibility tolerance of 1E-4). Feasibility won't always be achieved so quickly. It will largely depend on how close to a feasible solution the optimization starts (e.g. is the initial AoA that for which the lift constraint is satisfied.) In general, it is a good idea to start as close as possible to a feasible solution to help the optimizer.

Common SNOPT Exit Codes

Below is a description of the most common exit codes we see. For more codes and details see Section 8.6 of the SNOPT Manual.

• SNOPT EXIT 0 / INFO 1: This is the ideal exit. The optimization exited successfully, with all feasibility and optimality conditions satisfied. In reality, this is often not achieved for all but the simplest (fewest design variable) problems. 

• SNOPT EXIT 60 / INFO 63 - Undefined user-supplied functions, unable to proceed into undefined region: This occurs after multiple function evaluation failures. It will often (but not always) be accompanied with many "D" flags in the last iterations of optimize.his as shown in the example below. The optimizer is trying to go in a direction that the solver can't handle. If it happens early in the optimization, a number of "D" flags will be present. The optimizer will experience multiple function evaluation failures, try and backtrack to the last state that it was able to get a converged solution on. It will do this repeatedly until it determines that it is unable to move in the direction it needs to improve the merit function, and then give up, throwing this exit condition. Sometimes, particularly late in the optimization when the problem is relatively well converged, it can throw this exit condition after only a few (sometimes even one) function evaluation failures and seemingly out of no where.
  When this occurs, the best approach is to try and diagnose which solver is failing (mesh movement or flow solver), why, and try to adjust any solver parameters to improve robustness. It it occurs in the first few iterations, it is probably best to just start a new case with the modified solver parameters. If the optimization has been running for a while and doing fine up until this point, it doesn't make sense to start from scratch. In that case, the trimOptHis script can be used as described in trimOptHis  to to "trim off" the troublesome function evaluations from the optimization restart files in order to allow the optimization to be picked up from just before it started having trouble, but with the improved solver parameters.

• SNOPT EXIT 40 / INFO 41 / INFO 42 - Terminated after numerical difficulties, current point cannot be improved: This exit can be a bit ambiguous. In my experience, the leading cause is inaccurate functions or gradients. This exit often arises late in the optimization when the case is relatively well converged, but no further improvement can be made. This can be that the design space is flat near the optimal point, and the error/noise in the functions/gradients is too much to make any meaningful design changes. Hopfully the case is well enough converged that it can yield usable information and the design can be considered converged. To avoid this error two things can be done:

  1. Make sure that the gradients are accurate. Run the optimization case (or a second identical but short case) with jtstrm% grad_test = 0 which causes SNOPT to do a finite difference check of the gradients at the start of the optimization. This test isn't always accurate, but if the finite difference and computed gradient values that it reports in optimize.info are very different, consider that the gradients may be inaccurate. A tip to identify the offending gradient is to run debugjobs with only one constraint active until you figures out which one is causing the error.

  2.  Set a realistic function precision and optimality convergence tolerance. The function and gradient precision that SNOPT should expect can be set with the input parameter jtstrm% func_precision. This value should be set to a level that is commensurate with the expected accuracy of CL, CD, etc. E.g., if it is found that at flow solver convergence (for a given residual convergence criteria) CD is accurate to 1E-5, that value should be used for the function precision. The SNOPT manual recommends that the optimality tolerance, set with jtstrm% grad_tol, is sqrt(function precision).

• Elastic mode: This isn't an exit code, but rather a mode that SNOPT activates. SNOPT enters what it calls "elastic mode" when it believe the problem is infeasible, in particular, the nonlinear constraints can't be satisfied. See the SNOPT manual for what SNOPT is doing when it attempts this. However, that is a bit immaterial since if you enter elastic mode there is likely something wrong with your problem setup. A sample of the optimize.his when elastic mode is entered is shown below. It is indicated by a few things:

  1. The message "Elastic Phase 1" and "Elastic Phase 2" will be printed, indicating it is entering elastic mode.

  2. The letter flag "i" will be shown in the last column.

  3. The value of the MeritFunction will become very large since it will now include the "weighted elastics".

SNOPT seems to be very good at identifying an infeasible problem. So, if your case enters elastic mode, particularly right at the beginning, it is almost certainly an issue with your optimization problem definition and you have indeed specified an infeasible problem. For example, there may be conflicting geometric constraints (e.g. is there a bound on a geometric quantity like span that is not achievable because of the bound on a design variable?) or something in your aerodynamic constrains (e.g. you have asked for both lift and moment constraints at multiple operating points for a multipoint problem but without any control surface design variables.)