SOL Using the SOL Solvers in TOMLAB
From TomWiki
This page is part of the SOL Manual. See SOL. |
This section discusses the use of the TOMLAB solvers from Stanford Systems Optimization Laboratory (SOL). In order to use these solvers efficiently, it is recommended to read the corresponding solver details as well. It is important to do help on the m-files corresponding to each solver as well as the TOMLAB interface routine. The names for MINOS solver are minos.m and minosTL.m, and similar for other solvers.
To learn all the different parameter settings for a solver it is useful to run the GUI, where all parameters are selectable, and all default values are shown. Furthermore there are short help available for the different solver parameters in the drag menus. Even if the user is not using the GUI to solve the particular user problem, it might be useful to run the test problems defined in TOMLAB to learn how to use the SOL solvers in the most efficient way.
Contents |
Setting Solver Parameters
To handle the use of the SOL solvers, a special field in the Prob structure, Prob.SOL, is used to send information to the SOL solvers. It is also used to store the information needed for warm starts of the SOL solvers.
The vector Prob.SOL.optPar of length 71 holds most of the different parameters that control the performance of the SOL solvers. All parameters have default values. If calling the SOL solver directly, not using TOMLAB, the user should set the values wanted in the optPar vector. The rest should have the value -999, which gives the default value used by the solver. For information on other parameters that could effect the solution process see #Table: Information stored in the structure Prob.optParam. Default values in parenthesis.. The TOMLAB interface routine always has the name of the routine, with the additional two letters TL, e.g. for MINOS the TOMLAB interface routine is minosTL.
Other important fields to set when using the SOL solvers are the print and summary files that the solvers create. These files are very important to look through if any problems are occurring, to find what the causes might be, and if any warnings or errors are reported from the SOL solvers. To create a print and summary file, one example when running MINOS is the following statements
Prob.SOL.optPar(1) = 111111; % Maximal print level Prob.SOL.PrintFile = 'minos.pri' % Print file called minos.pri Prob.SOL.SummFile = 'minos.sum' % Summary file called minos.sum Prob.NumDiff = 6; % Tell TOMLAB that minos is estimating Prob.ConsDiff = 6; % all derivatives (gradient and Jacobian)
If MINOS is told that no derivatives are given, then MINOS will try to estimate them, and then TOMLAB must not do the same, i.e. Prob.NumDiff and Prob.ConsDiff must be set to six (internal solver estimation of derivatives). If MINOS is told that all derivatives are given, then TOMLAB might estimate them for MINOS using any of the five methods possible, or by using automatic differentiation.
Derivatives for the Solvers
The TOMLAB solvers from Stanford Systems Optimization Laboratory (SOL), have some useful special features, which influence the way that input is prepared to the solvers.
When defining the gradient vector and the constraint Jacobian matrix it is often the case that they are only partially known. The SOL solvers give the possibility to mark these elements. They will then be estimated by finite differences.
In TOMLAB the gradient and the constraint Jacobian matrix are defined in two separate routines. If any element is unknown, it is just marked with the standard Matlab element NaN. The TOMLAB SOL interface routines will estimate the NaN elements if Prob.CheckNaN is set to 1.
If any gradient or constraint Jacobian element is infinite, in Matlab set as Inf or -Inf, this element is converted to a big number, 1020 , in the TOMLAB SOL interface.
The following applies to the sparse nonlinear programming solvers MINOS and SNOPT. When the constraint Jacobian matrix is sparse, then only the nonzero elements should be given. The sparse pattern is given as a sparse matrix Prob.ConsPattern. In this matrix nonzero elements are marking nonzero elements in the constraint Jacobian. This pattern is static, i.e. given once before the call to the SOL solver. One problem is that a sparse matrix in Matlab is dynamic, i.e. only the nonzero elements of the matrix are stored. As soon as an element becomes zero, the vector of nonzeros are decreased one element. A gradient element that is normally nonzero might become zero during the optimization. Therefore care must be taken by the interface to return the correct values, because the SOL solvers assume the possible non-zero elements of the constraint Jacobian to be returned in the correct order.
The TOMLAB interface assumes the following conventions for the constraint Jacobian matrix:
- If the user returns a sparse matrix, and the number of nonzeros are equal to the number of nonzeros in Prob.ConsPattern, no checks are done.
- If the user returns a sparse matrix, and the number of nonzeros are not equal to the number of nonzeros in Prob.ConsPattern, the interface is matching all elements in the sparse array to find which nonzeros they represent, and returns the correct vector of static nonzeros.
- If the user returns a sparse matrix, and has given no pattern of nonzeros in Prob.ConsPattern, i.e. it is an empty array, then the solver and the interface assumes a full, dense matrix and the interface makes a full matrix before returning the elements, column by column, to the solver.
- If the user returns a dense matrix, the interface just feeds all elements, column by column, back to the solver.
- If too few elements are returned, the solver will estimate the rest using finite differences.
When using the dense SOL nonlinear programming solvers, the constraint Jacobian matrix is always assumed to be dense. The interface will convert any sparse matrix returned by the user to a dense, full matrix, and return the elements, column by column, to the solver.
If no derivatives are available, it might be better to use the Nonderivative linesearch in SNOPT. It is based on safeguarded quadratic interpolation. The default is to use a safeguarded cubic interpolation if derivatives are available. To select Nonderivative linesearch set the following parameter:
Prob.SOL.optPar(40) = 0; % Use Nonderivative instead of Derivative Linesearch
Solver Output to Files
The SOL solvers print different amount of information on ASCII files, one Print File with more information, and one Summary File with less information. SNOPT is using snoptpri.txt and snoptsum.txt as default names. MINOS is using minospri.txt and minossum.txt as default names. The following example shows how to set new names, other than the default, for these files.
Prob.SOL.PrintFile = 'snoptp.out'; % New name for Print File Prob.SOL.SummFile = 'snopts.out'; % New name for Summary File
The SQOPT solver by default also defines the two log files as sqoptpri.txt and sqoptsum.txt. If the print level is 0 no output will occur, unless some errors are encountered. It is possible to make SQOPT totally silent and avoid any opening of files by the following statements.
Prob.SOL.PrintFile = ''; Prob.SOL.SummFile = ''; Prob.SOL.optPar(2) = 0; Prob.SOL.optPar(3) = 0;
The amount of printing is determined by a print level code, which is different for the solvers. See the help and manual for each solver. Some solvers also have two print levels, one major print level and one minor print level. This applies for SNOPT, NPSOL and NLSSOL. There are also different other parameters that influence how much output is written on the files. The following example show how to get maximum output for SNOPT on files with user defined names.
Prob.SOL.PrintFile = 'sn.p'; % New name for Print File Prob.SOL.SummFile = 'sn.s'; % New name for Summary File Prob.SOL.optPar(1) = 111111; % Major print level, combination of six 0/1 Prob.SOL.optPar(2) = 10; % Minor print level, 0, 1 or 10. 10 is maximum Prob.SOL.optPar(5) = 1; % Print Frequency Prob.SOL.optPar(6) = 1; % Summary Frequency Prob.SOL.optPar(7) = 1; % Solution yes. 0 = Solution not printed Prob.SOL.optPar(8) = 1; % Full options listing, not default
The other SOL solvers, NPSOL, NLSSOL, LSSOL, QPOPT and LPOPT, only define the Print File and Summary File if the user has defined names for them. See the help for each solver on how to set the correct print level and other parameters.
Warm Starts for the Solvers
In TOMLAB warm starts for the SOL solvers are automatically handled. The only thing needed is to call the routine WarmDefSOL after having solved the problem the first time, as the following principal example shows doing repeated calls to SNOPT.
... % Define first problem Result = tomRun('snopt',Prob); % Solve problem at t=1 ... for t=2:N ... % Changes at time t in Prob structure Prob = WarmDefSOL('snopt', Prob, Result(t-1)); Result(t) = tomRun('snopt',Prob); % Call tomRun to solve again ... % Postprocessing end
The WarmDefSOL routine are setting the warm start flag Prob.WarmStart, as true.
Prob.WarmStart = 1;
It is also moving subfields on the Result.SOL structure into Prob.SOL for the next run. For SNOPT, SQOPT and MINOS the following commands are needed.
Prob.SOL.xs = Result.SOL.xs Prob.SOL.hs = Result.SOL.hs Prob.SOL.nS = Result.SOL.nS
For NPSOL and the other SOL solvers the commands are
Prob.SOL.xs = Result.SOL.xs Prob.SOL.iState = Result.SOL.iState Prob.SOL.cLamda = Result.SOL.cLamda Prob.SOL.H = Result.SOL.H
The fields SOL.cLamda and SOL.H are not used for QPOPT, LPOPT, and LSSOL. For NPSOL and NLSSOL the TOMLAB interface is automatically setting the necessary parameter Hessian Yes for subsequent runs. However, in order for the first warm start to work the user must set this parameter before the first run. The principal calls will be
... % Define first problem Prob.SOL.optPar(50) = 1; % Define Hessian Yes BEFORE first call Result = tomRun('npsol',Prob); % Solve problem at t=1 ... for t=2:N ... Prob = WarmDefSOL('npsol', Prob, Result); Result = tomRun('npsol',Prob); ... end
Note that for all solvers the new initial value are taken from the field Prob.SOL.xs and any user change in the standard initial value Prob.x_0 is neglected.
Memory for the Solvers
Some users have encountered problems where SOL solvers report insufficient memory on machines where memory should not be an issue. The solvers estimate their internal memory requirements at startup. This estimate is not always large enough so the user might have to specify additional memory. This can be accomplished by
Prob.SOL.moremem = 1000; % or even larger if necessary
Parameters in Prob.optParam
Table: Information stored in the structure Prob.optParam. Default values in parenthesis.
Field | Description |
---|---|
PreSolve | Flag if presolve analysis is to be applied on linear constraints ( 0). |
DiffInt | Difference interval in derivative estimates (used for Prob.NumDiff/ConsDiff -1 or 1). |
CentralDiff | Central difference interval in derivative estimates (used for Prob.NumDiff/ConsDiff -2 or 2). |
splineSmooth | Smoothness parameter sent to the SPLINE Toolbox routine csaps.m when computing numerical approximations of the derivatives (0.4) (used for Prob.NumDiff/ConsDiff -3 or 3). |
VARsplineTol | Tolerance parameter sent to the SPLINE Toolbox routine spaps.m when computing numerical approximations of the derivatives (10-3 ) (used for Prob.NumDiff/ConsDiff -4 or 4). |
CHECK | If true, no more check is done on the structure. Set to true (=1) after first call to solver (which then calls optParamSet). |