fmincon walks away from good solution

I have learned from experience that patternsearch can be a good local minimum buster when used in conjunction with fmincon. I feed both the same objective function, and constraints and alternate between the two search methods in a loop. On a particular problem, I see fmincon walk away from a good solution that patternsearch has found. Below is output from my script. The only constraints used in this search are lb and ub; as stated before they are fed to both fmincon and patternsearch. What the heck could be going on here?

Loop #1
fmincon
                                            First-order      Norm of
 Iter F-count            f(x)  Feasibility   optimality         step
    0       8    1.192222e-02    0.000e+00    1.067e+01
    1      29    7.689937e-03    0.000e+00    5.144e+00    1.528e-03
    2      38    7.689937e-03    0.000e+00    5.144e+00    2.942e-16

Local minimum possible. Constraints satisfied.

fmincon stopped because the size of the current step is less than
the selected value of the step size tolerance and constraints are 
satisfied to within the default value of the constraint tolerance.

<stopping criteria details>

Loop #2
PatternSearch

Iter     f-count          f(x)      MeshSize     Method
    0        1     0.00768994             1      
    1        6     0.00768994           0.5     Refine Mesh
    2       12     0.00766503             1     Successful Poll
    3       17     0.00766503           0.5     Refine Mesh
Stop requested.
fmincon
                                            First-order      Norm of
 Iter F-count            f(x)  Feasibility   optimality         step
    0       8    7.665026e-03    0.000e+00    5.160e+00
    1      27    1.014478e-02    0.000e+00    3.812e+00    8.801e-03
    2      36    1.014478e-02    0.000e+00    3.812e+00    1.000e-15

Local minimum possible. Constraints satisfied.

Answer 1

[Matt J]

Notice that the "First-order optimality" measure at the point found by fmincon in Loop #2 is lower than the starting point found by patternsearch. Unlike patternsearch, fmincon uses the function's derivatives to compute the first-order optimality (a measure of stationarity), and thus to see if it is worth continuing to iterate. Clearly, the point x0 found by patternsearch was not stationary enough for fmincon to see it is a solution. It therefore continues to iterate until it finds a more stationary point.

My guess is that your function might not have continuous derivatives, as is required by fmincon. When fmincon finds a point, patternsearch can therefore throw it out of stationarity with a slight perturbation. Alternatively, patternsearch may have found a non-stationary point that was far away from the one obtained in Loop #1, but with a similar objective function value.

In any case, it might help to know what fmincon algorithm you are using (sqp, interior-point, etc...)

[Susan]

Matt, I am pretty sure it is interior-point. There's something else I need to check and follow up on here, but I'm not at work today.

This is simulated data and I'm pretty much starting the search with the correct answer in this instance. I'm not sure about discontinuous derivatives ... but I am trying to parameterize a nonlinear model.

Thanks for your input. I'll be back.