Multivariable Optimization with the FMINCON Function
33 Ansichten (letzte 30 Tage)
Ältere Kommentare anzeigen
I'm using a comprehensive MATLAB code to create a stiffened pressure vessel (that fulfills a known set of structural design criteria). The code to design the pressure vessel is written as a function, with four input variables that define the scantlings of the stiffeners for the design. The objective function (using FMINCON) calls up this design code function, and, in theory, the FMINCON algorithm is expected to modify the four design variables until an ideal solution is found (i.e. the pressure vessel design that represents a minimal weight solution, but satisfies all structural design criteria).
Unfortunately, as written, the current code appears to iterate through a single design variable, rather than all four design variables. As a result, no feasible solution is found. How do I modify the FMINCON function to ensure that the full multivariable design space is considered? Why does the default FMINCON function focus on a single design variable at a time, rather than iterating through all four design variables concurrently?
Any insights would be tremendously appreciated.
0 Kommentare
Antworten (2)
Kye Taylor
am 12 Dez. 2012
Bearbeitet: Kye Taylor
am 12 Dez. 2012
The key is to modify your objective function to be one that can be utilized by the fmincon interface.
For example, if your objective function has a signature that looks like
function f = myfun(x1,x2,x3,x4)
% assuming x1,...,x4 are scalars
% computations with x1,...,x4 like
f = x1*x2*x3*x4
rewrite it like
function f = myfun(x)
% input to objectives passed to fmincon can
% be a vector. So treat its scalar components
% as your design variables
x1 = x(1);
x2 = x(2);
x3 = x(3);
x4 = x(4);
% computations with x1,...,x4 like
f = x1*x2*x3*x4
Matt J
am 12 Dez. 2012
Bearbeitet: Matt J
am 12 Dez. 2012
Have you checked that small changes in the remaining variables x8, x9, x10 affect the output value of the objective function? If they do not, what you're seeing makes perfect sense.
A common mistake is to have non-differentiable quantizer operations in the objective function like ROUND, FLOOR, CEIL, etc... These make the function locally flat in some or all variables.
6 Kommentare
Sean de Wolski
am 12 Dez. 2012
You could use the 'DiffMinChange' option in optimset() to force fmincon to look further for its finite differences. This can help it step away from locally flat or discontinuous points.
Matt J
am 12 Dez. 2012
Bearbeitet: Matt J
am 12 Dez. 2012
It's still questionable whether DiffMinChange would make a difference for FMINCON algorithms where line searches are involved. The finite difference calculations normally control the direction of the search for the next point, but not the step size. If the step size isn't large enough to skip over the locally flat region, then you'll still get stuck.
On the other hand, it would make some sense if the FMINCON code did choose the initial step size of the line search at least as large as DiffMinChange, but I've seen no documentation of that being the case.
Siehe auch
Kategorien
Mehr zu Systems of Nonlinear Equations finden Sie in Help Center und File Exchange
Produkte
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!