« Previous « Start » Next »
4 Using the SOL Solvers in TOMLAB
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.
4.1 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.
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.
4.2 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, 10
20, 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
4.3 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.
4.4 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.
4.5 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
4.6 Parameters in Prob.optParam
Information stored in the structure Prob.optParam |
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). |
« Previous « Start » Next »