What does this Fmincon error mean?

Hi Everyone

I'm doing a constrained optimization where I first generate a few random intial points, I then only keep the feasible ones. I do this by running the objective function to see if it returns a NaN.

Then I use the feasible set of initial values and I call fmincon in a FOR loop. I did this because I was worried about local minima. I have turned on the option to use parallel workers.

However, I'm now receiving a weird error after a certain amount of fmincon executions.

Here is the output:

    User objective function returned NaN; trying a new point...
   22     590    9.074473e-01    1.382e+01    2.173e+03    1.337e-01
   Error using parallel_function (line 589)

   Matrix dimensions must agree.

   Error stack:
   parfinitedifferences>(parfor body) at 158

   Error in C:\MATLAB\R2012a      
   Student\toolbox\shared\optimlib\parfinitedifferences.p>parfinitedifferences (line 118)

   Error in C:\MATLAB\R2012a     
     Student\toolbox\optim\optim\private\computeFinDiffGradAndJac.p>computeFinDiffGradAndJac (line
45)

 Error in C:\MATLAB\R2012a Student\toolbox\optim\optim\barrier.p>barrier (line 564)

Error in fmincon (line 841)
  [X,FVAL,EXITFLAG,OUTPUT,LAMBDA,GRAD,HESSIAN] = barrier(funfcn,X,A,B,Aeq,Beq,l,u,confcn,options.HessFcn, ...

   Error in FreeTailObjConstr (line 70)
   [x,fval,exitflag] =    fmincon(fun,x0,Aineq,Bineq,Aeq,Beq,LB,UB,cfun,options,param);

   Error in multiStartFreeTail (line 113)
        [x,fval,exitflag] = FreeTailObjConstr(x0, UB, LB, muVal);
    % code
  end

What does this mean???

Answer 1

[Steve Grikschat]

This is a bug with the parallel finite differences approximation code. In particular, how this feature works with "invalid" values (i.e. Inf, NaN, and complex) is broken when it cannot get a real/defined function value. I'll make a bug report for this.

In your problem, does your objective function naturally evaluate to NaN when the input parameters are outside of a constrained region? Or do you do this manually:

if isFeasible(x)
  f = ...
else
  f = NaN
end

If you force the function value to NaN, I suggest trying without that, which will avoid this error. Otherwise, you can use the serial mode (set UseParallel to 'never').

[Amir Patel]

Hi

Thank you for that reply.

Unfortunately, that's not ideal for me as returning an arbitrary large value, makes it difficult for fmincon to converge. See this link: http://www.mathworks.com/help/optim/ug/optimizing-a-simulation-or-ordinary-differential-equation.html#btfizgo

Is there any other way around this? A Patch perhaps? I'm leaving running the algorithm on one worker as a last resolution.

Cheers

[Alan Weiss]

I wonder if you have misunderstood the "return NaN" recommendation in the link you gave. I assume that you are running a simulation or solving an ODE to evaluate your objective and nonlinear constraint functions.

My question is this: do you have a nonlinear constraint function defined in your problem? I mean, do you have a function c(x) where "feasible" means c(x) <= 0, and "infeasible" means c(x) > 0? And are you setting either the objective or nonlinear constraint function to NaN when c(x) > 0?

fmincon has a reasonably robust nonlinear constraint algorithm when the function c(x) is smooth. If you set the objective or nonlinear constraint to NaN whenever there is a constraint violation, then the solver cannot recognize when it is close to a constraint boundary, it only gets the binary signal of feasible or not. The solver works better if it can smoothly approach feasibility.

Alan Weiss

MATLAB mathematical toolbox documentation

[Amir Patel]

Hi Alan

Thank you very much for following up.

Yes, I do have a nonlinear constraint function. The reason why I return NaN is because sometimes fmincon will try a vector of 'x' which causes my simulation (a Simulink model) to halt because one of the integrator inputs go to INF or NaN.

To prevent this, I detect when the system's states get arbitrarily large, and then I stop the simulation and return a NaN for the Cost. The previous thing I did, was to stop the simulation but return a very large Cost.

Is this the correct way of doing it?

[Amir Patel]

As a matter of interest, does Multistart have the same bug?

[Steve Grikschat]

What you are doing is reasonable. See my original answer for a workaround. See comment below about MultiStart.

Answer 2

[Amir Patel]

Does Multistart have the same bug?

[Steve Grikschat]

It depends where you use the parallel resources.

MultiStart in parallel means that fmincon is run with a different start point on each worker. This disables the parallelism inside fmincon (finite differences). So the bug does not happen here.

If, however, you run MultiStart in serial, but enable parallelism in fmincon, then the bug can happen.