Fmincon creates complex input vector

Some might remember me from some earlier questions. I have programmed an aircraft generator and analyzer. I'm trying to find an optimized aircraft, but after several months still no luck. Yesterday I started an optimization, which ran for about 12 hours and did 27 iteration successfully. I finally thought it was going to work, yet, halfway through the 28th iteration it failed again.

This time my objective function failed, so normally this is a fault in my own program. It returned an error that one of the variables had an imaginary part, which shouldn't be possible. After loading the currentxvector, which I save to debug problems like this, I quickly discovered that all of the values of the input vector (xvector as it is called in my program) are complex. How is this possible? I thought fmincon is not able to work with complex numbers. Did it make and error, or did I?

Needless to say that my start xvector has only real numbers and all of the preceding 27 iterations had only real numbers as well. I have no clue where this comes from and how to handle this problem. My xvector has a length of 31. I use an active-line algorithm now, that seemed to work fine until this came along.

I hope someone can help me out. I apologize for the number of questions asked. It is really a complex problem, which I hope to solve soon.

My xvector is saved as soon as the objective function is started, so I don't alter anything. If I'm right this is just the xvector created by fmincon. The way my xvector is saved:

function f = obj(aircraftstart,x)
        %Save current xvector, for debugging purposes
        eval(sprintf('%s%s%s','save(''optdata\',problem.TAG,...
        '\currentxvector.mat'',''x'')'))
        <Calculations>
return

[Jorrit]

I realize that this is a complex problem and it might be very difficult for someone to help with only this information. Even if you don't know the solution, it would be nice to get a confirmation that the problem is caused by fmincon.

If anything fails, I will write an if statement to catch this and return just some objective value and constraint vector. I hope fmincon is able to handle that and ignore the complex xvector's solution.

[Jorrit]

I keep realizing I didn't supply all necessary information. Sorry for that.

As said I'm using an active-set algorithm. I do not supply gradients and Hessian myself. This is calculated by fmincon. I suppose previous constraints and objective value cause fmincon to come up with a complex x vector, is that right? So could it be that this is causing the problem?

Answer 1

[Jorrit]

Okay I figured it out. It was a problem in my objective function.

Here is what happened: I have an aerodynamic solver included, this produced a numerical instability. At some point there is a calculation to approximate the maximum lift coefficient. This amplified the numerical instability and made a small part in the lift distribution negative. I did not anticipate this eventuality, which made one of the constraints complex. This happened several iterations before the actual error. The complex number probably got stuck in the Hessian, which eventually made fmincon produce a complex input vector.

The solution to prevent this from happening is to made fmincon stop as soon as a constraint or objective value gets complex. This can be done be putting 'FunValCheck','on' in the optimset line. This still makes the optimizer stop, but at least it stops at a point where the source of the error is.

This problem is now solved. Another one and a half day wasted. Should I now accept my own answer, that is a bit strange right.

[Walter Roberson]

Yes, go ahead and accept your own answer. It will help others debug similar problems in future.

Answer 2

[Max]

Does your objective function contain logs or non-integer powers of variables that take negative values in a neighbourhood containing your initial guess and the nearest local optimum? Taking logs or non-integer powers of negative numbers will land you with complex numbers. I often run into this problem after calculating what are supposed to be very small positive numbers which are actually returned as negative values due to numerical error. I can usually fix the problem by explicitly ensuring all values are positive before being passed to a log (or other function) that requires positive inputs in order to return real outputs; this usually involves setting negative values equal to eps or an otherwise small positive real.

[Jorrit]

Thanks for the suggestion. My objective function is a little more complex, than just clear operations on the parameters. I have found the problem now, so luckily it is solved.