« Previous « Start » Next »
4 Using the NPSOL 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 solver
MINOS. 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.
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.
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 = 'minosp.out'; % New name for Print File
Prob.SOL.SummFile = 'minoss.out'; % New name for Summary File
The amount of printing is determined by a print level code, which
is different for different 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
NPSOL and
NLSSOL. There are also different other
parameters that influence how much output is written on the files.
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
MINOS.
... % Define first problem
Result = tomRun('minos',Prob); % Solve problem at t=1
... for t=2:N
... % Changes at time t in Prob structure
Prob = WarmDefSOL('minos', Prob, Result(t-1));
Result(t) = tomRun('minos',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
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 »