Multivariable Optimization with the FMINCON Function

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.

Answer 1

[Kye Taylor]

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]

Or, you could change the way you call FMINCON

fmincon(@(x)myfun(x(1),x(2),x(3),x(4)), xInitial,....)

[Alexander]

Thanks for the quick response, Kye!

My objective function is already structured in the manner that you suggested ...

function f = PV_objfun(x)

x7 = x(1); x8 = x(2); x9 = x(3); x10 = x(4);

f = PV_design_code(x7,x8,x9,x10);

The variable "f" represents the value of the objective function (i.e. the weight of the pressure vessel). To calculate the value of f, FMINCON is expected to call up the robust design alogrithm ("PV_design_code"), with the four variables determined by the FMINCON algorithm.

Unfortunately, FMINCON seems to focus on a single variable, such as x(1), without altering any of the other variables.

Answer 2

[Matt J]

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.

[Alexander]

Thanks for the suggestion, Matt! I haven't conducted a sensitivity analysis on the four parameters, but my engineering judgment suggests that they should all influence the objective function. The parameters represent the dimensions of a standard T-stiffener: web thickness, web height, flange thickness, and flange width. The objective function sums all of the material weight for the total pressure vessel, so changing all of the dimensions should affect the amount of material similarly. I'll check to make sure that everything is coded correctly, but in order to attain a feasible solution (i.e. one that "passes" the structural design rules for maximum stress, stiffener tripping, etc.), all four parameters must be varied.

[Matt J]

Make sure there are no quantization operations in your nonlinear constraint functions (if you have any) as well. All functions fed to FMINCON must be differentiable and smoothly varying.

[Alexander]

That could definitely be an issue. I have an equality constraint that is essentially a binary value. If the pressure vessel design "passes" all of the programmed design rules, the binary value is 1. Otherwise, if even one of the rules is "failed," the binary value is 0. I'm not sure if FMINCON is robust enough to handle the situation where I don't already start with a "passing" (but non-ideal) solution, as I suspect that there is a discontinuity in that binary jump from 0 to 1. The constraint condition is that the the specific value (defined as "check_final_binary") has to equal 1.

[Matt J]

As I said, FMINCON can only work with twice differentiable (and hence continuous) functions. So, no discontinuities are allowed, be they in the constraints or in the objective.

[Sean de Wolski]

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]

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.