Multivariable Optimization with the FMINCON Function (2024)

Or, you could change the way you call FMINCON

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.

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.

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.

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.

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.

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.

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.